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

[Michael Biebl]

Hello once again

On 27.10.21 20:17, Michael Biebl wrote:
> On 27.10.21 16:05, Hendrik Buchner wrote:
>> Hello Michael,
>>
>> my system isn't running on battery because it's a Desktop-PC and not a
>> laptop. I've observed this behaviour now on 3 of my computers (2
>> Desktop-PCs and 1 laptop).
>>
> 
> Just to recap here:
> - Is this issue only reproducible with apt-daily.timer and 
> apt-daily-upgrade.timer works correctly?
> - Does this issue happen reproducibly?
> Say "systemctl status apt-daily.timer" shows that the timer is about to 
> elapse in 5 hours. If you shut down the system before that and start it 
> after that, apt-daily.service is not run with 100% certainty?
> 

So, I reread the documentation:

>        Persistent=
>            Takes a boolean argument. If true, the time when the service unit was last triggered is stored on disk. When the timer is activated, the service
>            unit is triggered immediately if it would have been triggered at least once during the time when the timer was inactive. Such triggering is
>            nonetheless subject to the delay imposed by RandomizedDelaySec=. This is useful to catch up on missed runs of the service when the system was
>            powered down.

Looking at /var/lib/systemd/timers/ you should be able to see a stamp 
file which indicates, when the corresponding service was last activated. 
This is true in my case.

Important is this sentence:
"Such triggering is nonetheless subject to the delay imposed by 
RandomizedDelaySec="

Keep in mind that RandomizedDelaySec= is not stored on disk, only the 
timestamp of the last execution.

So, let's assume the service was last triggered 2 days ago and you shut 
down the system yesterday. You boot the system this morning at 9:00, so 
the timer has elapsed. But a RandomizedDelaySec= is applied, which is 
computed dynamically. Let's say the delay is 7 hours. If you shut down 
the system before that, your service won't be executed.
The next day when you start your system again, systemd will notice 
again, that the timer has elapsed and again will apply a 
RandomizedDelaySec=12h, in this case maybe 9 hours.
If you only ever use your system for a very short period of time, this 
would mean that you never actually see the service being executed.
A RandomizedDelaySec=12h is rather large, if you run your system for 
only 6 hours a day, you have a chance of hitting the timer by 50% I'd say.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20211027/eb4d9d81/attachment.sig>