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). And for Raul, yes I'm aware that randomly picked value can be the same as the last randomly picked value, but for most types of house keeping tasks, the quality of "random" is less interesting. You are however correct in that my question wasn't totally coherent, but at least Theo got my drift. Cheers, > > > Raul Miller <rauldmil...@gmail.com> wrote: > > > That's a poorly phrased question, to be honest. > > > > In one sense the point in time where the job is scheduled has to be > > different -- it's a point in time in a different 24 hour period. > > > > But in another sense (a sense closer to what you probably intended) > > the point in time can't be guaranteed to be different. There's a > > finite number of minutes in a day and picking one pseudo-randomly > > would occasionally collide. Consider, as an extreme example, a system > > which reboots often and is only up for 1 minute every 24 hour period. > > > > But, such collisions should be rare, and that specific extreme case > > example was ludicrous. > > > > Anyways, on a normally operating machine, you should expect the same > > minute to be used slightly more often than once every four years. And, > > a difference less than 2 minutes would happen more often (around once > > a year, depending on exactly where you draw the line). > > > > But, if you don't trust what I have said here (and maybe you should > > not) what you really want to understand is the algorithm being used, > > and the best way to discover that is to look at the implementation. > > https://www.openbsd.org/anoncvs.html -- Specifically, you'll want to > > look at the implementation of get_range() in usr.sbin/cron/entry.c > > > > FYI, > > > > > > -- > > Raul > > > > On Thu, Apr 16, 2020 at 12:41 PM Andreas Kusalananda Kähäri > > <andreas.kah...@abc.se> wrote: > > > > > > Thanks for that! > > > > > > Also, considering a job scheduled like > > > > > > ~ ~ * * * somecommand > > > > > > I'm assuming, provided that the cron daemon is not restarted, this would > > > run the job at a single random point in each 24h period, right? A > > > *different* point in time, each 24 period? > > > > > > > > > > > > On Thu, Apr 16, 2020 at 10:28:34AM -0600, Theo de Raadt wrote: > > > > Yes. > > > > > > > > But that problem already existed with the minutes field being >close to > > > > the moment cron was restarted. > > > > > > > > Only difference is now you don't know the minute. > > > > > > > > > > > > Andreas Kusalananda Kähäri <andreas.kah...@abc.se> wrote: > > > > > > > > > Thanks for the ~ crontab(5) feature! > > > > > > > > > > Question: If the cron daemon is restarted (e.g. via reboot) during the > > > > > interval during which a cron job may be randomly triggered, is there a > > > > > risk (or even guarantee) that the job may run a second time? > > > > > > > > > > > > > > > Regards, > > > > > > > > > > -- > > > > > Andreas (Kusalananda) Kähäri > > > > > SciLifeLab, NBIS, ICM > > > > > Uppsala University, Sweden > > > > > > > > > > . > > > > > > > > > > > -- > > > Andreas (Kusalananda) Kähäri > > > SciLifeLab, NBIS, ICM > > > Uppsala University, Sweden > > > > > > . > > > > > -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
