Re: Should we add jitter to cron(8) ?

On 05/11/2026 16:28, Darren Henderson wrote:
> Considering POLA I believe it would be better as an opt-in kind of thing 
> rather than opt-out. If people need it they can enable it. In general 
> opt-out changes should be avoided. Just flipping this around is likely 
> to cause many many unexpected issues for people who are not paying close 
> attention.

Given the POLA concerns raised, I have an alternative idea:
fixed per-host offset instead of per-run random jitter.

  - cron derives a constant offset in the range 0-59 seconds from a hash 
of kern.hostuuid (plus hostname, to cope with cloned VMs and jails 
sharing the same hostuuid). Optionally, the user can override it with a 
fixed value via cron_flags in rc.conf
  - All jobs on the host are shifted by that offset, so a */5 job with 
e.g. 23s offset runs at 00:00:23, 00:05:23, 00:10:23, ...
  - @reboot and @every_second are not affected

For the power grid the effect should be the same as jitter. The 
important is the distribution across the population of machines, not 
across individual runs on one machine.

Compared to -j / -J it has several advantages:

  - intervals stay exact (*/5 is always 300s apart)
  - no "every minute job runs twice within a few seconds" anomaly, the 
full 0-59s range can be used
  - predictable timestamps in logs
  - relative spacing between jobs on a host is preserved

Because schedules stay regular, this would be a less surprising 
candidate for a default than random jitter.

Possible variant is a per-job offset, hashed from hostuuid and the 
crontab entry, which would also spread jobs on a single host. Systemd 
does something similar with RandomizedDelaySec= combined with 
FixedRandomDelay=, derived from the machine-id.

It would need a new option (e.g. -t offset) and a code change. I suspect 
it would be a small one, shifting cron's notion of "virtual time" in the 
main loop, but I haven't looked closely.

I'm not arguing against -j / -J, it works today without any code change. 
I just wanted to mention this alternative as a possibly less
surprising option.
I'll leave it up to others to decide whether this should be the default 
behavior.

Best regards
Miroslav Lachman


> On Wed, Nov 4, 2026 at 5:14 PM Poul-Henning Kamp <phk@phk.freebsd.dk 
> <mailto:phk@phk.freebsd.dk>> wrote:
> 
>     It seems that we have solid consensus for jittering by default, with
>     option to disable.
> 
>     I had not spotted the -j/-J options to cron before I raised the
>     issue, but given those, I dont see neither an need for code changes
>     nor bike-sheds about their syntax.
> 
>     It is of course mathematically ideal to jitter [0…59[ seconds.
> 
>     But that would lead to some anomalies which I would rather avoid,
>     for instance a "every minute" job being called twice within a few
>     seconds.
> 
>     In power grids the relevant regulation time constants are typically
>     below 10 and almost always less than 15 seconds.
> 
>     So on balance, I propose we change the cron default arguments to include
> 
>              -j 20 -J 20
> 
>     That way there will be at least 40 seconds between "once per minute
>     jobs".
>