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.
> 
> 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:
> 
> v247:
>>         * Timer units gained a new FixedRandomDelay= boolean setting. If
>>           enabled, the random delay configured with 
>> RandomizedDelaySec= is
>>           selected in a way that is stable on a given system (though 
>> still
>>           different for different units).
> 
> 
> and from the man page
> 
>>        RandomizedDelaySec=
>>            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
>>            modified with FixedRandomDelay=, see below.
>>
>>            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.
>>
>>        FixedRandomDelay=
>>            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
>>            similarly configured timers.
>>
>>            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.
-------------- 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/525e1c35/attachment-0001.sig>