5 ms·
For my own use cases, I've found that traditional cron timing specs don't match what I need from scheduled operations. I mainly care about two things: time wind
by tremon 3y ago
For my own use cases, I've found that traditional cron timing specs don't match what I need from scheduled operations. I mainly care about two things: time window and periodicity -- and while it's possible to express both in the same cron timestamp, it's both too specific and not specific enough. I don't see this post making a clear argument about their functional requirements, just that fcron satisfies more technical requirements than Vixie cron.
But going in full "I want a pony"-mode: over the years, I've needed the following features from a job scheduling system:
1) time window (e.g. only run between 1am and 3am on weekdays)
2) periodicity (if job was successful, next run is X time away)
3) retry period (if job failed, retry after X time)
4) job timeout (if job is still running after X time, kill it)
5) start randomization (randomize start up to X time in window)
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)
FAFAIK, Vixie cron only allows 1 and 2; 4 can be done with coreutils' timeout (don't know if it's a POSIX command or only GNU), and 5 can be done with something like sleep $RANDOM, but the time spent waiting is added to the job's runtime -- which means that you no longer can create useful reports about job processing times. Of this list, fcron only adds nicer syntax, and 5 is built-in. It can kinda do 7, but serial is a global exclusion. If it were possible to make exclusion groups (e.g. job Y and Z have serial(1), job X has serial(2), and user's fcrontab has serial($UID)), that would be much nicer.
I acknowledge that Cron was never meant to solve 6 and 7, but it's still a feature that I require regularly in my systems. But I don't understand why 3 (explicit retries) was never implemented in any cron replacement, even systemd timers don't have it, at least I'm not aware of it (RestartSec is for services only).
- 9dev 3y agoSounds 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 ago1) 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 agoDiscoverability 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 agosystemd.directives(7) is useful if you know what directive you want to read about but not in what manual it's in.
- bravetraveler 3y agoAwesome, thank you! :D
- simpaticoder 3y agoSounds like a local LLM, coupled with a periodic wake up signal, will be your pony. Presumably even a small one could run a schedule under those (very reasonable) constraints. Maybe not general pathological cases, but ordinary cases. You'd probably want things to run in one big prompt over time and the tricky part would be finding the minimum size required to properly execute the schedule. Too small, and it loses knowledge of the past. Too large, and it won't function at all. EDIT: I believe in sysadmin llms and think they will become common and obvious in the next few years. I will look back at the downvotes on this comment with great pride. So, thanks and keep them coming!
- Hendrikto 3y agoI hope you are not serious…
- simpaticoder 3y agoI am serious. It may seem like killing a fly with a sledge-hammer, but a local llm sysadmin process has a lot of application apart from cron. The ability to simply talk about your processes in natural language is a huge bonus to those who don't do sysadmin daily - which is most of us. Obviously, using an llm is not appropriate where size and precision are required. In that case use cron and accept its limitations.
- yjftsjthsd-h 3y ago> It may seem like killing a fly with a sledge-hammer, It really does. > but a local llm sysadmin process has a lot of application apart from cron. The problem is that I trust it with none of them; I've seen even humans make mistakes that led to data loss, and I trust machines less than that.
- tannhaeuser 3y ago5 is an odd requirement potentially better implemented outside cron, such as with a single line of shell code involving the "at" command (and "expr" to scale a /dev/random value). 4, 6, 7 gets you into "enterprise" (not the StarTrek thing;) territory. Think about it: how to represent that a job has or hasn't finished successfully? Using a process return status, or maybe something more persistent, restartable, or federated and independent of a PID eg. a state stored in a database, which involves further design trade offs such as transactional isolation, locking, eventual consistency, etc.
- chasil 3y agoI know that our OS2200 machines use "Opcon XPS" for scheduling, but I don't know anything about it. They have occasionally advocated that we migrate our crontabs. https://smatechnologies.com/products-opcon-automation https://smatechnologies.com/products-opcon-automation
- Dylan16807 3y ago> 5 is an odd requirement potentially better implemented outside cron, such as with a single line of shell code involving the "at" command (and "expr" to scale a /dev/random value). I'm very surprised you think that. I would say that the job scheduler is the perfect place to randomize start times.
- tannhaeuser 3y agoWhy? Starting a process at random seems like a one off thing.
- Dylan16807 3y agoIf it's a one-off then you rarely need randomization. For scheduled tasks, you often want randomization so that your fleet of servers is not all doing the task at the exact same time. Think "start between 2am and 4am every day". You can work around it by picking an offset at install time like scheduling for 3:17am in particular on this server, or by putting a random sleep into the job, but both of those obfuscate the actual scheduling intent.
- maio 3y agoNot a Cron but tools like Jenkins or TeamCity will probably handle most if not all of these requirements.
- sashk 3y agoAt $job we are forced to use [Autosys Job Automation](https://techdocs.broadcom.com/us/en/ca-enterprise-software/intelligent-automation/autosys-workload-automation/12-0/release-notes/ae-release-12.html https://techdocs.broadcom.com/us/en/ca-enterprise-software/i...). It can handle everything except 5, I think. But that somewhat huge system which hardly can be called cron replacement.