man: document the random delay of persistent timers

The manual states that a persistent timer triggers it's service
immediately on activation to catch up with missed invocations, but since
PR #11608 it is no longer the case if RandomizedDelaySec= is set to a
non-zero value.
This commit is contained in:
Nazar Vinnichuk 2020-09-11 13:38:53 +03:00 committed by Zbigniew Jędrzejewski-Szmek
parent 766f8f388f
commit 5501da15ba
1 changed files with 4 additions and 3 deletions

View File

@ -297,9 +297,10 @@
<listitem><para>Takes a boolean argument. If true, the time when the service unit was last triggered
is stored on disk. When the timer is activated, the service unit is triggered immediately if it
would have been triggered at least once during the time when the timer was inactive. This is useful
to catch up on missed runs of the service when the system was powered down. Note that this setting
only has an effect on timers configured with <varname>OnCalendar=</varname>. Defaults to
would have been triggered at least once during the time when the timer was inactive. Such triggering
is nonetheless subject to the delay imposed by <varname>RandomizedDelaySec=</varname>.
This is useful to catch up on missed runs of the service when the system was powered down. Note that
this setting only has an effect on timers configured with <varname>OnCalendar=</varname>. Defaults to
<varname>false</varname>.</para>
<para>Use <command>systemctl clean --what=state …</command> on the timer unit to remove the timestamp