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 <[email protected]
<mailto:[email protected]>> 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".
