On Wed, Oct 27, 2021 at 09:50:39PM +0200, Michael Biebl wrote: > On 27.10.21 21:42, Michael Biebl wrote: > > Possibly related > > https://github.com/systemd/systemd/pull/11608 > > The commit message explains it rather well: > > https://github.com/systemd/systemd/pull/11608/commits/a87c1d3a979f8c2641471bed93577558a1027a24 > > > core: delay persistent timers by "RandomizedDelaySec=" at boot. > > Fixes #5659. > > Currently, if Persistent=true and the machine is off at the scheduled time > > of the timer unit, the timer > > will be triggered immediately at the next boot even if RandomizedDelaySec= > > is specified. > > > > As a result, if multiple timers meet that condition, they will be triggered > > at the same time and too > > much CPU/IO work makes boot slow down. > > > > With this commit, if the scheduled time of the persistent timer has already > > elapsed at boot, > > set the time when systemd first started as the scheduled time and > > RandomizedDelaySec= is applied to it. >
I believe that on the one hand this is a significant improvement for us, as the old situation meant that all your containers would run unattended-upgrades at boot which was a terrible experience. Or was it at resume where I always had problems with it? But users not getting their systems updated once a day is a major concern as well. Unfortunately the answer is hard: You might only resume your laptop for 5 minutes a day, so even a RandomizedBootDelaySec option would not help if we'd set it to 30 min (I assume resume acts the same way as boot? I have not used either in a long time with timers). Need to think more, but certainly not running directly at boot is something we actively want. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en