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.
OpenPGP_signature
Description: OpenPGP digital signature
