On 2026-Nov-02 11:25:49 +0000, Poul-Henning Kamp <[email protected]> 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
An unwanted side-effect of precise time now being easily available (and hence the default) everywhere :-). There have been past issues with synchronized wakeups from mobile phones causing network spikes. >That indicates that we should add jitter to cron(8). Agreed. >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. In the long term, I agree - I'd suggest that 16-RELEASE be either A or C. I'm not sure A could be MFC'd, though B definitely could be. OTOH, I'm loath to suddenly make a significant change to cron behaviour - I'm confident that there are systems somewhere that depend on the current behaviour - which suggests that C should be implemented. Overall, I'd suggest implementing B to start with (so jitter is optional) and MFC'ing it, then later flipping the default in -CURRENT to A (and maybe implementing C if people find a need for it). As a related issue, should we also come up with a cron syntax that is less precise about when a task runs - currently the "@" variants specify that they run at the start of whatever period is specified. IMO, it would be useful to have a way of saying e.g. "run once an hour but I don't care when within the hour". -- Peter Jeremy
signature.asc
Description: PGP signature
