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

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 Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF