This appears to have no syntax for X minutes past the hour, and the like. Even more than cron, this would encourage writing a thundering horde of jobs that all trigger at midnight?
Cron's syntax lets you easily calculate the next time a job will have to be run (rather than eg re-checking schedules each second, as in the earliest crons). However, exact timing isn't always necessary or desirable - eg in this case, encouraging all users to run jobs at exactly the same time.
I wonder if there is room in the plethora of cron alternatives for one whose syntax encouraged users to schedule jobs eg 'overnight' and left it up to a scheduler to spread jobs evenly? So eg, 'every hour' actually meant 45-75 minutes between executions.
Something similar happened with g_timeout_add_seconds and tickless idle; there the idea was to gather scheduled events to clock second boundaries, to avoid cpu wakeups-because really, users didn't care that they needed the timer to run exactly n seconds from now.
You can implement crons level of timing specificity with a few "every" jobs and some variables.
e.g. (not real syntax)
every minute: set minute = (minute + 1) % 60
when minute = 4 && day = 5 ...
I think the better part of this system is the cascading success semantics that it would provide, where by a next stage doesn't start if the previous stage didn't finish successfully. This has a lot of overlap with Jenkins and other CI servers, but without the java/http overhead and with a (potentially) lighter weight text based syntax for specifying the dependencies between jobs.
I can even envision this sort of system to be used to distribute jobs to slave machines given a small amount of ssh foo.
Interesting, but I am not sure that script dependency needs to be in a cron-like tool.
I've always thought that once you start needing such functionality then it's better that you move your logic to your scripts or timed-tasks system. Because soon, setting variables won't be enough and you're implementing hacks on top of hacks.
As of systemd 197, the timer units now support calendar based events which makes it a pretty full replacement for cron: http://lwn.net/Articles/531850/
4 comments
[ 4.5 ms ] story [ 18.9 ms ] threadCron's syntax lets you easily calculate the next time a job will have to be run (rather than eg re-checking schedules each second, as in the earliest crons). However, exact timing isn't always necessary or desirable - eg in this case, encouraging all users to run jobs at exactly the same time.
I wonder if there is room in the plethora of cron alternatives for one whose syntax encouraged users to schedule jobs eg 'overnight' and left it up to a scheduler to spread jobs evenly? So eg, 'every hour' actually meant 45-75 minutes between executions.
Something similar happened with g_timeout_add_seconds and tickless idle; there the idea was to gather scheduled events to clock second boundaries, to avoid cpu wakeups-because really, users didn't care that they needed the timer to run exactly n seconds from now.
e.g. (not real syntax)
I think the better part of this system is the cascading success semantics that it would provide, where by a next stage doesn't start if the previous stage didn't finish successfully. This has a lot of overlap with Jenkins and other CI servers, but without the java/http overhead and with a (potentially) lighter weight text based syntax for specifying the dependencies between jobs.I can even envision this sort of system to be used to distribute jobs to slave machines given a small amount of ssh foo.
I've always thought that once you start needing such functionality then it's better that you move your logic to your scripts or timed-tasks system. Because soon, setting variables won't be enough and you're implementing hacks on top of hacks.