4 ms·

Sounds like systemd timers tick many of your boxes, maybe not all, but that’s the system I’d be most optimistic for to a as actually implement these…

• bongobingo1 3y ago
  1) time window (e.g. only run between 1am and 3am on weekdays) Should just be `OnCalendar` in the timer. 2) periodicity (if job was successful, next run is X time away) Not sure if this is specified as 1 && 2, or 1 || 2. 1 or 2 is pretty easy, 1 and 2 I think requires two timers, a "run-on-sunday" that then enables the "now run every 20 minutes" timer. Both do-able though. 3) retry period (if job failed, retry after X time) Unit files should already do this, but it will be disconnected from the timer, the unit can retry every 10 minutes if it fails, up to 5 times, but AFAIK the timer wont check the status of the service before running. BUT I also think you can configure the unit to only run once so depending on your setup it would either not duplicate the service, or you would have killed it before the next timer. 4) job timeout (if job is still running after X time, kill it) JobTimeoutSec, (also JobTimeoutAction might be useful). 5) start randomization (randomize start up to X time in window) RandomizedDelaySec 6) job dependencies (don't run job Y until job Z has finished successfully) 7) job anti-dependencies (don't run job Y while job Z is active) I think you could do both of these, but it would probably be at the unit level, not the timer. I think properly configuring a "Z still running, try Y again in 2 minutes" might be hard or might not be, as systemd can queue jobs, I think it might just queue Y until it hits a timeout and kills it. I think you can actually achieve all this but might require a bit of setup building a graph that flips timers on or off but at its core I think all the "if x then y" bits exist. My major complaint against systemd is that its documentation is so complete, it becomes quite dense and you have to understand quite a lot of interconnected parts. "The problem is the problem" though, its complex because what it aims to do is complex. I am still positive on it as a whole though. You could also write a systemd generator to build all these files from a single specification.
  • tetha 3y ago
    > My major complaint against systemd is that its documentation is so complete, it becomes quite dense and you have to understand quite a lot of interconnected parts. "The problem is the problem" though, its complex because what it aims to do is complex. I am still positive on it as a whole though. Aye, that is a problem. We have like 3-4 recipes in our internal documentation of "Here are the 12 lines of systemd for each of the 9 things you need to do to solve 90% of your use cases". I might ask around if we could put this onto some public blog or something.
    • bravetraveler 3y ago
      Discoverability is such a thing. For example, which of these do I want?: man systemd.{exec,unit,service} It's not too bad to get a general feel for what's possible, but recalling where is frustrating. These three are so closely related they're notable. Others, like timers, are a little more obvious. I've settled on Ansible roles. I define the important bits and config mgmt does the rest
      • Bu9818 3y ago
        systemd.directives(7) is useful if you know what directive you want to read about but not in what manual it's in.
        • bravetraveler 3y ago
          Awesome, thank you! :D