Hey,
this is a very clean solution to a very common problem that i have. A
lot of tasks that i run from cron have very different completion times.
Right now i use the -s [1] option in crontab to make sure only one task
is running at once and so that they don't overlap if they take longer to
complete than the interval i schedule them. But the problem with the -s
workflow is that the interval can get messed up if the interval is
smaller than the execution period. This will basically "skip" a run.
With your patch this can be avioded in a very clean way. I have your
patch a try and for my local testing usecase it worked as expected. This
would clean up a lot of things in my personal workflow. Thank you very
mich for the patch Job, much appreciated!
Thanks and greetings
Leo
[1] https://man.openbsd.org/crontab.5#s
On 10/07/2021 16:07, Job Snijders wrote:
The below patch adds a new kind of time specifier: an interval (in
minutes). When used, cron(8) will schedule the next instance of a job
after the previous job has completed and a full interval has passed.
A crontab(5) configured as following:
$ crontab -l
@3 sleep 100
Will result in this schedule:
Jul 10 13:38:17 vurt cron[96937]: (CRON) STARTUP (V5.0)
Jul 10 13:42:01 vurt cron[79385]: (job) CMD (sleep 100)
Jul 10 13:47:01 vurt cron[3165]: (job) CMD (sleep 100)
Jul 10 13:52:01 vurt cron[40539]: (job) CMD (sleep 100)
Jul 10 13:57:01 vurt cron[84504]: (job) CMD (sleep 100)
A use case could be running rpki-client more frequently than once an
hour:
@15 -n rpki-client && bgpctl reload
The above is equivalent to:
* * * * * -sn sleep 900 && rpki-client && bgpctl reload
I borrowed the idea from FreeBSD's cron [1]. A difference between the
below changeset and the freebsd implementation is that they specify the
interval in seconds, while the below specifies in minutes. I was able
to leverage the 'singleton' infrastructure. And removed a comment that
reads like a TODO nobody is going to do.
Thoughts?
