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

[Michael Biebl]

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.



-------------- 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/43a0c4fa/attachment.sig>