diff options
Diffstat (limited to '')
| -rw-r--r-- | man/systemd.timer.xml | 416 |
1 files changed, 416 insertions, 0 deletions
diff --git a/man/systemd.timer.xml b/man/systemd.timer.xml new file mode 100644 index 0000000..e5af7c0 --- /dev/null +++ b/man/systemd.timer.xml @@ -0,0 +1,416 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="systemd.timer" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>systemd.timer</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.timer</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.timer</refname> + <refpurpose>Timer unit configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>timer</replaceable>.timer</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A unit configuration file whose name ends in + <literal>.timer</literal> encodes information about a timer + controlled and supervised by systemd, for timer-based + activation.</para> + + <para>This man page lists the configuration options specific to + this unit type. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The timer specific configuration options are + configured in the [Timer] section.</para> + + <para>For each timer file, a matching unit file must exist, + describing the unit to activate when the timer elapses. By + default, a service by the same name as the timer (except for the + suffix) is activated. Example: a timer file + <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=yes</varname> set (which stay around continuously 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. Target units, which by default do not deactivate on their own, can be + activated repeatedly by timers by setting <varname>StopWhenUnneeded=yes</varname> on them. This will cause a + target unit to be stopped immediately after its activation, if it is not a dependency of another running unit.</para> + </refsect1> + + <refsect1> + <title>Automatic Dependencies</title> + + <refsect2> + <title>Implicit Dependencies</title> + + <para>The following dependencies are implicitly added:</para> + + <itemizedlist> + <listitem><para>Timer units automatically gain a <varname>Before=</varname> + dependency on the service they are supposed to activate.</para></listitem> + </itemizedlist> + </refsect2> + + <refsect2> + <title>Default Dependencies</title> + + <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para> + + <itemizedlist> + <listitem><para>Timer units will automatically 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. Only timer + units involved with early boot or late system shutdown should disable the + <varname>DefaultDependencies=</varname> option.</para></listitem> + + <listitem><para>Timer units with at least one <varname>OnCalendar=</varname> directive acquire a pair + of additional <varname>After=</varname> dependencies on <filename>time-set.target</filename> and + <filename>time-sync.target</filename>, in order to avoid being started before the system clock has + been correctly set. See + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details on these two targets.</para></listitem> + </itemizedlist> + </refsect2> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>Timer unit files may include [Unit] and [Install] sections, which are described in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>Timer unit files must include a [Timer] section, which carries + information about the timer it defines. The options specific to + the [Timer] section of timer units are the following:</para> + + <variablelist class='unit-directives'> + <varlistentry> + <term><varname>OnActiveSec=</varname></term> + <term><varname>OnBootSec=</varname></term> + <term><varname>OnStartupSec=</varname></term> + <term><varname>OnUnitActiveSec=</varname></term> + <term><varname>OnUnitInactiveSec=</varname></term> + + <listitem><para>Defines monotonic timers relative to different + starting points:</para> + + <table> + <title>Settings and their starting points</title> + + <tgroup cols='2'> + <thead> + <row> + <entry>Setting</entry> + <entry>Meaning</entry> + </row> + </thead> + <tbody> + <row> + <entry><varname>OnActiveSec=</varname></entry> + <entry>Defines a timer relative to the moment the timer unit itself is activated.</entry> + </row> + <row> + <entry><varname>OnBootSec=</varname></entry> + <entry>Defines a timer relative to when the machine was booted up. In containers, for the system manager instance, this is mapped to <varname>OnStartupSec=</varname>, making both equivalent.</entry> + </row> + <row> + <entry><varname>OnStartupSec=</varname></entry> + <entry>Defines a timer relative to when the service manager was first started. For system timer units this is very similar to <varname>OnBootSec=</varname> as the system service manager is generally started very early at boot. It's primarily useful when configured in units running in the per-user service manager, as the user service manager is generally started on first login only, not already during boot.</entry> + </row> + <row> + <entry><varname>OnUnitActiveSec=</varname></entry> + <entry>Defines a timer relative to when the unit the timer unit is activating was last activated.</entry> + </row> + <row> + <entry><varname>OnUnitInactiveSec=</varname></entry> + <entry>Defines a timer relative to when the unit the timer unit is activating was last deactivated.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>Multiple directives may be combined of the same and of different types, in which case the timer + unit will trigger whenever any of the specified timer expressions elapse. For example, by combining + <varname>OnBootSec=</varname> and <varname>OnUnitActiveSec=</varname>, it is possible to define a + timer that elapses in regular intervals and activates a specific service each time. Moreover, both + monotonic time expressions and <varname>OnCalendar=</varname> calendar expressions may be combined in + the same timer unit.</para> + + <para>The arguments to the directives are time spans + configured in seconds. Example: "OnBootSec=50" means 50s after + boot-up. The argument may also include time units. Example: + "OnBootSec=5h 30min" means 5 hours and 30 minutes after + boot-up. For details about the syntax of time spans, see + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + + <para>If a timer configured with <varname>OnBootSec=</varname> + or <varname>OnStartupSec=</varname> is already in the past + when the timer unit is activated, it will immediately elapse + and the configured unit is started. This is not the case for + timers defined in the other directives.</para> + + <para>These are monotonic timers, independent of wall-clock time and timezones. If the computer is + temporarily suspended, the monotonic clock generally pauses, too. Note that if + <varname>WakeSystem=</varname> is used, a different monotonic clock is selected that continues to + advance while the system is suspended and thus can be used as the trigger to resume the + system.</para> + + <para>If the empty string is assigned to any of these options, the list of timers is reset (both + monotonic timers and <varname>OnCalendar=</varname> timers, see below), and all prior assignments + will have no effect.</para> + + <para>Note that timers do not necessarily expire at the + precise time configured with these settings, as they are + subject to the <varname>AccuracySec=</varname> setting + below.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>OnCalendar=</varname></term> + + <listitem><para>Defines realtime (i.e. wallclock) timers with calendar event expressions. See + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + more information on the syntax of calendar event expressions. Otherwise, the semantics are similar to + <varname>OnActiveSec=</varname> and related settings.</para> + + <para>Note that timers do not necessarily expire at the precise time configured with this setting, as + it is subject to the <varname>AccuracySec=</varname> setting below.</para> + + <para>May be specified more than once, in which case the timer unit will trigger whenever any of the + specified expressions elapse. Moreover calendar timers and monotonic timers (see above) may be + combined within the same timer unit.</para> + + <para>If the empty string is assigned to any of these options, the list of timers is reset (both + <varname>OnCalendar=</varname> timers and monotonic timers, see above), and all prior assignments + will have no effect.</para> + + <para>Note that calendar timers might be triggered at unexpected times if the system's realtime clock + is not set correctly. Specifically, on systems that lack a battery-buffered Realtime Clock (RTC) it + might be wise to enable <filename>systemd-time-wait-sync.service</filename> to ensure the clock is + adjusted to a network time source <emphasis>before</emphasis> the timer event is set up. Timer units + with at least one <varname>OnCalendar=</varname> expression are automatically ordered after + <filename>time-sync.target</filename>, which <filename>systemd-time-wait-sync.service</filename> is + ordered before.</para> + + <para>When a system is temporarily put to sleep (i.e. system suspend or hibernation) the realtime + clock does not pause. When a calendar timer elapses while the system is sleeping it will not be acted + on immediately, but once the system is later resumed it will catch up and process all timers that + triggered while the system was sleeping. Note that if a calendar timer elapsed more than once while + the system was continuously sleeping the timer will only result in a single service activation. If + <varname>WakeSystem=</varname> (see below) is enabled a calendar time event elapsing while the system + is suspended will cause the system to wake up (under the condition the system's hardware supports + time-triggered wake-up functionality).</para> + + <xi:include href="version-info.xml" xpointer="v197"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>AccuracySec=</varname></term> + + <listitem><para>Specify the accuracy the timer shall elapse + with. Defaults to 1min. The timer is scheduled to elapse + within a time window starting with the time specified in + <varname>OnCalendar=</varname>, + <varname>OnActiveSec=</varname>, + <varname>OnBootSec=</varname>, + <varname>OnStartupSec=</varname>, + <varname>OnUnitActiveSec=</varname> or + <varname>OnUnitInactiveSec=</varname> and ending the time + configured with <varname>AccuracySec=</varname> later. Within + this time window, the expiry time will be placed at a + host-specific, randomized, but stable position that is + synchronized between all local timer units. This is done in + order to optimize power consumption to suppress unnecessary + CPU wake-ups. To get best accuracy, set this option to + 1us. Note that the timer is still subject to the timer slack + configured via + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>'s + <varname>TimerSlackNSec=</varname> setting. See + <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for details. To optimize power consumption, make sure to set + this value as high as possible and as low as + necessary.</para> + + <para>Note that this setting is primarily a power saving option that allows coalescing CPU + wake-ups. It should not be confused with <varname>RandomizedDelaySec=</varname> (see below) which + adds a random value to the time the timer shall elapse next and whose purpose is the opposite: to + stretch elapsing of timer events over a longer period to reduce workload spikes. For further details + and explanations and how both settings play together, see below.</para> + + <xi:include href="version-info.xml" xpointer="v209"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RandomizedDelaySec=</varname></term> + + <listitem><para>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 + <varname>FixedRandomDelay=</varname>, see below.</para> + + <para>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.</para> + + <para>Note the relation to <varname>AccuracySec=</varname> 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 <varname>RandomizedDelaySec=</varname> and + <varname>AccuracySec=</varname> 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 <varname>AccuracySec=</varname> defaults to 1 minute and + <varname>RandomizedDelaySec=</varname> to 0, thus encouraging coalescing of timer events. In order to + optimally stretch timer events over a certain range of time, set + <varname>AccuracySec=1us</varname> and <varname>RandomizedDelaySec=</varname> to some higher value. + </para> + + <xi:include href="version-info.xml" xpointer="v229"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>FixedRandomDelay=</varname></term> + + <listitem><para>Takes a boolean argument. When enabled, the randomized offset specified by + <varname>RandomizedDelaySec=</varname> 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.</para> + + <para>This setting has no effect if <varname>RandomizedDelaySec=</varname> is set to 0. Defaults to + <option>false</option>.</para> + + <xi:include href="version-info.xml" xpointer="v247"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>OnClockChange=</varname></term> + <term><varname>OnTimezoneChange=</varname></term> + + <listitem><para>These options take boolean arguments. When true, the service unit will be triggered + when the system clock (<constant>CLOCK_REALTIME</constant>) jumps relative to the monotonic clock + (<constant>CLOCK_MONOTONIC</constant>), or when the local system timezone is modified. These options + can be used alone or in combination with other timer expressions (see above) within the same timer + unit. These options default to <option>false</option>.</para> + + <xi:include href="version-info.xml" xpointer="v242"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Unit=</varname></term> + + <listitem><para>The unit to activate when this timer elapses. + The argument is a unit name, whose suffix is not + <literal>.timer</literal>. If not specified, this value + defaults to a service that has the same name as the timer + unit, except for the suffix. (See above.) It is recommended + that the unit name that is activated and the unit name of the + timer unit are named identically, except for the + suffix.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Persistent=</varname></term> + + <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. 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 + <option>false</option>.</para> + + <para>Use <command>systemctl clean --what=state …</command> on the timer unit to remove the timestamp + file maintained by this option from disk. In particular, use this command before uninstalling a timer + unit. See + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details.</para> + + <xi:include href="version-info.xml" xpointer="v212"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>WakeSystem=</varname></term> + + <listitem><para>Takes a boolean argument. If true, an elapsing timer will cause the system to resume + from suspend, should it be suspended and if the system supports this. Note that this option will only + make sure the system resumes on the appropriate times, it will not take care of suspending it again + after any work that is to be done is finished. Defaults to + <option>false</option>.</para> + + <para>Note that this functionality requires privileges and is thus generally only available in the + system service manager.</para> + + <para>Note that behaviour of monotonic clock timers (as configured with + <varname>OnActiveSec=</varname>, <varname>OnBootSec=</varname>, <varname>OnStartupSec=</varname>, + <varname>OnUnitActiveSec=</varname>, <varname>OnUnitInactiveSec=</varname>, see above) is altered + depending on this option. If false, a monotonic clock is used that is paused during system suspend + (<constant>CLOCK_MONOTONIC</constant>), if true a different monotonic clock is used that continues + advancing during system suspend (<constant>CLOCK_BOOTTIME</constant>), see + <citerefentry><refentrytitle>clock_getres</refentrytitle><manvolnum>2</manvolnum></citerefentry> for + details.</para> + + <xi:include href="version-info.xml" xpointer="v212"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RemainAfterElapse=</varname></term> + + <listitem><para>Takes a boolean argument. If true, a timer will stay loaded, and its state remains + queryable even after it elapsed and the associated unit (as configured with <varname>Unit=</varname>, + see above) deactivated again. If false, an elapsed timer unit that cannot elapse anymore is unloaded + once its associated unit deactivated again. Turning this off is particularly useful for transient + timer units. Note that this setting has an effect when repeatedly starting a timer unit: if + <varname>RemainAfterElapse=</varname> is on, starting the timer a second time has no effect. However, + if <varname>RemainAfterElapse=</varname> is off and the timer unit was already unloaded, it can be + started again, and thus the service can be triggered multiple times. Defaults to + <option>true</option>.</para> + + <xi:include href="version-info.xml" xpointer="v229"/></listitem> + </varlistentry> + </variablelist> + + <xi:include href="systemd.service.xml" xpointer="shared-unit-options" /> + </refsect1> + + <refsect1> + <title>See Also</title> + <para>Environment variables with details on the trigger will be set for triggered units. See the + <literal>Environment Variables Set or Propagated by the Service Manager</literal> section in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more details.</para> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> |