It would be useful if timer units could be delayed randomly within, or spread out evenly across, a given interval starting at the time specified in the OnCalendar/etc. setting. This would help to spread out I/O intensive jobs and avoid disk thrashing.
In some discussions, the AccuracySec setting has been suggested as the equivalent to cron’s random delay feature, but as the man page says, the AccuracySec delay is synchronized across all timers, so that jobs will still launch in parallel.
systemd could compute a random factor using the host + job ID as a seed
for AccuracySec or for something new ("AccuracySec2" ? I have no idea)
Any news on that?
Does anybody has workaround?
This would indeed be useful as it would eliminate the need for the usual sleep $RANDOM semantics that is used in load-generating cron jobs.
If a lot of VMs start running their cron jobs in parallel, this generates a painful load spike on the VM host that could be mitigated by adding some randomness. Please consider implementing this.
This has been implemented a while back with RandomDelaySec=
(In reply to Lennart Poettering from comment #4)
> This has been implemented a while back with RandomDelaySec=
I may have misunderstood something here but...
This was originally submitted as RandomDelaySec= (2015-11-19):
however, it was then renamed to RandomizedDelaySec= (2015-11-27):
The online man page for systemd.timer currently uses RandomSec= (2016-02-02):
however, the 'random' feature narrowly missed the 228 release (2015-11-18) so it's not in the current versions man page.
Any help in clearing this up would be greatly appreciated, it would be great to get ahead of 229!
It got renamed in git:
The final name is RandomizedDelaySec=.
Sorry for the confusion.