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:
parent
766f8f388f
commit
5501da15ba
|
@ -297,9 +297,10 @@
|
||||||
|
|
||||||
<listitem><para>Takes a boolean argument. If true, the time when the service unit was last triggered
|
<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
|
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
|
would have been triggered at least once during the time when the timer was inactive. Such triggering
|
||||||
to catch up on missed runs of the service when the system was powered down. Note that this setting
|
is nonetheless subject to the delay imposed by <varname>RandomizedDelaySec=</varname>.
|
||||||
only has an effect on timers configured with <varname>OnCalendar=</varname>. Defaults to
|
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>
|
<varname>false</varname>.</para>
|
||||||
|
|
||||||
<para>Use <command>systemctl clean --what=state …</command> on the timer unit to remove the timestamp
|
<para>Use <command>systemctl clean --what=state …</command> on the timer unit to remove the timestamp
|
||||||
|
|
Loading…
Reference in New Issue