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

[Hendrik Buchner]

>Is this issue only reproducible with apt-daily.timer and
>apt-daily-upgrade.timer works correctly?

I think so, but I will observe it for the next days.

>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?

Yes, that's correct.

>Can you mark in the log, when you upgraded your system

I think it was at 15. August, one day after bullseye was released.

>at what times you shutdown/started the system and where exactly you
>expected the timer to fire

That's different, but it's easy to see when you compare both logs. As
you can see the last execution of "apt-daily" was "Okt 24 19:34:45".
In the log of "apt-daily-upgrade" you see that the system was running
at "Okt 25 16:08:30" and "Okt 26 21:10:30" and "Okt 27 15:45:00".
So with the options of "apt-daily.timer" (OnCalendar=*-*-* 6,18:00
RandomizedDelaySec=12h) it should have been executed since then because
there were missed timers.
For normal the computer is not running for only 1 minute so that
the timespan is too short for execution (apt-daily-upgrade had also
enough time for execution).