On 28.10.21 09:05, Hendrik Buchner wrote:
Hello Michael and Julian,

that explains why the behaviour of "RandomizedDelaySec" together with
"Persistent" is different between buster and bullseye. If that's the
intended behaviour, my systems seems to work like they should and it's
no bug.

It's definitely a change of behaviour I wasn't aware of myself.

While it fixes the thundering herd issue during boot, it is definitely problematic that for systems that aren't up for a longer period of time, a timer with a large RandomizedDelaySec= will basically never fire.

I do think that we have a similar thundering herd issue with timers that elapse while the system is suspended and ttbomk, systemd will *not* reapply a RandomizedDelaySec= on resume.

This appears to be inconsistent imho.

Somehow I think systemd could be more clever here and scale down RandomizedDelaySec= on boot depending on how far in the past the timestamp of the stampfile is. Say the last activation of the service was 12 hours ago, then scale down RandomizedDelaySec=12h by dividing it by 12, so it would become RandomizedDelaySec=1h. The further in the past, the shorter the delay would become and the more likely that the timer fires eventually.

And for consistencies sake, a (scaled) RandomizedDelaySec=1 should also be reapplied on resume.



Regards,
Michael

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to