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

[Michael Biebl]

On 27.10.21 21:19, Michael Biebl wrote:
> 
> 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.

Possibly related
https://github.com/systemd/systemd/pull/11608
-------------- 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/f3714f9a/attachment.sig>