Conversation

Notices

1. Embed this notice
   feld (feld@friedcheese.us)'s status on Saturday, 07-Sep-2024 22:48:19 JST feld
   "Systemd timers are better than cron"
   
   Ok yes to a point, but most people would be happy with another daemon that could schedule the same way systemd timers work without needing the rest of systemd. Someone should just make that.
   • Embed this notice
     feld (feld@friedcheese.us)'s status on Saturday, 07-Sep-2024 23:05:20 JST feld

     in reply to

     • miauz genyau
     @mia I need it to run things on a schedule, the logging and other junk is not interesting.
     
     
     - wake-up / triggers -- any IPC/message bus can fill this role
     
     - namespaces -- jails on BSD, but I can use them with my cron jobs to isolate something I'm running
     
     - state service tracking -- but the timer doesn't do this, it just runs the thing which doesn't have to be a systemd service, and if it is it's probably a one-shot. There are other ways to turn services on/off on a schedule if that's what you really want. Also the timer isn't going to turn the service back on. If it crashes too many times even systemd will mark it as failed. The timer isn't the supervisor here.
     
     So this timer replacement plus something like runit would be suitable for lots of things IMO.
   • Embed this notice
     miauz genyau (mia@movsw.0x0.st)'s status on Saturday, 07-Sep-2024 23:05:21 JST miauz genyau

     in reply to

     @feld but then you just end up reimplementing systemd unless you only want a small subset of what timers can do because imo wakeup conditions/triggers, scopes/namespaces, robust service state tracking, notification and logging mechanisms etc. are part of what makes them appealing
     i prefer them over cron because i'm not happy with just running commands and hoping for the best while manually having to ensure there are no race conditions and all the preconditions are also met

   • Embed this notice
     Pete Wright (pete_wright@nlogic.systems)'s status on Saturday, 07-Sep-2024 23:15:46 JST Pete Wright

     in reply to
     @feld they are so good because they work with only on OS and have shitty documentation?
     feld likes this.
   • Embed this notice
     miauz genyau (mia@movsw.0x0.st)'s status on Saturday, 07-Sep-2024 23:25:39 JST miauz genyau

     in reply to

     @feld but i guess this is all missing the point: what would be nice to have isn't really a systemd timer replacement but a more modern task scheduler than cron, without the unix/posix legacy brainworms and the crude hacks and fragile shell scripting it often entails

     feld likes this.
   • Embed this notice
     miauz genyau (mia@movsw.0x0.st)'s status on Saturday, 07-Sep-2024 23:25:40 JST miauz genyau

     in reply to

     @feld IPCwell then you're reinventing the wheel for something the service manager likely already has, potentially adding points of failure jailsnot quite the same thing but I'll let it count because i'm not quite familiar with their limitations but the timer doesn't do this it does because a timer runs a service and keeps track of each run and its result. i wasn't aware it can be used in other ways than in conjunction with units if it crashes too often that's a setting (with conditions for different failure modes and what is considered a failure) and this is also desired behavior in many cases

   • Embed this notice
     feld (feld@friedcheese.us)'s status on Saturday, 07-Sep-2024 23:27:38 JST feld

     in reply to

     • miauz genyau
     @mia Jails are a complete process namespace and also isolate SHM/SysV IPC, entire network stack if you want, drop privs, reduce all access to things like sysctls, block mounting, etc etc. It's all the different namespace / cgroups stuff you have to piece together in Linux in one framework
   • Embed this notice
     miauz genyau (mia@movsw.0x0.st)'s status on Saturday, 07-Sep-2024 23:35:20 JST miauz genyau

     in reply to

     @feld in practice, systemd just does a very good job at fulfilling that role on a system that is as poorly designed for modern computing as linux and basically everything else with 1970s/1980s heritage
     
     we know how to build better things in terms of security, reliability, simplicity, scalability, flexibility and maintainability, but we can't do it because it'd uproot almost every software and hardware ecosystem :pensive_bread:

     feld likes this.