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

[Michael Biebl]

On 27.10.21 21:05, Michael Biebl wrote:

On 27.10.21 20:47, Michael Biebl wrote:

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.

v247:

This would be consistent with your observation that by reducing RandomizedDelaySec= to 0h you are reliably triggering the timer. So, what you see is actually consistent with the documented behaviour I'd argue. Nonetheless, if I understand you correctly there is a difference of behaviour between buster and bullseye if I understand you correctly. I went through the changelog/NEWS file of systemd. This seems to be related:

        * Timer units gained a new FixedRandomDelay= boolean setting. If

          different for different units).

          enabled, the random delay configured with RandomizedDelaySec= is           selected in a way that is stable on a given system (though still

and from the man page

       RandomizedDelaySec=

           modified with FixedRandomDelay=, see below.





       FixedRandomDelay=

           similarly configured timers.

           Delay the timer by a randomly selected, evenly distributed amount of time between 0 and the specified time value.            Defaults to 0, indicating that no randomized delay shall be applied. Each timer unit will determine this delay            randomly before each iteration, and the delay will simply be added on top of the next determined elapsing time, unless            This setting is useful to stretch dispatching of similarly configured timer events over a certain time interval, to            prevent them from firing all at the same time, possibly resulting in resource congestion.            Note the relation to AccuracySec= above: the latter allows the service manager to coalesce timer events within a            specified time range in order to minimize wakeups, while this setting does the opposite: it stretches timer events            over an interval, to make it unlikely that they fire simultaneously. If RandomizedDelaySec= and AccuracySec= are used            in conjunction, first the randomized delay is added, and then the result is possibly further shifted to coalesce it            with other timer events happening on the system. As mentioned above AccuracySec= defaults to 1 minute and            RandomizedDelaySec= to 0, thus encouraging coalescing of timer events. In order to optimally stretch timer events over            a certain range of time, set AccuracySec=1us and RandomizedDelaySec= to some higher value.            Takes a boolean argument. When enabled, the randomized offset specified by RandomizedDelaySec= is reused for all            firings of the same timer. For a given timer unit, the offset depends on the machine ID, user identifier and timer            name, which means that it is stable between restarts of the manager. This effectively creates a fixed offset for an            individual timer, reducing the jitter in firings of this timer, while still avoiding firing at the same time as other            This setting has no effect if RandomizedDelaySec= is set to 0. Defaults to false.

I'm putting Julian (the maintainer of apt and therefor apt-daily.timer) into the loop here. Julian, please have a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997943#42 and

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997943#47

What were your expectations regarding the timer and the currently documented behavior? Afaics, Persistent=true is functional, but the behaviour of RandomizedDelaySec= changed slighly which might affect timers which chose a long delay.

OpenPGP_signature
Description: OpenPGP digital signature