]>
Commit | Line | Data |
---|---|---|
514094f9 | 1 | <?xml version='1.0'?> |
3a54a157 | 2 | <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" |
eea10b26 | 3 | "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> |
db9ecf05 | 4 | <!-- SPDX-License-Identifier: LGPL-2.1-or-later --> |
11fcc3ab | 5 | |
d8e1613e | 6 | <refentry id="systemd.timer" xmlns:xi="http://www.w3.org/2001/XInclude"> |
798d3a52 ZJS |
7 | <refentryinfo> |
8 | <title>systemd.timer</title> | |
9 | <productname>systemd</productname> | |
798d3a52 ZJS |
10 | </refentryinfo> |
11 | ||
12 | <refmeta> | |
13 | <refentrytitle>systemd.timer</refentrytitle> | |
14 | <manvolnum>5</manvolnum> | |
15 | </refmeta> | |
16 | ||
17 | <refnamediv> | |
18 | <refname>systemd.timer</refname> | |
19 | <refpurpose>Timer unit configuration</refpurpose> | |
20 | </refnamediv> | |
21 | ||
22 | <refsynopsisdiv> | |
23 | <para><filename><replaceable>timer</replaceable>.timer</filename></para> | |
24 | </refsynopsisdiv> | |
25 | ||
26 | <refsect1> | |
27 | <title>Description</title> | |
28 | ||
29 | <para>A unit configuration file whose name ends in | |
30 | <literal>.timer</literal> encodes information about a timer | |
31 | controlled and supervised by systemd, for timer-based | |
32 | activation.</para> | |
33 | ||
34 | <para>This man page lists the configuration options specific to | |
35 | this unit type. See | |
36 | <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> | |
37 | for the common options of all unit configuration files. The common | |
bdac5608 ZJS |
38 | configuration items are configured in the generic [Unit] and |
39 | [Install] sections. The timer specific configuration options are | |
40 | configured in the [Timer] section.</para> | |
798d3a52 ZJS |
41 | |
42 | <para>For each timer file, a matching unit file must exist, | |
43 | describing the unit to activate when the timer elapses. By | |
44 | default, a service by the same name as the timer (except for the | |
45 | suffix) is activated. Example: a timer file | |
46 | <filename>foo.timer</filename> activates a matching service | |
47 | <filename>foo.service</filename>. The unit to activate may be | |
48 | controlled by <varname>Unit=</varname> (see below).</para> | |
14e2baa3 LP |
49 | |
50 | <para>Note that in case the unit to activate is already active at the time the timer elapses it is not restarted, | |
51 | but simply left running. There is no concept of spawning new service instances in this case. Due to this, services | |
d4506301 JB |
52 | with <varname>RemainAfterExit=yes</varname> set (which stay around continuously even after the service's main |
53 | process exited) are usually not suitable for activation via repetitive timers, as they will only be activated | |
54 | once, and then stay around forever. Target units, which by default do not deactivate on their own, can be | |
55 | activated repeatedly by timers by setting <varname>StopWhenUnneeded=yes</varname> on them. This will cause a | |
56 | target unit to be stopped immediately after its activation, if it is not a dependency of another running unit.</para> | |
c129bd5d LP |
57 | </refsect1> |
58 | ||
45f09f93 | 59 | <refsect1> |
aed5cb03 | 60 | <title>Automatic Dependencies</title> |
45f09f93 | 61 | |
aed5cb03 ZJS |
62 | <refsect2> |
63 | <title>Implicit Dependencies</title> | |
45f09f93 | 64 | |
0ccc48b5 ML |
65 | <para>The following dependencies are implicitly added:</para> |
66 | ||
67 | <itemizedlist> | |
68 | <listitem><para>Timer units automatically gain a <varname>Before=</varname> | |
69 | dependency on the service they are supposed to activate.</para></listitem> | |
70 | </itemizedlist> | |
aed5cb03 ZJS |
71 | </refsect2> |
72 | ||
73 | <refsect2> | |
74 | <title>Default Dependencies</title> | |
75 | ||
76 | <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para> | |
77 | ||
78 | <itemizedlist> | |
79 | <listitem><para>Timer units will automatically have dependencies of type <varname>Requires=</varname> and | |
80 | <varname>After=</varname> on <filename>sysinit.target</filename>, a dependency of type <varname>Before=</varname> | |
81 | on <filename>timers.target</filename>, as well as <varname>Conflicts=</varname> and <varname>Before=</varname> on | |
82 | <filename>shutdown.target</filename> to ensure that they are stopped cleanly prior to system shutdown. Only timer | |
83 | units involved with early boot or late system shutdown should disable the | |
84 | <varname>DefaultDependencies=</varname> option.</para></listitem> | |
85 | ||
08e77eb8 LP |
86 | <listitem><para>Timer units with at least one <varname>OnCalendar=</varname> directive acquire a pair |
87 | of additional <varname>After=</varname> dependencies on <filename>time-set.target</filename> and | |
88 | <filename>time-sync.target</filename>, in order to avoid being started before the system clock has | |
89 | been correctly set. See | |
90 | <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> | |
91 | for details on these two targets.</para></listitem> | |
aed5cb03 ZJS |
92 | </itemizedlist> |
93 | </refsect2> | |
798d3a52 ZJS |
94 | </refsect1> |
95 | ||
96 | <refsect1> | |
97 | <title>Options</title> | |
98 | ||
d8e1613e ZJS |
99 | <para>Timer unit files may include [Unit] and [Install] sections, which are described in |
100 | <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. | |
101 | </para> | |
102 | ||
103 | <para>Timer unit files must include a [Timer] section, which carries | |
798d3a52 ZJS |
104 | information about the timer it defines. The options specific to |
105 | the [Timer] section of timer units are the following:</para> | |
106 | ||
107 | <variablelist class='unit-directives'> | |
108 | <varlistentry> | |
109 | <term><varname>OnActiveSec=</varname></term> | |
110 | <term><varname>OnBootSec=</varname></term> | |
111 | <term><varname>OnStartupSec=</varname></term> | |
112 | <term><varname>OnUnitActiveSec=</varname></term> | |
113 | <term><varname>OnUnitInactiveSec=</varname></term> | |
114 | ||
115 | <listitem><para>Defines monotonic timers relative to different | |
c49357e7 LP |
116 | starting points:</para> |
117 | ||
118 | <table> | |
119 | <title>Settings and their starting points</title> | |
120 | ||
121 | <tgroup cols='2'> | |
122 | <thead> | |
123 | <row> | |
124 | <entry>Setting</entry> | |
125 | <entry>Meaning</entry> | |
126 | </row> | |
127 | </thead> | |
128 | <tbody> | |
129 | <row> | |
130 | <entry><varname>OnActiveSec=</varname></entry> | |
131 | <entry>Defines a timer relative to the moment the timer unit itself is activated.</entry> | |
132 | </row> | |
133 | <row> | |
134 | <entry><varname>OnBootSec=</varname></entry> | |
65aeb9d4 | 135 | <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> |
c49357e7 LP |
136 | </row> |
137 | <row> | |
138 | <entry><varname>OnStartupSec=</varname></entry> | |
139 | <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> | |
140 | </row> | |
141 | <row> | |
142 | <entry><varname>OnUnitActiveSec=</varname></entry> | |
143 | <entry>Defines a timer relative to when the unit the timer unit is activating was last activated.</entry> | |
144 | </row> | |
145 | <row> | |
146 | <entry><varname>OnUnitInactiveSec=</varname></entry> | |
147 | <entry>Defines a timer relative to when the unit the timer unit is activating was last deactivated.</entry> | |
148 | </row> | |
149 | </tbody> | |
150 | </tgroup> | |
151 | </table> | |
798d3a52 | 152 | |
58031d99 LP |
153 | <para>Multiple directives may be combined of the same and of different types, in which case the timer |
154 | unit will trigger whenever any of the specified timer expressions elapse. For example, by combining | |
155 | <varname>OnBootSec=</varname> and <varname>OnUnitActiveSec=</varname>, it is possible to define a | |
156 | timer that elapses in regular intervals and activates a specific service each time. Moreover, both | |
157 | monotonic time expressions and <varname>OnCalendar=</varname> calendar expressions may be combined in | |
158 | the same timer unit.</para> | |
798d3a52 ZJS |
159 | |
160 | <para>The arguments to the directives are time spans | |
161 | configured in seconds. Example: "OnBootSec=50" means 50s after | |
162 | boot-up. The argument may also include time units. Example: | |
163 | "OnBootSec=5h 30min" means 5 hours and 30 minutes after | |
164 | boot-up. For details about the syntax of time spans, see | |
9905e698 | 165 | <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> |
798d3a52 ZJS |
166 | |
167 | <para>If a timer configured with <varname>OnBootSec=</varname> | |
168 | or <varname>OnStartupSec=</varname> is already in the past | |
169 | when the timer unit is activated, it will immediately elapse | |
170 | and the configured unit is started. This is not the case for | |
171 | timers defined in the other directives.</para> | |
172 | ||
58031d99 | 173 | <para>These are monotonic timers, independent of wall-clock time and timezones. If the computer is |
f535af6b LP |
174 | temporarily suspended, the monotonic clock generally pauses, too. Note that if |
175 | <varname>WakeSystem=</varname> is used, a different monotonic clock is selected that continues to | |
176 | advance while the system is suspended and thus can be used as the trigger to resume the | |
177 | system.</para> | |
798d3a52 | 178 | |
58031d99 LP |
179 | <para>If the empty string is assigned to any of these options, the list of timers is reset (both |
180 | monotonic timers and <varname>OnCalendar=</varname> timers, see below), and all prior assignments | |
181 | will have no effect.</para> | |
798d3a52 ZJS |
182 | |
183 | <para>Note that timers do not necessarily expire at the | |
184 | precise time configured with these settings, as they are | |
185 | subject to the <varname>AccuracySec=</varname> setting | |
186 | below.</para></listitem> | |
798d3a52 ZJS |
187 | </varlistentry> |
188 | ||
189 | <varlistentry> | |
190 | <term><varname>OnCalendar=</varname></term> | |
191 | ||
9e7e9c72 LP |
192 | <listitem><para>Defines realtime (i.e. wallclock) timers with calendar event expressions. See |
193 | <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for | |
194 | more information on the syntax of calendar event expressions. Otherwise, the semantics are similar to | |
798d3a52 ZJS |
195 | <varname>OnActiveSec=</varname> and related settings.</para> |
196 | ||
9e7e9c72 LP |
197 | <para>Note that timers do not necessarily expire at the precise time configured with this setting, as |
198 | it is subject to the <varname>AccuracySec=</varname> setting below.</para> | |
192fa38b | 199 | |
58031d99 LP |
200 | <para>May be specified more than once, in which case the timer unit will trigger whenever any of the |
201 | specified expressions elapse. Moreover calendar timers and monotonic timers (see above) may be | |
202 | combined within the same timer unit.</para> | |
203 | ||
204 | <para>If the empty string is assigned to any of these options, the list of timers is reset (both | |
205 | <varname>OnCalendar=</varname> timers and monotonic timers, see above), and all prior assignments | |
9e7e9c72 LP |
206 | will have no effect.</para> |
207 | ||
208 | <para>Note that calendar timers might be triggered at unexpected times if the system's realtime clock | |
209 | is not set correctly. Specifically, on systems that lack a battery-buffered Realtime Clock (RTC) it | |
210 | might be wise to enable <filename>systemd-time-wait-sync.service</filename> to ensure the clock is | |
211 | adjusted to a network time source <emphasis>before</emphasis> the timer event is set up. Timer units | |
212 | with at least one <varname>OnCalendar=</varname> expression are automatically ordered after | |
213 | <filename>time-sync.target</filename>, which <filename>systemd-time-wait-sync.service</filename> is | |
438874cb LP |
214 | ordered before.</para> |
215 | ||
216 | <para>When a system is temporarily put to sleep (i.e. system suspend or hibernation) the realtime | |
217 | clock does not pause. When a calendar timer elapses while the system is sleeping it will not be acted | |
218 | on immediately, but once the system is later resumed it will catch up and process all timers that | |
219 | triggered while the system was sleeping. Note that if a calendar timer elapsed more than once while | |
9a27ef09 | 220 | the system was continuously sleeping the timer will only result in a single service activation. If |
438874cb LP |
221 | <varname>WakeSystem=</varname> (see below) is enabled a calendar time event elapsing while the system |
222 | is suspended will cause the system to wake up (under the condition the system's hardware supports | |
ec07c3c8 AK |
223 | time-triggered wake-up functionality).</para> |
224 | ||
225 | <xi:include href="version-info.xml" xpointer="v197"/></listitem> | |
798d3a52 ZJS |
226 | </varlistentry> |
227 | ||
228 | <varlistentry> | |
229 | <term><varname>AccuracySec=</varname></term> | |
230 | ||
231 | <listitem><para>Specify the accuracy the timer shall elapse | |
232 | with. Defaults to 1min. The timer is scheduled to elapse | |
233 | within a time window starting with the time specified in | |
234 | <varname>OnCalendar=</varname>, | |
235 | <varname>OnActiveSec=</varname>, | |
236 | <varname>OnBootSec=</varname>, | |
237 | <varname>OnStartupSec=</varname>, | |
238 | <varname>OnUnitActiveSec=</varname> or | |
239 | <varname>OnUnitInactiveSec=</varname> and ending the time | |
240 | configured with <varname>AccuracySec=</varname> later. Within | |
241 | this time window, the expiry time will be placed at a | |
744c7693 | 242 | host-specific, randomized, but stable position that is |
798d3a52 | 243 | synchronized between all local timer units. This is done in |
744c7693 LP |
244 | order to optimize power consumption to suppress unnecessary |
245 | CPU wake-ups. To get best accuracy, set this option to | |
246 | 1us. Note that the timer is still subject to the timer slack | |
247 | configured via | |
798d3a52 ZJS |
248 | <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>'s |
249 | <varname>TimerSlackNSec=</varname> setting. See | |
250 | <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> | |
251 | for details. To optimize power consumption, make sure to set | |
252 | this value as high as possible and as low as | |
d524094b LP |
253 | necessary.</para> |
254 | ||
255 | <para>Note that this setting is primarily a power saving option that allows coalescing CPU | |
256 | wake-ups. It should not be confused with <varname>RandomizedDelaySec=</varname> (see below) which | |
257 | adds a random value to the time the timer shall elapse next and whose purpose is the opposite: to | |
258 | stretch elapsing of timer events over a longer period to reduce workload spikes. For further details | |
ec07c3c8 AK |
259 | and explanations and how both settings play together, see below.</para> |
260 | ||
261 | <xi:include href="version-info.xml" xpointer="v209"/></listitem> | |
798d3a52 | 262 | </varlistentry> |
744c7693 LP |
263 | |
264 | <varlistentry> | |
6f5d7998 | 265 | <term><varname>RandomizedDelaySec=</varname></term> |
744c7693 | 266 | |
b5e798de ZJS |
267 | <listitem><para>Delay the timer by a randomly selected, evenly distributed amount of time between 0 |
268 | and the specified time value. Defaults to 0, indicating that no randomized delay shall be applied. | |
269 | Each timer unit will determine this delay randomly before each iteration, and the delay will simply | |
270 | be added on top of the next determined elapsing time, unless modified with | |
271 | <varname>FixedRandomDelay=</varname>, see below.</para> | |
272 | ||
273 | <para>This setting is useful to stretch dispatching of similarly configured timer events over a | |
274 | certain time interval, to prevent them from firing all at the same time, possibly resulting in | |
275 | resource congestion.</para> | |
276 | ||
277 | <para>Note the relation to <varname>AccuracySec=</varname> above: the latter allows the service | |
278 | manager to coalesce timer events within a specified time range in order to minimize wakeups, while | |
279 | this setting does the opposite: it stretches timer events over an interval, to make it unlikely that | |
280 | they fire simultaneously. If <varname>RandomizedDelaySec=</varname> and | |
281 | <varname>AccuracySec=</varname> are used in conjunction, first the randomized delay is added, and | |
282 | then the result is possibly further shifted to coalesce it with other timer events happening on the | |
283 | system. As mentioned above <varname>AccuracySec=</varname> defaults to 1 minute and | |
284 | <varname>RandomizedDelaySec=</varname> to 0, thus encouraging coalescing of timer events. In order to | |
285 | optimally stretch timer events over a certain range of time, set | |
286 | <varname>AccuracySec=1us</varname> and <varname>RandomizedDelaySec=</varname> to some higher value. | |
ec07c3c8 AK |
287 | </para> |
288 | ||
289 | <xi:include href="version-info.xml" xpointer="v229"/></listitem> | |
744c7693 LP |
290 | </varlistentry> |
291 | ||
acf24a1a KG |
292 | <varlistentry> |
293 | <term><varname>FixedRandomDelay=</varname></term> | |
294 | ||
b5e798de ZJS |
295 | <listitem><para>Takes a boolean argument. When enabled, the randomized offset specified by |
296 | <varname>RandomizedDelaySec=</varname> is reused for all firings of the same timer. For a given timer | |
297 | unit, the offset depends on the machine ID, user identifier and timer name, which means that it is | |
298 | stable between restarts of the manager. This effectively creates a fixed offset for an individual | |
299 | timer, reducing the jitter in firings of this timer, while still avoiding firing at the same time as | |
300 | other similarly configured timers.</para> | |
301 | ||
302 | <para>This setting has no effect if <varname>RandomizedDelaySec=</varname> is set to 0. Defaults to | |
ec07c3c8 AK |
303 | <option>false</option>.</para> |
304 | ||
305 | <xi:include href="version-info.xml" xpointer="v247"/></listitem> | |
acf24a1a KG |
306 | </varlistentry> |
307 | ||
d9b8c2ef LP |
308 | <varlistentry> |
309 | <term><varname>OnClockChange=</varname></term> | |
310 | <term><varname>OnTimezoneChange=</varname></term> | |
311 | ||
312 | <listitem><para>These options take boolean arguments. When true, the service unit will be triggered | |
313 | when the system clock (<constant>CLOCK_REALTIME</constant>) jumps relative to the monotonic clock | |
314 | (<constant>CLOCK_MONOTONIC</constant>), or when the local system timezone is modified. These options | |
315 | can be used alone or in combination with other timer expressions (see above) within the same timer | |
ec07c3c8 AK |
316 | unit. These options default to <option>false</option>.</para> |
317 | ||
318 | <xi:include href="version-info.xml" xpointer="v242"/></listitem> | |
d9b8c2ef LP |
319 | </varlistentry> |
320 | ||
798d3a52 ZJS |
321 | <varlistentry> |
322 | <term><varname>Unit=</varname></term> | |
323 | ||
324 | <listitem><para>The unit to activate when this timer elapses. | |
325 | The argument is a unit name, whose suffix is not | |
326 | <literal>.timer</literal>. If not specified, this value | |
327 | defaults to a service that has the same name as the timer | |
328 | unit, except for the suffix. (See above.) It is recommended | |
329 | that the unit name that is activated and the unit name of the | |
330 | timer unit are named identically, except for the | |
331 | suffix.</para></listitem> | |
332 | </varlistentry> | |
333 | ||
798d3a52 ZJS |
334 | <varlistentry> |
335 | <term><varname>Persistent=</varname></term> | |
336 | ||
8c8208cb LP |
337 | <listitem><para>Takes a boolean argument. If true, the time when the service unit was last triggered |
338 | is stored on disk. When the timer is activated, the service unit is triggered immediately if it | |
5501da15 NV |
339 | would have been triggered at least once during the time when the timer was inactive. Such triggering |
340 | is nonetheless subject to the delay imposed by <varname>RandomizedDelaySec=</varname>. | |
341 | This is useful to catch up on missed runs of the service when the system was powered down. Note that | |
342 | this setting only has an effect on timers configured with <varname>OnCalendar=</varname>. Defaults to | |
5cecbae1 | 343 | <option>false</option>.</para> |
8c8208cb LP |
344 | |
345 | <para>Use <command>systemctl clean --what=state …</command> on the timer unit to remove the timestamp | |
346 | file maintained by this option from disk. In particular, use this command before uninstalling a timer | |
347 | unit. See | |
348 | <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for | |
ec07c3c8 AK |
349 | details.</para> |
350 | ||
351 | <xi:include href="version-info.xml" xpointer="v212"/></listitem> | |
798d3a52 ZJS |
352 | </varlistentry> |
353 | ||
354 | <varlistentry> | |
355 | <term><varname>WakeSystem=</varname></term> | |
356 | ||
114b90e1 LP |
357 | <listitem><para>Takes a boolean argument. If true, an elapsing timer will cause the system to resume |
358 | from suspend, should it be suspended and if the system supports this. Note that this option will only | |
359 | make sure the system resumes on the appropriate times, it will not take care of suspending it again | |
360 | after any work that is to be done is finished. Defaults to | |
5cecbae1 | 361 | <option>false</option>.</para> |
114b90e1 LP |
362 | |
363 | <para>Note that this functionality requires privileges and is thus generally only available in the | |
f535af6b LP |
364 | system service manager.</para> |
365 | ||
366 | <para>Note that behaviour of monotonic clock timers (as configured with | |
367 | <varname>OnActiveSec=</varname>, <varname>OnBootSec=</varname>, <varname>OnStartupSec=</varname>, | |
368 | <varname>OnUnitActiveSec=</varname>, <varname>OnUnitInactiveSec=</varname>, see above) is altered | |
369 | depending on this option. If false, a monotonic clock is used that is paused during system suspend | |
370 | (<constant>CLOCK_MONOTONIC</constant>), if true a different monotonic clock is used that continues | |
371 | advancing during system suspend (<constant>CLOCK_BOOTTIME</constant>), see | |
372 | <citerefentry><refentrytitle>clock_getres</refentrytitle><manvolnum>2</manvolnum></citerefentry> for | |
ec07c3c8 AK |
373 | details.</para> |
374 | ||
375 | <xi:include href="version-info.xml" xpointer="v212"/></listitem> | |
3e0c30ac LP |
376 | </varlistentry> |
377 | ||
378 | <varlistentry> | |
70b4f819 | 379 | <term><varname>RemainAfterElapse=</varname></term> |
3e0c30ac | 380 | |
415f8a5b LP |
381 | <listitem><para>Takes a boolean argument. If true, a timer will stay loaded, and its state remains |
382 | queryable even after it elapsed and the associated unit (as configured with <varname>Unit=</varname>, | |
383 | see above) deactivated again. If false, an elapsed timer unit that cannot elapse anymore is unloaded | |
384 | once its associated unit deactivated again. Turning this off is particularly useful for transient | |
385 | timer units. Note that this setting has an effect when repeatedly starting a timer unit: if | |
386 | <varname>RemainAfterElapse=</varname> is on, starting the timer a second time has no effect. However, | |
387 | if <varname>RemainAfterElapse=</varname> is off and the timer unit was already unloaded, it can be | |
388 | started again, and thus the service can be triggered multiple times. Defaults to | |
ec07c3c8 AK |
389 | <option>true</option>.</para> |
390 | ||
391 | <xi:include href="version-info.xml" xpointer="v229"/></listitem> | |
798d3a52 ZJS |
392 | </varlistentry> |
393 | </variablelist> | |
d8e1613e ZJS |
394 | |
395 | <xi:include href="systemd.service.xml" xpointer="shared-unit-options" /> | |
798d3a52 ZJS |
396 | </refsect1> |
397 | ||
398 | <refsect1> | |
399 | <title>See Also</title> | |
c8bc7519 | 400 | <para>Environment variables with details on the trigger will be set for triggered units. See the |
8fb35004 | 401 | <literal>Environment Variables Set or Propagated by the Service Manager</literal> section in |
8b9f0921 | 402 | <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> |
c8bc7519 | 403 | for more details.</para> |
13a69c12 DT |
404 | <para><simplelist type="inline"> |
405 | <member><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry></member> | |
406 | <member><citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member> | |
407 | <member><citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry></member> | |
408 | <member><citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry></member> | |
409 | <member><citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry></member> | |
410 | <member><citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry></member> | |
411 | <member><citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry></member> | |
412 | <member><citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry></member> | |
413 | </simplelist></para> | |
798d3a52 | 414 | </refsect1> |
11fcc3ab LP |
415 | |
416 | </refentry> |