Namaste Andreas, > Sent: Friday, April 17, 2020 at 8:53 AM > From: "Andreas Kusalananda Kähäri" <andreas.kah...@abc.se> > To: "Janne Johansson" <icepic...@gmail.com> > Cc: "openbsd-misc" <misc@openbsd.org> > Subject: Re: Regarding randomized times in crontab > > On Fri, Apr 17, 2020 at 09:06:10AM +0200, Janne Johansson wrote: > > Den tors 16 apr. 2020 kl 20:22 skrev Andreas Kusalananda Kähäri < > > andreas.kah...@abc.se>: > > > > > On Thu, Apr 16, 2020 at 11:14:59AM -0600, Theo de Raadt wrote: > > > > That is a lot of words to cover a simple concept: > > > > > > > > The specific random values are selected when cron(5) loads > > > > the crontab file. New numbers are chosen when crontab -e is used. > > > > If you understand that, the conclusions are obvious. > > > > > > Ah. Good. Then I know the restrictions. The random times are random, > > > but fixed for the lifetime of the cron daemon (or until the crontab is > > > reloaded due to being edited). > > > > > > > It would be very weird otherwise, if the 24h random example was used, then > > it chose 00:01, > > ran your "bin/true" command and then re-randomized, it would most certainly > > end up wanting > > to run again, perhaps twice or more. So if it re-randomized after each > > execution > > it would have to keep a 24h timer going (in your example, a per-week, a > > per-month timer also) > > to make sure the newly randomized 11:12 time is actually tomorrows 11:12 > > and not the upcoming > > one in this day. Also, re-randomization would also mean it could start your > > one hour backup at 23:59 > > and once more in 00:01 the next day, which would cause lots of unexpected > > chaos for anyone expecting > > a daily one-hour job to not collide with itself. > > Well, not weird but unexpected if you didn't think about it when you > picked the randomized time intervals. The issue with overlapping jobs > could be sorted out fairly easily with manual locking, or with the -s > crontab(5) feature that I saw a patch for on the tech list recently. > > I suppose there is no technical issue with actually re-randomizing the > picking of the time whenever a job is about to enter the time frame of > when the if would possibly start (not directly after each execution, > obviously). That would have the same effect as delaying the job with > sleep and $RANDOM.
Tusen tack for asking this question. After seeing your mail, I looked at the manpage and incorrectly inferred the "~" as a replacement of the sleep and RANDOM combination. The examples and Theo's reply helped in understanding the nuance. It might seem logical and common sense on further thought, as Janne has pointed out. But at least in my case, it was not immediately apparent. > > -- > > May the most significant bit of your life be positive. > > :-) > > -- > Andreas (Kusalananda) Kähäri > SciLifeLab, NBIS, ICM > Uppsala University, Sweden > > . Dhanyavaad, ab ---------|---------|---------|---------|---------|---------|---------|--
