summaryrefslogtreecommitdiff
path: root/man/systemd.timer.xml
diff options
context:
space:
mode:
authorLuke Shumaker <lukeshu@sbcglobal.net>2016-06-09 02:37:33 -0400
committerLuke Shumaker <lukeshu@sbcglobal.net>2016-06-09 02:37:33 -0400
commitf6e7ffdf3fe8e3ed5e659f747946461350ade5a8 (patch)
treed261964cafdd51154b1ad757574f508da2d9ad76 /man/systemd.timer.xml
parent566cac15ed36506e2bb766313a5d4e0825bc6499 (diff)
parent022ed72eff07ca6c1409747e774ef5b35724c9df (diff)
Merge tag 'v230-3.parabola1' into parabola
Diffstat (limited to 'man/systemd.timer.xml')
-rw-r--r--man/systemd.timer.xml35
1 files changed, 18 insertions, 17 deletions
diff --git a/man/systemd.timer.xml b/man/systemd.timer.xml
index 29e235e2dc..0fa95e97a8 100644
--- a/man/systemd.timer.xml
+++ b/man/systemd.timer.xml
@@ -73,6 +73,12 @@
<filename>foo.timer</filename> activates a matching service
<filename>foo.service</filename>. The unit to activate may be
controlled by <varname>Unit=</varname> (see below).</para>
+
+ <para>Note that in case the unit to activate is already active at the time the timer elapses it is not restarted,
+ but simply left running. There is no concept of spawning new service instances in this case. Due to this, services
+ with <varname>RemainAfterExit=</varname> set (which stay around continously even after the service's main process
+ exited) are usually not suitable for activation via repetitive timers, as they will only be activated once, and
+ then stay around forever.</para>
</refsect1>
<refsect1>
@@ -81,21 +87,15 @@
<para>Timer units automatically gain a <varname>Before=</varname>
dependency on the service they are supposed to activate.</para>
- <para>Unless <varname>DefaultDependencies=</varname> is set to
- <option>false</option>, all timer units will implicitly have
- dependencies of type <varname>Requires=</varname> and
- <varname>After=</varname> on <filename>sysinit.target</filename>,
- a dependency of type <varname>Before=</varname> on
- <filename>timers.target</filename>, as well as
- <varname>Conflicts=</varname> and <varname>Before=</varname> on
- <filename>shutdown.target</filename> to ensure that they are
- stopped cleanly prior to system shutdown. Timer units with at
- least one <varname>OnCalendar=</varname> directive will have an
- additional <varname>After=</varname> dependency on
- <filename>timer-sync.target</filename> to avoid being started
- before the system clock has been correctly set. Only timer units
- involved with early boot or late system shutdown should disable
- the <varname>DefaultDependencies=</varname> option.</para>
+ <para>Unless <varname>DefaultDependencies=</varname> in the <literal>[Unit]</literal> section is set to
+ <option>false</option>, all timer units will implicitly have dependencies of type <varname>Requires=</varname> and
+ <varname>After=</varname> on <filename>sysinit.target</filename>, a dependency of type <varname>Before=</varname>
+ on <filename>timers.target</filename>, as well as <varname>Conflicts=</varname> and <varname>Before=</varname> on
+ <filename>shutdown.target</filename> to ensure that they are stopped cleanly prior to system shutdown. Timer units
+ with at least one <varname>OnCalendar=</varname> directive will have an additional <varname>After=</varname>
+ dependency on <filename>timer-sync.target</filename> to avoid being started before the system clock has been
+ correctly set. Only timer units involved with early boot or late system shutdown should disable the
+ <varname>DefaultDependencies=</varname> option.</para>
</refsect1>
<refsect1>
@@ -259,7 +259,8 @@
during the time when the timer was inactive. This is useful to
catch up on missed runs of the service when the machine was
off. Note that this setting only has an effect on timers
- configured with <varname>OnCalendar=</varname>.
+ configured with <varname>OnCalendar=</varname>. Defaults
+ to <varname>false</varname>.
</para></listitem>
</varlistentry>
@@ -287,7 +288,7 @@
starting a timer unit that only elapses once: if
<varname>RemainAfterElapse=</varname> is on, it will not be
started again, and is guaranteed to elapse only once. However,
- if <varname>RemainAfterLeapse=</varname> is off, it might be
+ if <varname>RemainAfterElapse=</varname> is off, it might be
started again if it is already elapsed, and thus be triggered
multiple times. Defaults to
<varname>yes</varname>.</para></listitem>