Am 2026-11-02 12:56, schrieb Miroslav Lachman:
On 02/11/2026 12:25, Poul-Henning Kamp wrote:Embedded systems using cron(8) are starting to cause macroscopic effects at the top of the minute:https://www.fz-juelich.de/en/news/archive/press-release/2026/mystery-of-60-second-fluctuations-in-power-grids-solved That indicates that we should add jitter to cron(8). I can see three ways to do it: A) By default cron(8) waits [0...N] seconds before executing commands. This can be disabled with a command line option. For a number of reasons which we can hash later, I suggest N=30 B) Same as A), but the command line option enables jitter. C) Same as A), but with additional crontab(5) syntax to say "dont jitter this particular entry". I would argue that A is the proper choice. Comments ?We already have that. Or do you mean something else? -j jitter Enable time jitter. Prior to executing commands, cron will sleep a random number of seconds in the range from 0 to jitter. This will not affect superuser jobs (see -J). A value for jitter must be between 0 and 60 inclusive. Default is 0, which effectively disables time jitter. This option can help to smooth down system load spikes during moments when a lot of jobs are likely to start at once, e.g., at the beginning of the first minute of each hour. -J rootjitter Enable time jitter for superuser jobs. The same as -j except that it will affect jobs run by the superuser only. cron_flags="-j 20 -J 20" in rc.conf should do the trick
Adding to that:- POLA (I can easily imagine how this breaks stuff, I paid attention on my system a time drift or load spike induced delay doesn't, but in general I would bet this can cause problems). - It always comes down to the choice of a human. I always try to schedule at random times and not at the usual suspects like "00" or multiples of 5 or 10. - Do we expect that those jobs use cron? Or asked differently: why do you think it will matter in the big picture?
By using A you enforce policy. In the past we didn't want to do that.We already have B. There's also option D, having two new options: one to ensure jitter, and one to disable jitter. With B+D it's up to the admin to set the policy.
Bye, Alexander. -- http://www.Leidinger.net [email protected]: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org [email protected] : PGP 0x8F31830F9F2772BF
signature.asc
Description: OpenPGP digital signature
