Bug#997943: systemd: Persistent attribute of timer is ignored

[Julian Andres Klode]

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