]> git.ipfire.org Git - thirdparty/systemd.git/blob - man/systemd.unit.xml
core: change top-level drop-in from -.service.d to service.d
[thirdparty/systemd.git] / man / systemd.unit.xml
1 <?xml version='1.0'?>
2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
4 <!ENTITY % entities SYSTEM "custom-entities.ent" >
5 %entities;
6 ]>
7 <!-- SPDX-License-Identifier: LGPL-2.1+ -->
8
9 <refentry id="systemd.unit">
10
11 <refentryinfo>
12 <title>systemd.unit</title>
13 <productname>systemd</productname>
14 </refentryinfo>
15
16 <refmeta>
17 <refentrytitle>systemd.unit</refentrytitle>
18 <manvolnum>5</manvolnum>
19 </refmeta>
20
21 <refnamediv>
22 <refname>systemd.unit</refname>
23 <refpurpose>Unit configuration</refpurpose>
24 </refnamediv>
25
26 <refsynopsisdiv>
27 <para><filename><replaceable>service</replaceable>.service</filename>,
28 <filename><replaceable>socket</replaceable>.socket</filename>,
29 <filename><replaceable>device</replaceable>.device</filename>,
30 <filename><replaceable>mount</replaceable>.mount</filename>,
31 <filename><replaceable>automount</replaceable>.automount</filename>,
32 <filename><replaceable>swap</replaceable>.swap</filename>,
33 <filename><replaceable>target</replaceable>.target</filename>,
34 <filename><replaceable>path</replaceable>.path</filename>,
35 <filename><replaceable>timer</replaceable>.timer</filename>,
36 <filename><replaceable>slice</replaceable>.slice</filename>,
37 <filename><replaceable>scope</replaceable>.scope</filename></para>
38
39 <refsect2>
40 <title>System Unit Search Path</title>
41
42 <para><literallayout><filename>/etc/systemd/system.control/*</filename>
43 <filename>/run/systemd/system.control/*</filename>
44 <filename>/run/systemd/transient/*</filename>
45 <filename>/run/systemd/generator.early/*</filename>
46 <filename>/etc/systemd/system/*</filename>
47 <filename>/etc/systemd/systemd.attached/*</filename>
48 <filename>/run/systemd/system/*</filename>
49 <filename>/run/systemd/systemd.attached/*</filename>
50 <filename>/run/systemd/generator/*</filename>
51 <filename></filename>
52 <filename>/usr/lib/systemd/system/*</filename>
53 <filename>/run/systemd/generator.late/*</filename></literallayout></para>
54 </refsect2>
55
56 <refsect2>
57 <title>User Unit Search Path</title>
58 <para><literallayout><filename>~/.config/systemd/user.control/*</filename>
59 <filename>$XDG_RUNTIME_DIR/systemd/user.control/*</filename>
60 <filename>$XDG_RUNTIME_DIR/systemd/transient/*</filename>
61 <filename>$XDG_RUNTIME_DIR/systemd/generator.early/*</filename>
62 <filename>~/.config/systemd/user/*</filename>
63 <filename>/etc/systemd/user/*</filename>
64 <filename>$XDG_RUNTIME_DIR/systemd/user/*</filename>
65 <filename>/run/systemd/user/*</filename>
66 <filename>$XDG_RUNTIME_DIR/systemd/generator/*</filename>
67 <filename>~/.local/share/systemd/user/*</filename>
68 <filename></filename>
69 <filename>/usr/lib/systemd/user/*</filename>
70 <filename>$XDG_RUNTIME_DIR/systemd/generator.late/*</filename></literallayout></para>
71 </refsect2>
72
73 </refsynopsisdiv>
74
75 <refsect1>
76 <title>Description</title>
77
78 <para>A unit file is a plain text ini-style file that encodes information about a service, a
79 socket, a device, a mount point, an automount point, a swap file or partition, a start-up
80 target, a watched file system path, a timer controlled and supervised by
81 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, a
82 resource management slice or a group of externally created processes. See
83 <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>
84 for a general description of the syntax.</para>
85
86 <para>This man page lists the common configuration options of all
87 the unit types. These options need to be configured in the [Unit]
88 or [Install] sections of the unit files.</para>
89
90 <para>In addition to the generic [Unit] and [Install] sections
91 described here, each unit may have a type-specific section, e.g.
92 [Service] for a service unit. See the respective man pages for
93 more information:
94 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
95 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
96 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
97 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
98 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
99 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
100 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
101 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
102 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
103 <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
104 <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
105 </para>
106
107 <para>Unit files are loaded from a set of paths determined during compilation, described in the next
108 section.</para>
109
110 <para>Valid unit names consist of a "name prefix" and a dot and a suffix specifying the unit type. The
111 "unit prefix" must consist of one or more valid characters (ASCII letters, digits, <literal>:</literal>,
112 <literal>-</literal>, <literal>_</literal>, <literal>.</literal>, and <literal>\</literal>). The total
113 length of the unit name including the suffix must not exceed 256 characters. The type suffix must be one
114 of <literal>.service</literal>, <literal>.socket</literal>, <literal>.device</literal>,
115 <literal>.mount</literal>, <literal>.automount</literal>, <literal>.swap</literal>,
116 <literal>.target</literal>, <literal>.path</literal>, <literal>.timer</literal>,
117 <literal>.slice</literal>, or <literal>.scope</literal>.</para>
118
119 <para>Units names can be parameterized by a single argument called the "instance name". The unit is then
120 constructed based on a "template file" which serves as the definition of multiple services or other
121 units. A template unit must have a single <literal>@</literal> at the end of the name (right before the
122 type suffix). The name of the full unit is formed by inserting the instance name between
123 <literal>@</literal> and the unit type suffix. In the unit file itself, the instance parameter may be
124 referred to using <literal>%i</literal> and other specifiers, see below.</para>
125
126 <para>Unit files may contain additional options on top of those
127 listed here. If systemd encounters an unknown option, it will
128 write a warning log message but continue loading the unit. If an
129 option or section name is prefixed with <option>X-</option>, it is
130 ignored completely by systemd. Options within an ignored section
131 do not need the prefix. Applications may use this to include
132 additional information in the unit files.</para>
133
134 <para>Units can be aliased (have an alternative name), by creating a symlink from the new name to the
135 existing name in one of the unit search paths. For example, <filename>systemd-networkd.service</filename>
136 has the alias <filename>dbus-org.freedesktop.network1.service</filename>, created during installation as
137 a symlink, so when <command>systemd</command> is asked through D-Bus to load
138 <filename>dbus-org.freedesktop.network1.service</filename>, it'll load
139 <filename>systemd-networkd.service</filename>. Alias names may be used in commands like
140 <command>disable</command>, <command>start</command>, <command>stop</command>, <command>status</command>,
141 and similar, and in all unit dependency directives, including <varname>Wants=</varname>,
142 <varname>Requires=</varname>, <varname>Before=</varname>, <varname>After=</varname>. Aliases cannot be
143 used with the <command>preset</command> command.</para>
144
145 <para>Unit files may specify aliases through the <varname>Alias=</varname> directive in the [Install]
146 section. When the unit is enabled, symlinks will be created for those names, and removed when the unit is
147 disabled. For example, <filename>reboot.target</filename> specifies
148 <varname>Alias=ctrl-alt-del.target</varname>, so when enabled, the symlink
149 <filename>/etc/systemd/systemd/ctrl-alt-del.service</filename> pointing to the
150 <filename>reboot.target</filename> file will be created, and when
151 <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> is invoked,
152 <command>systemd</command> will look for the <filename>ctrl-alt-del.service</filename> and execute
153 <filename>reboot.service</filename>. <command>systemd</command> does not look at the [Install] section at
154 all during normal operation, so any directives in that section only have an effect through the symlinks
155 created during enablement.</para>
156
157 <para>Along with a unit file <filename>foo.service</filename>, the directory
158 <filename>foo.service.wants/</filename> may exist. All unit files symlinked from such a directory are
159 implicitly added as dependencies of type <varname>Wants=</varname> to the unit. Similar functionality
160 exists for <varname>Requires=</varname> type dependencies as well, the directory suffix is
161 <filename>.requires/</filename> in this case. This functionality is useful to hook units into the
162 start-up of other units, without having to modify their unit files. For details about the semantics of
163 <varname>Wants=</varname>, see below. The preferred way to create symlinks in the
164 <filename>.wants/</filename> or <filename>.requires/</filename> directory of a unit file is by embedding
165 the dependency in [Install] section of the target unit, and creating the symlink in the file system with
166 the <command>enable</command> or <command>preset</command> commands of
167 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
168
169 <para>Along with a unit file <filename>foo.service</filename>, a "drop-in" directory
170 <filename>foo.service.d/</filename> may exist. All files with the suffix <literal>.conf</literal> from this
171 directory will be parsed after the unit file itself is parsed. This is useful to alter or add configuration
172 settings for a unit, without having to modify unit files. Drop-in files must contain appropriate section
173 headers. For instantiated units, this logic will first look for the instance <literal>.d/</literal> subdirectory
174 (e.g. <literal>foo@bar.service.d/</literal>) and read its <literal>.conf</literal> files, followed by the template
175 <literal>.d/</literal> subdirectory (e.g. <literal>foo@.service.d/</literal>) and the <literal>.conf</literal>
176 files there. Moreover for units names containing dashes (<literal>-</literal>), the set of directories generated by
177 truncating the unit name after all dashes is searched too. Specifically, for a unit name
178 <filename>foo-bar-baz.service</filename> not only the regular drop-in directory
179 <filename>foo-bar-baz.service.d/</filename> is searched but also both <filename>foo-bar-.service.d/</filename> and
180 <filename>foo-.service.d/</filename>. This is useful for defining common drop-ins for a set of related units, whose
181 names begin with a common prefix. This scheme is particularly useful for mount, automount and slice units, whose
182 systematic naming structure is built around dashes as component separators. Note that equally named drop-in files
183 further down the prefix hierarchy override those further up,
184 i.e. <filename>foo-bar-.service.d/10-override.conf</filename> overrides
185 <filename>foo-.service.d/10-override.conf</filename>.</para>
186
187 <para>In addition to <filename>/etc/systemd/system</filename>, the drop-in <literal>.d/</literal>
188 directories for system services can be placed in <filename>/usr/lib/systemd/system</filename> or
189 <filename>/run/systemd/system</filename> directories. Drop-in files in <filename>/etc</filename>
190 take precedence over those in <filename>/run</filename> which in turn take precedence over those
191 in <filename>/usr/lib</filename>. Drop-in files under any of these directories take precedence
192 over unit files wherever located. Multiple drop-in files with different names are applied in
193 lexicographic order, regardless of which of the directories they reside in.</para>
194
195 <para>Units also support a top-level drop-in with <filename><replaceable>type</replaceable>.d/</filename>,
196 where <replaceable>type</replaceable> may be e.g. <literal>service</literal> or <literal>socket</literal>,
197 that allows altering or adding to the settings of all corresponding unit files on the system.
198 The formatting and precedence of applying drop-in configurations follow what is defined above.
199 Configurations in <filename><replaceable>type</replaceable>.d/</filename> have the lowest precedence
200 compared to settings in the name specific override directories. So the contents of
201 <filename>foo-.service.d/10-override.conf</filename> would override
202 <filename>service.d/10-override.conf</filename>.</para>
203
204 <!-- Note that we do not document .include here, as we consider it mostly obsolete, and want
205 people to use .d/ drop-ins instead. -->
206
207 <para>Note that while systemd offers a flexible dependency system
208 between units it is recommended to use this functionality only
209 sparingly and instead rely on techniques such as bus-based or
210 socket-based activation which make dependencies implicit,
211 resulting in a both simpler and more flexible system.</para>
212
213 <para>As mentioned above, a unit may be instantiated from a template file. This allows creation
214 of multiple units from a single configuration file. If systemd looks for a unit configuration
215 file, it will first search for the literal unit name in the file system. If that yields no
216 success and the unit name contains an <literal>@</literal> character, systemd will look for a
217 unit template that shares the same name but with the instance string (i.e. the part between the
218 <literal>@</literal> character and the suffix) removed. Example: if a service
219 <filename>getty@tty3.service</filename> is requested and no file by that name is found, systemd
220 will look for <filename>getty@.service</filename> and instantiate a service from that
221 configuration file if it is found.</para>
222
223 <para>To refer to the instance string from within the
224 configuration file you may use the special <literal>%i</literal>
225 specifier in many of the configuration options. See below for
226 details.</para>
227
228 <para>If a unit file is empty (i.e. has the file size 0) or is
229 symlinked to <filename>/dev/null</filename>, its configuration
230 will not be loaded and it appears with a load state of
231 <literal>masked</literal>, and cannot be activated. Use this as an
232 effective way to fully disable a unit, making it impossible to
233 start it even manually.</para>
234
235 <para>The unit file format is covered by the
236 <ulink
237 url="https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
238 Stability Promise</ulink>.</para>
239
240 </refsect1>
241
242 <refsect1>
243 <title>String Escaping for Inclusion in Unit Names</title>
244
245 <para>Sometimes it is useful to convert arbitrary strings into unit names. To facilitate this, a method of string
246 escaping is used, in order to map strings containing arbitrary byte values (except NUL) into valid unit names and
247 their restricted character set. A common special case are unit names that reflect paths to objects in the file
248 system hierarchy. Example: a device unit <filename>dev-sda.device</filename> refers to a device with the device
249 node <filename noindex='true'>/dev/sda</filename> in the file system.</para>
250
251 <para>The escaping algorithm operates as follows: given a string, any <literal>/</literal> character is replaced by
252 <literal>-</literal>, and all other characters which are not ASCII alphanumerics or <literal>_</literal> are
253 replaced by C-style <literal>\x2d</literal> escapes. In addition, <literal>.</literal> is replaced with such a
254 C-style escape when it would appear as the first character in the escaped string.</para>
255
256 <para>When the input qualifies as absolute file system path, this algorithm is extended slightly: the path to the
257 root directory <literal>/</literal> is encoded as single dash <literal>-</literal>. In addition, any leading,
258 trailing or duplicate <literal>/</literal> characters are removed from the string before transformation. Example:
259 <filename>/foo//bar/baz/</filename> becomes <literal>foo-bar-baz</literal>.</para>
260
261 <para>This escaping is fully reversible, as long as it is known whether the escaped string was a path (the
262 unescaping results are different for paths and non-path strings). The
263 <citerefentry><refentrytitle>systemd-escape</refentrytitle><manvolnum>1</manvolnum></citerefentry> command may be
264 used to apply and reverse escaping on arbitrary strings. Use <command>systemd-escape --path</command> to escape
265 path strings, and <command>systemd-escape</command> without <option>--path</option> otherwise.</para>
266 </refsect1>
267
268 <refsect1>
269 <title>Automatic dependencies</title>
270
271 <refsect2>
272 <title>Implicit Dependencies</title>
273
274 <para>A number of unit dependencies are implicitly established, depending on unit type and
275 unit configuration. These implicit dependencies can make unit configuration file cleaner. For
276 the implicit dependencies in each unit type, please refer to section "Implicit Dependencies"
277 in respective man pages.</para>
278
279 <para>For example, service units with <varname>Type=dbus</varname> automatically acquire
280 dependencies of type <varname>Requires=</varname> and <varname>After=</varname> on
281 <filename>dbus.socket</filename>. See
282 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
283 for details.</para>
284 </refsect2>
285
286 <refsect2>
287 <title>Default Dependencies</title>
288
289 <para>Default dependencies are similar to implicit dependencies, but can be turned on and off
290 by setting <varname>DefaultDependencies=</varname> to <varname>yes</varname> (the default) and
291 <varname>no</varname>, while implicit dependencies are always in effect. See section "Default
292 Dependencies" in respective man pages for the effect of enabling
293 <varname>DefaultDependencies=</varname> in each unit types.</para>
294
295 <para>For example, target units will complement all configured dependencies of type
296 <varname>Wants=</varname> or <varname>Requires=</varname> with dependencies of type
297 <varname>After=</varname> unless <varname>DefaultDependencies=no</varname> is set in the
298 specified units. See
299 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
300 for details. Note that this behavior can be turned off by setting
301 <varname>DefaultDependencies=no</varname>.</para>
302 </refsect2>
303 </refsect1>
304
305 <refsect1>
306 <title>Unit File Load Path</title>
307
308 <para>Unit files are loaded from a set of paths determined during
309 compilation, described in the two tables below. Unit files found
310 in directories listed earlier override files with the same name in
311 directories lower in the list.</para>
312
313 <para>When the variable <varname>$SYSTEMD_UNIT_PATH</varname> is set,
314 the contents of this variable overrides the unit load path. If
315 <varname>$SYSTEMD_UNIT_PATH</varname> ends with an empty component
316 (<literal>:</literal>), the usual unit load path will be appended
317 to the contents of the variable.</para>
318
319 <table>
320 <title>
321 Load path when running in system mode (<option>--system</option>).
322 </title>
323
324 <tgroup cols='2'>
325 <colspec colname='path' />
326 <colspec colname='expl' />
327 <thead>
328 <row>
329 <entry>Path</entry>
330 <entry>Description</entry>
331 </row>
332 </thead>
333 <tbody>
334 <row>
335 <entry><filename>/etc/systemd/system.control</filename></entry>
336 <entry morerows="1">Persistent and transient configuration created using the dbus API</entry>
337 </row>
338 <row>
339 <entry><filename>/run/systemd/system.control</filename></entry>
340 </row>
341 <row>
342 <entry><filename>/run/systemd/transient</filename></entry>
343 <entry>Dynamic configuration for transient units</entry>
344 </row>
345 <row>
346 <entry><filename>/run/systemd/generator.early</filename></entry>
347 <entry>Generated units with high priority (see <replaceable>early-dir</replaceable> in <citerefentry
348 ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
349 </row>
350 <row>
351 <entry><filename>/etc/systemd/system</filename></entry>
352 <entry>System units created by the administrator</entry>
353 </row>
354 <row>
355 <entry><filename>/run/systemd/system</filename></entry>
356 <entry>Runtime units</entry>
357 </row>
358 <row>
359 <entry><filename>/run/systemd/generator</filename></entry>
360 <entry>Generated units with medium priority (see <replaceable>normal-dir</replaceable> in <citerefentry
361 ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
362 </row>
363 <row>
364 <entry><filename>/usr/local/lib/systemd/system</filename></entry>
365 <entry>System units installed by the administrator </entry>
366 </row>
367 <row>
368 <entry><filename>/usr/lib/systemd/system</filename></entry>
369 <entry>System units installed by the distribution package manager</entry>
370 </row>
371 <row>
372 <entry><filename>/run/systemd/generator.late</filename></entry>
373 <entry>Generated units with low priority (see <replaceable>late-dir</replaceable> in <citerefentry
374 ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
375 </row>
376 </tbody>
377 </tgroup>
378 </table>
379
380 <table>
381 <title>
382 Load path when running in user mode (<option>--user</option>).
383 </title>
384
385 <tgroup cols='2'>
386 <colspec colname='path' />
387 <colspec colname='expl' />
388 <thead>
389 <row>
390 <entry>Path</entry>
391 <entry>Description</entry>
392 </row>
393 </thead>
394 <tbody>
395 <row>
396 <entry><filename>$XDG_CONFIG_HOME/systemd/user.control</filename> or <filename
397 >~/.config/systemd/user.control</filename></entry>
398 <entry morerows="1">Persistent and transient configuration created using the dbus API (<varname>$XDG_CONFIG_HOME</varname> is used if set, <filename>~/.config</filename> otherwise)</entry>
399 </row>
400 <row>
401 <entry><filename>$XDG_RUNTIME_DIR/systemd/user.control</filename></entry>
402 </row>
403 <row>
404 <entry><filename>/run/systemd/transient</filename></entry>
405 <entry>Dynamic configuration for transient units</entry>
406 </row>
407 <row>
408 <entry><filename>/run/systemd/generator.early</filename></entry>
409 <entry>Generated units with high priority (see <replaceable>early-dir</replaceable> in <citerefentry
410 ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
411 </row>
412 <row>
413 <entry><filename>$XDG_CONFIG_HOME/systemd/user</filename> or <filename>$HOME/.config/systemd/user</filename></entry>
414 <entry>User configuration (<varname>$XDG_CONFIG_HOME</varname> is used if set, <filename>~/.config</filename> otherwise)</entry>
415 </row>
416 <row>
417 <entry><filename>/etc/systemd/user</filename></entry>
418 <entry>User units created by the administrator</entry>
419 </row>
420 <row>
421 <entry><filename>$XDG_RUNTIME_DIR/systemd/user</filename></entry>
422 <entry>Runtime units (only used when $XDG_RUNTIME_DIR is set)</entry>
423 </row>
424 <row>
425 <entry><filename>/run/systemd/user</filename></entry>
426 <entry>Runtime units</entry>
427 </row>
428 <row>
429 <entry><filename>$XDG_RUNTIME_DIR/systemd/generator</filename></entry>
430 <entry>Generated units with medium priority (see <replaceable>normal-dir</replaceable> in <citerefentry
431 ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
432 </row>
433 <row>
434 <entry><filename>$XDG_DATA_HOME/systemd/user</filename> or <filename>$HOME/.local/share/systemd/user</filename></entry>
435 <entry>Units of packages that have been installed in the home directory (<varname>$XDG_DATA_HOME</varname> is used if set, <filename>~/.local/share</filename> otherwise)</entry>
436 </row>
437 <row>
438 <entry><filename>$dir/systemd/user</filename> for each <varname noindex='true'>$dir</varname> in <varname>$XDG_DATA_DIRS</varname></entry>
439 <entry>Additional locations for installed user units, one for each entry in <varname>$XDG_DATA_DIRS</varname></entry>
440 </row>
441 <row>
442 <entry><filename>/usr/local/lib/systemd/user</filename></entry>
443 <entry>User units installed by the administrator</entry>
444 </row>
445 <row>
446 <entry><filename>/usr/lib/systemd/user</filename></entry>
447 <entry>User units installed by the distribution package manager</entry>
448 </row>
449 <row>
450 <entry><filename>$XDG_RUNTIME_DIR/systemd/generator.late</filename></entry>
451 <entry>Generated units with low priority (see <replaceable>late-dir</replaceable> in <citerefentry
452 ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
453 </row>
454 </tbody>
455 </tgroup>
456 </table>
457
458 <para>The set of load paths for the user manager instance may be augmented or
459 changed using various environment variables. And environment variables may in
460 turn be set using environment generators, see
461 <citerefentry><refentrytitle>systemd.environment-generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
462 In particular, <varname>$XDG_DATA_HOME</varname> and
463 <varname>$XDG_DATA_DIRS</varname> may be easily set using
464 <citerefentry><refentrytitle>systemd-environment-d-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
465 Thus, directories listed here are just the defaults. To see the actual list that
466 would be used based on compilation options and current environment use
467 <programlisting>systemd-analyze --user unit-paths</programlisting>
468 </para>
469
470 <para>Moreover, additional units might be loaded into systemd ("linked") from
471 directories not on the unit load path. See the <command>link</command> command
472 for
473 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
474 </para>
475 </refsect1>
476
477 <refsect1>
478 <title>Unit Garbage Collection</title>
479
480 <para>The system and service manager loads a unit's configuration automatically when a unit is referenced for the
481 first time. It will automatically unload the unit configuration and state again when the unit is not needed anymore
482 ("garbage collection"). A unit may be referenced through a number of different mechanisms:</para>
483
484 <orderedlist>
485 <listitem><para>Another loaded unit references it with a dependency such as <varname>After=</varname>,
486 <varname>Wants=</varname>, …</para></listitem>
487
488 <listitem><para>The unit is currently starting, running, reloading or stopping.</para></listitem>
489
490 <listitem><para>The unit is currently in the <constant>failed</constant> state. (But see below.)</para></listitem>
491
492 <listitem><para>A job for the unit is pending.</para></listitem>
493
494 <listitem><para>The unit is pinned by an active IPC client program.</para></listitem>
495
496 <listitem><para>The unit is a special "perpetual" unit that is always active and loaded. Examples for perpetual
497 units are the root mount unit <filename>-.mount</filename> or the scope unit <filename>init.scope</filename> that
498 the service manager itself lives in.</para></listitem>
499
500 <listitem><para>The unit has running processes associated with it.</para></listitem>
501 </orderedlist>
502
503 <para>The garbage collection logic may be altered with the <varname>CollectMode=</varname> option, which allows
504 configuration whether automatic unloading of units that are in <constant>failed</constant> state is permissible,
505 see below.</para>
506
507 <para>Note that when a unit's configuration and state is unloaded, all execution results, such as exit codes, exit
508 signals, resource consumption and other statistics are lost, except for what is stored in the log subsystem.</para>
509
510 <para>Use <command>systemctl daemon-reload</command> or an equivalent command to reload unit configuration while
511 the unit is already loaded. In this case all configuration settings are flushed out and replaced with the new
512 configuration (which however might not be in effect immediately), however all runtime state is
513 saved/restored.</para>
514 </refsect1>
515
516 <refsect1>
517 <title>[Unit] Section Options</title>
518
519 <para>The unit file may include a [Unit] section, which carries
520 generic information about the unit that is not dependent on the
521 type of unit:</para>
522
523 <variablelist class='unit-directives'>
524 <varlistentry>
525 <term><varname>Description=</varname></term>
526 <listitem><para>A human readable name for the unit. This is used by
527 <command>systemd</command> (and other UIs) as the label for the unit, so this string should
528 identify the unit rather than describe it, despite the name. <literal>Apache2 Web
529 Server</literal> is a good example. Bad examples are <literal>high-performance light-weight
530 HTTP server</literal> (too generic) or <literal>Apache2</literal> (too specific and
531 meaningless for people who do not know Apache). <command>systemd</command> will use this
532 string as a noun in status messages (<literal>Starting
533 <replaceable>description</replaceable>...</literal>, <literal>Started
534 <replaceable>description</replaceable>.</literal>, <literal>Reached target
535 <replaceable>description</replaceable>.</literal>, <literal>Failed to start
536 <replaceable>description</replaceable>.</literal>), so it should be capitalized, and should
537 not be a full sentence or a phrase with a continuous verb. Bad examples include
538 <literal>exiting the container</literal> or <literal>updating the database once per
539 day.</literal>.</para>
540 </listitem>
541 </varlistentry>
542
543 <varlistentry>
544 <term><varname>Documentation=</varname></term>
545 <listitem><para>A space-separated list of URIs referencing
546 documentation for this unit or its configuration. Accepted are
547 only URIs of the types <literal>http://</literal>,
548 <literal>https://</literal>, <literal>file:</literal>,
549 <literal>info:</literal>, <literal>man:</literal>. For more
550 information about the syntax of these URIs, see <citerefentry
551 project='man-pages'><refentrytitle>uri</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
552 The URIs should be listed in order of relevance, starting with
553 the most relevant. It is a good idea to first reference
554 documentation that explains what the unit's purpose is,
555 followed by how it is configured, followed by any other
556 related documentation. This option may be specified more than
557 once, in which case the specified list of URIs is merged. If
558 the empty string is assigned to this option, the list is reset
559 and all prior assignments will have no
560 effect.</para></listitem>
561 </varlistentry>
562
563 <varlistentry>
564 <term><varname>Requires=</varname></term>
565
566 <listitem><para>Configures requirement dependencies on other units. If this unit gets activated, the units
567 listed here will be activated as well. If one of the other units fails to activate, and an ordering dependency
568 <varname>After=</varname> on the failing unit is set, this unit will not be started. Besides, with or without
569 specifying <varname>After=</varname>, this unit will be stopped if one of the other units is explicitly
570 stopped. This option may be specified more than once or multiple space-separated units may be
571 specified in one option in which case requirement dependencies for all listed names will be created. Note that
572 requirement dependencies do not influence the order in which services are started or stopped. This has to be
573 configured independently with the <varname>After=</varname> or <varname>Before=</varname> options. If a unit
574 <filename>foo.service</filename> requires a unit <filename>bar.service</filename> as configured with
575 <varname>Requires=</varname> and no ordering is configured with <varname>After=</varname> or
576 <varname>Before=</varname>, then both units will be started simultaneously and without any delay between them
577 if <filename>foo.service</filename> is activated. Often, it is a better choice to use <varname>Wants=</varname>
578 instead of <varname>Requires=</varname> in order to achieve a system that is more robust when dealing with
579 failing services.</para>
580
581 <para>Note that this dependency type does not imply that the other unit always has to be in active state when
582 this unit is running. Specifically: failing condition checks (such as <varname>ConditionPathExists=</varname>,
583 <varname>ConditionPathIsSymbolicLink=</varname>, … — see below) do not cause the start job of a unit with a
584 <varname>Requires=</varname> dependency on it to fail. Also, some unit types may deactivate on their own (for
585 example, a service process may decide to exit cleanly, or a device may be unplugged by the user), which is not
586 propagated to units having a <varname>Requires=</varname> dependency. Use the <varname>BindsTo=</varname>
587 dependency type together with <varname>After=</varname> to ensure that a unit may never be in active state
588 without a specific other unit also in active state (see below).</para>
589
590 <para>Note that dependencies of this type may also be configured outside of the unit configuration file by
591 adding a symlink to a <filename>.requires/</filename> directory accompanying the unit file. For details, see
592 above.</para></listitem>
593 </varlistentry>
594
595 <varlistentry>
596 <term><varname>Requisite=</varname></term>
597
598 <listitem><para>Similar to <varname>Requires=</varname>. However, if the units listed here
599 are not started already, they will not be started and the starting of this unit will fail
600 immediately. <varname>Requisite=</varname> does not imply an ordering dependency, even if
601 both units are started in the same transaction. Hence this setting should usually be
602 combined with <varname>After=</varname>, to ensure this unit is not started before the other
603 unit.</para>
604
605 <para>When <varname>Requisite=b.service</varname> is used on
606 <filename>a.service</filename>, this dependency will show as
607 <varname>RequisiteOf=a.service</varname> in property listing of
608 <filename>b.service</filename>. <varname>RequisiteOf=</varname>
609 dependency cannot be specified directly.</para>
610 </listitem>
611 </varlistentry>
612
613 <varlistentry>
614 <term><varname>Wants=</varname></term>
615
616 <listitem><para>A weaker version of
617 <varname>Requires=</varname>. Units listed in this option will
618 be started if the configuring unit is. However, if the listed
619 units fail to start or cannot be added to the transaction,
620 this has no impact on the validity of the transaction as a
621 whole. This is the recommended way to hook start-up of one
622 unit to the start-up of another unit.</para>
623
624 <para>Note that dependencies of this type may also be
625 configured outside of the unit configuration file by adding
626 symlinks to a <filename>.wants/</filename> directory
627 accompanying the unit file. For details, see
628 above.</para></listitem>
629 </varlistentry>
630
631 <varlistentry>
632 <term><varname>BindsTo=</varname></term>
633
634 <listitem><para>Configures requirement dependencies, very similar in style to
635 <varname>Requires=</varname>. However, this dependency type is stronger: in addition to the effect of
636 <varname>Requires=</varname> it declares that if the unit bound to is stopped, this unit will be stopped
637 too. This means a unit bound to another unit that suddenly enters inactive state will be stopped too.
638 Units can suddenly, unexpectedly enter inactive state for different reasons: the main process of a service unit
639 might terminate on its own choice, the backing device of a device unit might be unplugged or the mount point of
640 a mount unit might be unmounted without involvement of the system and service manager.</para>
641
642 <para>When used in conjunction with <varname>After=</varname> on the same unit the behaviour of
643 <varname>BindsTo=</varname> is even stronger. In this case, the unit bound to strictly has to be in active
644 state for this unit to also be in active state. This not only means a unit bound to another unit that suddenly
645 enters inactive state, but also one that is bound to another unit that gets skipped due to a failed condition
646 check (such as <varname>ConditionPathExists=</varname>, <varname>ConditionPathIsSymbolicLink=</varname>, … —
647 see below) will be stopped, should it be running. Hence, in many cases it is best to combine
648 <varname>BindsTo=</varname> with <varname>After=</varname>.</para>
649
650 <para>When <varname>BindsTo=b.service</varname> is used on
651 <filename>a.service</filename>, this dependency will show as
652 <varname>BoundBy=a.service</varname> in property listing of
653 <filename>b.service</filename>. <varname>BoundBy=</varname>
654 dependency cannot be specified directly.</para>
655 </listitem>
656 </varlistentry>
657
658 <varlistentry>
659 <term><varname>PartOf=</varname></term>
660
661 <listitem><para>Configures dependencies similar to
662 <varname>Requires=</varname>, but limited to stopping and
663 restarting of units. When systemd stops or restarts the units
664 listed here, the action is propagated to this unit. Note that
665 this is a one-way dependency — changes to this unit do not
666 affect the listed units.</para>
667
668 <para>When <varname>PartOf=b.service</varname> is used on
669 <filename>a.service</filename>, this dependency will show as
670 <varname>ConsistsOf=a.service</varname> in property listing of
671 <filename>b.service</filename>. <varname>ConsistsOf=</varname>
672 dependency cannot be specified directly.</para>
673 </listitem>
674 </varlistentry>
675
676 <varlistentry>
677 <term><varname>Conflicts=</varname></term>
678
679 <listitem><para>A space-separated list of unit names.
680 Configures negative requirement dependencies. If a unit has a
681 <varname>Conflicts=</varname> setting on another unit,
682 starting the former will stop the latter and vice versa. Note
683 that this setting is independent of and orthogonal to the
684 <varname>After=</varname> and <varname>Before=</varname>
685 ordering dependencies.</para>
686
687 <para>If a unit A that conflicts with a unit B is scheduled to
688 be started at the same time as B, the transaction will either
689 fail (in case both are required parts of the transaction) or be
690 modified to be fixed (in case one or both jobs are not a
691 required part of the transaction). In the latter case, the job
692 that is not required will be removed, or in case both are
693 not required, the unit that conflicts will be started and the
694 unit that is conflicted is stopped.</para></listitem>
695 </varlistentry>
696
697 <varlistentry>
698 <term><varname>Before=</varname></term>
699 <term><varname>After=</varname></term>
700
701 <listitem><para>These two settings expect a space-separated list of unit names. They configure ordering
702 dependencies between units. If a unit <filename>foo.service</filename> contains a setting
703 <option>Before=bar.service</option> and both units are being started, <filename>bar.service</filename>'s
704 start-up is delayed until <filename>foo.service</filename> has finished starting up. Note that this setting is
705 independent of and orthogonal to the requirement dependencies as configured by <varname>Requires=</varname>,
706 <varname>Wants=</varname> or <varname>BindsTo=</varname>. It is a common pattern to include a unit name in both
707 the <varname>After=</varname> and <varname>Requires=</varname> options, in which case the unit listed will be
708 started before the unit that is configured with these options. This option may be specified more than once, in
709 which case ordering dependencies for all listed names are created. <varname>After=</varname> is the inverse of
710 <varname>Before=</varname>, i.e. while <varname>After=</varname> ensures that the configured unit is started
711 after the listed unit finished starting up, <varname>Before=</varname> ensures the opposite, that the
712 configured unit is fully started up before the listed unit is started. Note that when two units with an
713 ordering dependency between them are shut down, the inverse of the start-up order is applied. i.e. if a unit is
714 configured with <varname>After=</varname> on another unit, the former is stopped before the latter if both are
715 shut down. Given two units with any ordering dependency between them, if one unit is shut down and the other is
716 started up, the shutdown is ordered before the start-up. It doesn't matter if the ordering dependency is
717 <varname>After=</varname> or <varname>Before=</varname>, in this case. It also doesn't matter which of the two
718 is shut down, as long as one is shut down and the other is started up. The shutdown is ordered before the
719 start-up in all cases. If two units have no ordering dependencies between them, they are shut down or started
720 up simultaneously, and no ordering takes place. It depends on the unit type when precisely a unit has finished
721 starting up. Most importantly, for service units start-up is considered completed for the purpose of
722 <varname>Before=</varname>/<varname>After=</varname> when all its configured start-up commands have been
723 invoked and they either failed or reported start-up success.</para></listitem>
724 </varlistentry>
725
726 <varlistentry>
727 <term><varname>OnFailure=</varname></term>
728
729 <listitem><para>A space-separated list of one or more units
730 that are activated when this unit enters the
731 <literal>failed</literal> state. A service unit using
732 <varname>Restart=</varname> enters the failed state only after
733 the start limits are reached.</para></listitem>
734 </varlistentry>
735
736 <varlistentry>
737 <term><varname>PropagatesReloadTo=</varname></term>
738 <term><varname>ReloadPropagatedFrom=</varname></term>
739
740 <listitem><para>A space-separated list of one or more units
741 where reload requests on this unit will be propagated to, or
742 reload requests on the other unit will be propagated to this
743 unit, respectively. Issuing a reload request on a unit will
744 automatically also enqueue a reload request on all units that
745 the reload request shall be propagated to via these two
746 settings.</para></listitem>
747 </varlistentry>
748
749 <varlistentry>
750 <term><varname>JoinsNamespaceOf=</varname></term>
751
752 <listitem><para>For units that start processes (such as service units), lists one or more other units
753 whose network and/or temporary file namespace to join. This only applies to unit types which support
754 the <varname>PrivateNetwork=</varname>, <varname>NetworkNamespacePath=</varname> and
755 <varname>PrivateTmp=</varname> directives (see
756 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
757 details). If a unit that has this setting set is started, its processes will see the same
758 <filename>/tmp</filename>, <filename>/var/tmp</filename> and network namespace as one listed unit
759 that is started. If multiple listed units are already started, it is not defined which namespace is
760 joined. Note that this setting only has an effect if
761 <varname>PrivateNetwork=</varname>/<varname>NetworkNamespacePath=</varname> and/or
762 <varname>PrivateTmp=</varname> is enabled for both the unit that joins the namespace and the unit
763 whose namespace is joined.</para></listitem>
764 </varlistentry>
765
766 <varlistentry>
767 <term><varname>RequiresMountsFor=</varname></term>
768
769 <listitem><para>Takes a space-separated list of absolute
770 paths. Automatically adds dependencies of type
771 <varname>Requires=</varname> and <varname>After=</varname> for
772 all mount units required to access the specified path.</para>
773
774 <para>Mount points marked with <option>noauto</option> are not
775 mounted automatically through <filename>local-fs.target</filename>,
776 but are still honored for the purposes of this option, i.e. they
777 will be pulled in by this unit.</para></listitem>
778 </varlistentry>
779
780 <varlistentry>
781 <term><varname>OnFailureJobMode=</varname></term>
782
783 <listitem><para>Takes a value of
784 <literal>fail</literal>,
785 <literal>replace</literal>,
786 <literal>replace-irreversibly</literal>,
787 <literal>isolate</literal>,
788 <literal>flush</literal>,
789 <literal>ignore-dependencies</literal> or
790 <literal>ignore-requirements</literal>. Defaults to
791 <literal>replace</literal>. Specifies how the units listed in
792 <varname>OnFailure=</varname> will be enqueued. See
793 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
794 <option>--job-mode=</option> option for details on the
795 possible values. If this is set to <literal>isolate</literal>,
796 only a single unit may be listed in
797 <varname>OnFailure=</varname>..</para></listitem>
798 </varlistentry>
799
800 <varlistentry>
801 <term><varname>IgnoreOnIsolate=</varname></term>
802
803 <listitem><para>Takes a boolean argument. If <option>true</option>, this unit
804 will not be stopped when isolating another unit. Defaults to
805 <option>false</option> for service, target, socket, busname, timer, and path
806 units, and <option>true</option> for slice, scope, device, swap, mount, and
807 automount units.</para></listitem>
808 </varlistentry>
809
810 <varlistentry>
811 <term><varname>StopWhenUnneeded=</varname></term>
812
813 <listitem><para>Takes a boolean argument. If
814 <option>true</option>, this unit will be stopped when it is no
815 longer used. Note that, in order to minimize the work to be
816 executed, systemd will not stop units by default unless they
817 are conflicting with other units, or the user explicitly
818 requested their shut down. If this option is set, a unit will
819 be automatically cleaned up if no other active unit requires
820 it. Defaults to <option>false</option>.</para></listitem>
821 </varlistentry>
822
823 <varlistentry>
824 <term><varname>RefuseManualStart=</varname></term>
825 <term><varname>RefuseManualStop=</varname></term>
826
827 <listitem><para>Takes a boolean argument. If
828 <option>true</option>, this unit can only be activated or
829 deactivated indirectly. In this case, explicit start-up or
830 termination requested by the user is denied, however if it is
831 started or stopped as a dependency of another unit, start-up
832 or termination will succeed. This is mostly a safety feature
833 to ensure that the user does not accidentally activate units
834 that are not intended to be activated explicitly, and not
835 accidentally deactivate units that are not intended to be
836 deactivated. These options default to
837 <option>false</option>.</para></listitem>
838 </varlistentry>
839
840 <varlistentry>
841 <term><varname>AllowIsolate=</varname></term>
842
843 <listitem><para>Takes a boolean argument. If
844 <option>true</option>, this unit may be used with the
845 <command>systemctl isolate</command> command. Otherwise, this
846 will be refused. It probably is a good idea to leave this
847 disabled except for target units that shall be used similar to
848 runlevels in SysV init systems, just as a precaution to avoid
849 unusable system states. This option defaults to
850 <option>false</option>.</para></listitem>
851 </varlistentry>
852
853 <varlistentry>
854 <term><varname>DefaultDependencies=</varname></term>
855
856 <listitem><para>Takes a boolean argument. If
857 <option>yes</option>, (the default), a few default
858 dependencies will implicitly be created for the unit. The
859 actual dependencies created depend on the unit type. For
860 example, for service units, these dependencies ensure that the
861 service is started only after basic system initialization is
862 completed and is properly terminated on system shutdown. See
863 the respective man pages for details. Generally, only services
864 involved with early boot or late shutdown should set this
865 option to <option>no</option>. It is highly recommended to
866 leave this option enabled for the majority of common units. If
867 set to <option>no</option>, this option does not disable
868 all implicit dependencies, just non-essential
869 ones.</para></listitem>
870 </varlistentry>
871
872 <varlistentry>
873 <term><varname>CollectMode=</varname></term>
874
875 <listitem><para>Tweaks the "garbage collection" algorithm for this unit. Takes one of <option>inactive</option>
876 or <option>inactive-or-failed</option>. If set to <option>inactive</option> the unit will be unloaded if it is
877 in the <constant>inactive</constant> state and is not referenced by clients, jobs or other units — however it
878 is not unloaded if it is in the <constant>failed</constant> state. In <option>failed</option> mode, failed
879 units are not unloaded until the user invoked <command>systemctl reset-failed</command> on them to reset the
880 <constant>failed</constant> state, or an equivalent command. This behaviour is altered if this option is set to
881 <option>inactive-or-failed</option>: in this case the unit is unloaded even if the unit is in a
882 <constant>failed</constant> state, and thus an explicitly resetting of the <constant>failed</constant> state is
883 not necessary. Note that if this mode is used unit results (such as exit codes, exit signals, consumed
884 resources, …) are flushed out immediately after the unit completed, except for what is stored in the logging
885 subsystem. Defaults to <option>inactive</option>.</para>
886 </listitem>
887 </varlistentry>
888
889 <varlistentry>
890 <term><varname>FailureAction=</varname></term>
891 <term><varname>SuccessAction=</varname></term>
892
893 <listitem><para>Configure the action to take when the unit stops and enters a failed state or inactive state.
894 Takes one of <option>none</option>, <option>reboot</option>, <option>reboot-force</option>,
895 <option>reboot-immediate</option>, <option>poweroff</option>, <option>poweroff-force</option>,
896 <option>poweroff-immediate</option>, <option>exit</option>, and <option>exit-force</option>. In system mode,
897 all options are allowed. In user mode, only <option>none</option>, <option>exit</option>, and
898 <option>exit-force</option> are allowed. Both options default to <option>none</option>.</para>
899
900 <para>If <option>none</option> is set, no action will be triggered. <option>reboot</option> causes a reboot
901 following the normal shutdown procedure (i.e. equivalent to <command>systemctl reboot</command>).
902 <option>reboot-force</option> causes a forced reboot which will terminate all processes forcibly but should
903 cause no dirty file systems on reboot (i.e. equivalent to <command>systemctl reboot -f</command>) and
904 <option>reboot-immediate</option> causes immediate execution of the
905 <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call, which
906 might result in data loss (i.e. equivalent to <command>systemctl reboot -ff</command>). Similarly,
907 <option>poweroff</option>, <option>poweroff-force</option>, <option>poweroff-immediate</option> have the effect
908 of powering down the system with similar semantics. <option>exit</option> causes the manager to exit following
909 the normal shutdown procedure, and <option>exit-force</option> causes it terminate without shutting down
910 services. When <option>exit</option> or <option>exit-force</option> is used by default the exit status of the
911 main process of the unit (if this applies) is returned from the service manager. However, this may be overridden
912 with <varname>FailureActionExitStatus=</varname>/<varname>SuccessActionExitStatus=</varname>, see
913 below.</para></listitem>
914 </varlistentry>
915
916 <varlistentry>
917 <term><varname>FailureActionExitStatus=</varname></term>
918 <term><varname>SuccessActionExitStatus=</varname></term>
919
920 <listitem><para>Controls the exit status to propagate back to an invoking container manager (in case of a
921 system service) or service manager (in case of a user manager) when the
922 <varname>FailureAction=</varname>/<varname>SuccessAction=</varname> are set to <option>exit</option> or
923 <option>exit-force</option> and the action is triggered. By default the exit status of the main process of the
924 triggering unit (if this applies) is propagated. Takes a value in the range 0255 or the empty string to
925 request default behaviour.</para></listitem>
926 </varlistentry>
927
928 <varlistentry>
929 <term><varname>JobTimeoutSec=</varname></term>
930 <term><varname>JobRunningTimeoutSec=</varname></term>
931
932 <listitem><para>When a job for this unit is queued, a timeout <varname>JobTimeoutSec=</varname> may be
933 configured. Similarly, <varname>JobRunningTimeoutSec=</varname> starts counting when the queued job is actually
934 started. If either time limit is reached, the job will be cancelled, the unit however will not change state or
935 even enter the <literal>failed</literal> mode. This value defaults to <literal>infinity</literal> (job timeouts
936 disabled), except for device units (<varname>JobRunningTimeoutSec=</varname> defaults to
937 <varname>DefaultTimeoutStartSec=</varname>). NB: this timeout is independent from any unit-specific timeout
938 (for example, the timeout set with <varname>TimeoutStartSec=</varname> in service units) as the job timeout has
939 no effect on the unit itself, only on the job that might be pending for it. Or in other words: unit-specific
940 timeouts are useful to abort unit state changes, and revert them. The job timeout set with this option however
941 is useful to abort only the job waiting for the unit state to change.</para>
942 </listitem>
943 </varlistentry>
944
945 <varlistentry>
946 <term><varname>JobTimeoutAction=</varname></term>
947 <term><varname>JobTimeoutRebootArgument=</varname></term>
948
949 <listitem><para><varname>JobTimeoutAction=</varname> optionally configures an additional action to take when
950 the timeout is hit, see description of <varname>JobTimeoutSec=</varname> and
951 <varname>JobRunningTimeoutSec=</varname> above. It takes the same values as
952 <varname>StartLimitAction=</varname>. Defaults to <option>none</option>.
953 <varname>JobTimeoutRebootArgument=</varname> configures an optional reboot string to pass to the
954 <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call.
955 </para></listitem>
956 </varlistentry>
957
958 <varlistentry>
959 <term><varname>StartLimitIntervalSec=<replaceable>interval</replaceable></varname></term>
960 <term><varname>StartLimitBurst=<replaceable>burst</replaceable></varname></term>
961
962 <listitem><para>Configure unit start rate limiting. Units which are started more than
963 <replaceable>burst</replaceable> times within an <replaceable>interval</replaceable> time interval are not
964 permitted to start any more. Use <varname>StartLimitIntervalSec=</varname> to configure the checking interval
965 (defaults to <varname>DefaultStartLimitIntervalSec=</varname> in manager configuration file, set it to 0 to
966 disable any kind of rate limiting). Use <varname>StartLimitBurst=</varname> to configure how many starts per
967 interval are allowed (defaults to <varname>DefaultStartLimitBurst=</varname> in manager configuration
968 file). These configuration options are particularly useful in conjunction with the service setting
969 <varname>Restart=</varname> (see
970 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>); however,
971 they apply to all kinds of starts (including manual), not just those triggered by the
972 <varname>Restart=</varname> logic. Note that units which are configured for <varname>Restart=</varname> and
973 which reach the start limit are not attempted to be restarted anymore; however, they may still be restarted
974 manually at a later point, after the <replaceable>interval</replaceable> has passed. From this point on, the
975 restart logic is activated again. Note that <command>systemctl reset-failed</command> will cause the restart
976 rate counter for a service to be flushed, which is useful if the administrator wants to manually start a unit
977 and the start limit interferes with that. Note that this rate-limiting is enforced after any unit condition
978 checks are executed, and hence unit activations with failing conditions do not count towards this rate
979 limit. This setting does not apply to slice, target, device, and scope units, since they are unit types whose
980 activation may either never fail, or may succeed only a single time.</para>
981
982 <para>When a unit is unloaded due to the garbage collection logic (see above) its rate limit counters are
983 flushed out too. This means that configuring start rate limiting for a unit that is not referenced continuously
984 has no effect.</para></listitem>
985 </varlistentry>
986
987 <varlistentry>
988 <term><varname>StartLimitAction=</varname></term>
989
990 <listitem><para>Configure an additional action to take if the rate limit configured with
991 <varname>StartLimitIntervalSec=</varname> and <varname>StartLimitBurst=</varname> is hit. Takes the same
992 values as the setting <varname>FailureAction=</varname>/<varname>SuccessAction=</varname> settings and executes
993 the same actions. If <option>none</option> is set, hitting the rate limit will trigger no action besides that
994 the start will not be permitted. Defaults to <option>none</option>.</para></listitem>
995 </varlistentry>
996
997 <varlistentry>
998 <term><varname>RebootArgument=</varname></term>
999 <listitem><para>Configure the optional argument for the
1000 <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call if
1001 <varname>StartLimitAction=</varname> or <varname>FailureAction=</varname> is a reboot action. This
1002 works just like the optional argument to <command>systemctl reboot</command> command.</para></listitem>
1003 </varlistentry>
1004
1005 <varlistentry>
1006 <term><varname>SourcePath=</varname></term>
1007 <listitem><para>A path to a configuration file this unit has
1008 been generated from. This is primarily useful for
1009 implementation of generator tools that convert configuration
1010 from an external configuration file format into native unit
1011 files. This functionality should not be used in normal
1012 units.</para></listitem>
1013 </varlistentry>
1014 </variablelist>
1015
1016 <refsect2>
1017 <title>Conditions and Asserts</title>
1018
1019 <para>Unit files may also include a number of <varname noindex="true">Condition…=</varname> and
1020 <varname noindex="true">Assert…=</varname> settings. Before the unit is started, systemd will verify
1021 that the specified conditions are true. If not, the starting of the unit will be (mostly silently)
1022 skipped. Failing conditions will not result in the unit being moved into the <literal>failed</literal>
1023 state. The conditions are checked at the time the queued start job is to be executed. The ordering
1024 dependencies are still respected, so other units are still pulled in and ordered as if this unit was
1025 successfully activated. Use condition expressions in order to skip units that do not apply to the local
1026 system, for example because the kernel or runtime environment doesn't require their functionality.
1027 </para>
1028
1029 <para>If multiple conditions are specified, the unit will be executed if all of them apply (i.e. a
1030 logical AND is applied). Condition checks can use a pipe symbol (<literal>|</literal>) after the equals
1031 sign (<literal>Condition…=|…</literal>), which causes the condition becomes a triggering condition. If
1032 at least one triggering condition is defined for a unit, then the unit will be executed if at least one
1033 of the triggering conditions apply and all of the non-triggering conditions. If you prefix an argument
1034 with the pipe symbol and an exclamation mark, the pipe symbol must be passed first, the exclamation
1035 second. If any of these options is assigned the empty string, the list of conditions is reset
1036 completely, all previous condition settings (of any kind) will have no effect.</para>
1037
1038 <para>The <varname>AssertArchitecture=</varname>, <varname>AssertVirtualization=</varname>, … options
1039 provide a similar mechanism that causes the job to fail (instead of being skipped). The failed check is
1040 logged. Units with failed conditions are considered to be in a clean state and will be garbage
1041 collected if they are not referenced. This means that when queried, the condition failure may or may
1042 not show up in the state of the unit.</para>
1043
1044 <para>Note that neither assertion nor condition expressions result in unit state changes. Also note
1045 that both are checked at the time the job is to be executed, i.e. long after depending jobs and it
1046 itself were queued. Thus, neither condition nor assertion expressions are suitable for conditionalizing
1047 unit dependencies.</para>
1048
1049 <para>The <command>condition</command> verb of
1050 <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry> can
1051 be used to test condition and assert expressions.</para>
1052
1053 <para>Except for <varname>ConditionPathIsSymbolicLink=</varname>, all path checks follow symlinks.</para>
1054
1055 <variablelist class='unit-directives'>
1056 <!-- We do not document ConditionNull= here, as it is not particularly useful and probably just
1057 confusing. -->
1058
1059 <varlistentry>
1060 <term><varname>ConditionArchitecture=</varname></term>
1061
1062 <listitem><para>Check whether the system is running on a specific architecture. Takes one of
1063 <literal>x86</literal>,
1064 <literal>x86-64</literal>,
1065 <literal>ppc</literal>,
1066 <literal>ppc-le</literal>,
1067 <literal>ppc64</literal>,
1068 <literal>ppc64-le</literal>,
1069 <literal>ia64</literal>,
1070 <literal>parisc</literal>,
1071 <literal>parisc64</literal>,
1072 <literal>s390</literal>,
1073 <literal>s390x</literal>,
1074 <literal>sparc</literal>,
1075 <literal>sparc64</literal>,
1076 <literal>mips</literal>,
1077 <literal>mips-le</literal>,
1078 <literal>mips64</literal>,
1079 <literal>mips64-le</literal>,
1080 <literal>alpha</literal>,
1081 <literal>arm</literal>,
1082 <literal>arm-be</literal>,
1083 <literal>arm64</literal>,
1084 <literal>arm64-be</literal>,
1085 <literal>sh</literal>,
1086 <literal>sh64</literal>,
1087 <literal>m68k</literal>,
1088 <literal>tilegx</literal>,
1089 <literal>cris</literal>,
1090 <literal>arc</literal>,
1091 <literal>arc-be</literal>, or
1092 <literal>native</literal>.</para>
1093
1094 <para>The architecture is determined from the information returned by
1095 <citerefentry project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
1096 and is thus subject to
1097 <citerefentry><refentrytitle>personality</refentrytitle><manvolnum>2</manvolnum></citerefentry>.
1098 Note that a <varname>Personality=</varname> setting in the same unit file has no effect on this
1099 condition. A special architecture name <literal>native</literal> is mapped to the architecture the
1100 system manager itself is compiled for. The test may be negated by prepending an exclamation
1101 mark.</para>
1102 </listitem>
1103 </varlistentry>
1104
1105 <varlistentry>
1106 <term><varname>ConditionArchitecture=</varname></term>
1107
1108 <listitem><para>Check whether the system is executed in a virtualized environment and optionally
1109 test whether it is a specific implementation. Takes either boolean value to check if being executed
1110 in any virtualized environment, or one of
1111 <literal>vm</literal> and
1112 <literal>container</literal> to test against a generic type of virtualization solution, or one of
1113 <literal>qemu</literal>,
1114 <literal>kvm</literal>,
1115 <literal>zvm</literal>,
1116 <literal>vmware</literal>,
1117 <literal>microsoft</literal>,
1118 <literal>oracle</literal>,
1119 <literal>xen</literal>,
1120 <literal>bochs</literal>,
1121 <literal>uml</literal>,
1122 <literal>bhyve</literal>,
1123 <literal>qnx</literal>,
1124 <literal>openvz</literal>,
1125 <literal>lxc</literal>,
1126 <literal>lxc-libvirt</literal>,
1127 <literal>systemd-nspawn</literal>,
1128 <literal>docker</literal>,
1129 <literal>podman</literal>,
1130 <literal>rkt</literal>,
1131 <literal>wsl</literal>,
1132 <literal>acrn</literal> to test
1133 against a specific implementation, or
1134 <literal>private-users</literal> to check whether we are running in a user namespace. See
1135 <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1136 for a full list of known virtualization technologies and their identifiers. If multiple
1137 virtualization technologies are nested, only the innermost is considered. The test may be negated
1138 by prepending an exclamation mark.</para>
1139 </listitem>
1140 </varlistentry>
1141
1142 <varlistentry>
1143 <term><varname>ConditionHost=</varname></term>
1144
1145 <listitem><para><varname>ConditionHost=</varname> may be used to match against the hostname or
1146 machine ID of the host. This either takes a hostname string (optionally with shell style globs)
1147 which is tested against the locally set hostname as returned by
1148 <citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>, or
1149 a machine ID formatted as string (see
1150 <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
1151 The test may be negated by prepending an exclamation mark.</para>
1152 </listitem>
1153 </varlistentry>
1154
1155 <varlistentry>
1156 <term><varname>ConditionKernelCommandLine=</varname></term>
1157
1158 <listitem><para><varname>ConditionKernelCommandLine=</varname> may be used to check whether a
1159 specific kernel command line option is set (or if prefixed with the exclamation mark — unset). The
1160 argument must either be a single word, or an assignment (i.e. two words, separated by
1161 <literal>=</literal>). In the former case the kernel command line is searched for the word
1162 appearing as is, or as left hand side of an assignment. In the latter case, the exact assignment is
1163 looked for with right and left hand side matching.</para>
1164 </listitem>
1165 </varlistentry>
1166
1167 <varlistentry>
1168 <term><varname>ConditionKernelVersion=</varname></term>
1169
1170 <listitem><para><varname>ConditionKernelVersion=</varname> may be used to check whether the kernel
1171 version (as reported by <command>uname -r</command>) matches a certain expression (or if prefixed
1172 with the exclamation mark does not match it). The argument must be a list of (potentially quoted)
1173 expressions. For each of the expressions, if it starts with one of <literal>&lt;</literal>,
1174 <literal>&lt;=</literal>, <literal>=</literal>, <literal>!=</literal>, <literal>&gt;=</literal>,
1175 <literal>&gt;</literal> a relative version comparison is done, otherwise the specified string is
1176 matched with shell-style globs.</para>
1177
1178 <para>Note that using the kernel version string is an unreliable way to determine which features
1179 are supported by a kernel, because of the widespread practice of backporting drivers, features, and
1180 fixes from newer upstream kernels into older versions provided by distributions. Hence, this check
1181 is inherently unportable and should not be used for units which may be used on different
1182 distributions.</para>
1183 </listitem>
1184 </varlistentry>
1185
1186 <varlistentry>
1187 <term><varname>ConditionSecurity=</varname></term>
1188
1189 <listitem><para><varname>ConditionSecurity=</varname> may be used to check whether the given
1190 security technology is enabled on the system. Currently, the recognized values are
1191 <literal>selinux</literal>, <literal>apparmor</literal>, <literal>tomoyo</literal>,
1192 <literal>ima</literal>, <literal>smack</literal>, <literal>audit</literal> and
1193 <literal>uefi-secureboot</literal>. The test may be negated by prepending an exclamation
1194 mark.</para>
1195 </listitem>
1196 </varlistentry>
1197
1198 <varlistentry>
1199 <term><varname>ConditionCapability=</varname></term>
1200
1201 <listitem><para>Check whether the given capability exists in the capability bounding set of the
1202 service manager (i.e. this does not check whether capability is actually available in the permitted
1203 or effective sets, see
1204 <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1205 for details). Pass a capability name such as <literal>CAP_MKNOD</literal>, possibly prefixed with
1206 an exclamation mark to negate the check.</para>
1207 </listitem>
1208 </varlistentry>
1209
1210 <varlistentry>
1211 <term><varname>ConditionACPower=</varname></term>
1212
1213 <listitem><para>Check whether the system has AC power, or is exclusively battery powered at the
1214 time of activation of the unit. This takes a boolean argument. If set to <literal>true</literal>,
1215 the condition will hold only if at least one AC connector of the system is connected to a power
1216 source, or if no AC connectors are known. Conversely, if set to <literal>false</literal>, the
1217 condition will hold only if there is at least one AC connector known and all AC connectors are
1218 disconnected from a power source.</para>
1219 </listitem>
1220 </varlistentry>
1221
1222 <varlistentry>
1223 <term><varname>ConditionNeedsUpdate=</varname></term>
1224
1225 <listitem><para>Takes one of <filename>/var</filename> or <filename>/etc</filename> as argument,
1226 possibly prefixed with a <literal>!</literal> (to inverting the condition). This condition may be
1227 used to conditionalize units on whether the specified directory requires an update because
1228 <filename>/usr</filename>'s modification time is newer than the stamp file
1229 <filename>.updated</filename> in the specified directory. This is useful to implement offline
1230 updates of the vendor operating system resources in <filename>/usr</filename> that require updating
1231 of <filename>/etc</filename> or <filename>/var</filename> on the next following boot. Units making
1232 use of this condition should order themselves before
1233 <citerefentry><refentrytitle>systemd-update-done.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1234 to make sure they run before the stamp file's modification time gets reset indicating a completed
1235 update.</para>
1236 </listitem>
1237 </varlistentry>
1238
1239 <varlistentry>
1240 <term><varname>ConditionFirstBoot=</varname></term>
1241
1242 <listitem><para>Takes a boolean argument. This condition may be used to conditionalize units on
1243 whether the system is booting up with an unpopulated <filename>/etc</filename> directory
1244 (specifically: an <filename>/etc</filename> with no <filename>/etc/machine-id</filename>). This may
1245 be used to populate <filename>/etc</filename> on the first boot after factory reset, or when a new
1246 system instance boots up for the first time.</para>
1247 </listitem>
1248 </varlistentry>
1249
1250 <varlistentry>
1251 <term><varname>ConditionPathExists=</varname></term>
1252
1253 <listitem><para>Check for the exists of a file. If the specified absolute path name does not exist,
1254 the condition will fail. If the absolute path name passed to
1255 <varname>ConditionPathExists=</varname> is prefixed with an exclamation mark
1256 (<literal>!</literal>), the test is negated, and the unit is only started if the path does not
1257 exist.</para>
1258 </listitem>
1259 </varlistentry>
1260
1261 <varlistentry>
1262 <term><varname>ConditionPathExistsGlob=</varname></term>
1263
1264 <listitem><para><varname>ConditionPathExistsGlob=</varname> is similar to
1265 <varname>ConditionPathExists=</varname>, but checks for the existence of at least one file or
1266 directory matching the specified globbing pattern.</para>
1267 </listitem>
1268 </varlistentry>
1269
1270 <varlistentry>
1271 <term><varname>ConditionPathIsDirectory=</varname></term>
1272
1273 <listitem><para><varname>ConditionPathIsDirectory=</varname> is similar to
1274 <varname>ConditionPathExists=</varname> but verifies that a certain path exists and is a
1275 directory.</para>
1276 </listitem>
1277 </varlistentry>
1278
1279 <varlistentry>
1280 <term><varname>ConditionPathIsSymbolicLink=</varname></term>
1281
1282 <listitem><para><varname>ConditionPathIsSymbolicLink=</varname> is similar to
1283 <varname>ConditionPathExists=</varname> but verifies that a certain path exists and is a symbolic
1284 link.</para>
1285 </listitem>
1286 </varlistentry>
1287
1288 <varlistentry>
1289 <term><varname>ConditionPathIsMountPoint=</varname></term>
1290
1291 <listitem><para><varname>ConditionPathIsMountPoint=</varname> is similar to
1292 <varname>ConditionPathExists=</varname> but verifies that a certain path exists and is a mount
1293 point.</para>
1294 </listitem>
1295 </varlistentry>
1296
1297 <varlistentry>
1298 <term><varname>ConditionPathIsReadWrite=</varname></term>
1299
1300 <listitem><para><varname>ConditionPathIsReadWrite=</varname> is similar to
1301 <varname>ConditionPathExists=</varname> but verifies that the underlying file system is readable
1302 and writable (i.e. not mounted read-only).</para>
1303 </listitem>
1304 </varlistentry>
1305
1306 <varlistentry>
1307 <term><varname>ConditionDirectoryNotEmpty=</varname></term>
1308
1309 <listitem><para><varname>ConditionDirectoryNotEmpty=</varname> is similar to
1310 <varname>ConditionPathExists=</varname> but verifies that a certain path exists and is a non-empty
1311 directory.</para>
1312 </listitem>
1313 </varlistentry>
1314
1315 <varlistentry>
1316 <term><varname>ConditionFileNotEmpty=</varname></term>
1317
1318 <listitem><para><varname>ConditionFileNotEmpty=</varname> is similar to
1319 <varname>ConditionPathExists=</varname> but verifies that a certain path exists and refers to a
1320 regular file with a non-zero size.</para>
1321 </listitem>
1322 </varlistentry>
1323
1324 <varlistentry>
1325 <term><varname>ConditionFileIsExecutable=</varname></term>
1326
1327 <listitem><para><varname>ConditionFileIsExecutable=</varname> is similar to
1328 <varname>ConditionPathExists=</varname> but verifies that a certain path exists, is a regular file,
1329 and marked executable.</para>
1330 </listitem>
1331 </varlistentry>
1332
1333 <varlistentry>
1334 <term><varname>ConditionUser=</varname></term>
1335
1336 <listitem><para><varname>ConditionUser=</varname> takes a numeric <literal>UID</literal>, a UNIX
1337 user name, or the special value <literal>@system</literal>. This condition may be used to check
1338 whether the service manager is running as the given user. The special value
1339 <literal>@system</literal> can be used to check if the user id is within the system user
1340 range. This option is not useful for system services, as the system manager exclusively runs as the
1341 root user, and thus the test result is constant.</para>
1342 </listitem>
1343 </varlistentry>
1344
1345 <varlistentry>
1346 <term><varname>ConditionGroup=</varname></term>
1347
1348 <listitem><para><varname>ConditionGroup=</varname> is similar to <varname>ConditionUser=</varname>
1349 but verifies that the service manager's real or effective group, or any of its auxiliary groups,
1350 match the specified group or GID. This setting does not support the special value
1351 <literal>@system</literal>.</para>
1352 </listitem>
1353 </varlistentry>
1354
1355 <varlistentry>
1356 <term><varname>ConditionControlGroupController=</varname></term>
1357
1358 <listitem><para>Verify that the given cgroup controller (eg. <literal>cpu</literal>) is available
1359 for use on the system. For example, a particular controller may not be available if it was disabled
1360 on the kernel command line with <varname>cgroup_disable=controller</varname>. Multiple controllers
1361 may be passed with a space separating them; in this case the condition will only pass if all listed
1362 controllers are available for use. Controllers unknown to systemd are ignored. Valid controllers
1363 are <literal>cpu</literal>, <literal>cpuacct</literal>, <literal>io</literal>,
1364 <literal>blkio</literal>, <literal>memory</literal>, <literal>devices</literal>, and
1365 <literal>pids</literal>.</para>
1366 </listitem>
1367 </varlistentry>
1368
1369 <varlistentry>
1370 <term><varname>ConditionMemory=</varname></term>
1371
1372 <listitem><para>Verify that the specified amount of system memory is available to the current
1373 system. Takes a memory size in bytes as argument, optionally prefixed with a comparison operator
1374 <literal>&lt;</literal>, <literal>&lt;=</literal>, <literal>=</literal>, <literal>!=</literal>,
1375 <literal>&gt;=</literal>, <literal>&gt;</literal>. On bare-metal systems compares the amount of
1376 physical memory in the system with the specified size, adhering to the specified comparison
1377 operator. In containers compares the amount of memory assigned to the container instead.</para>
1378 </listitem>
1379 </varlistentry>
1380
1381 <varlistentry>
1382 <term><varname>ConditionCPUs=</varname></term>
1383
1384 <listitem><para>Verify that the specified number of CPUs is available to the current system. Takes
1385 a number of CPUs as argument, optionally prefixed with a comparison operator
1386 <literal>&lt;</literal>, <literal>&lt;=</literal>, <literal>=</literal>, <literal>!=</literal>,
1387 <literal>&gt;=</literal>, <literal>&gt;</literal>. Compares the number of CPUs in the CPU affinity
1388 mask configured of the service manager itself with the specified number, adhering to the specified
1389 comparison operator. On physical systems the number of CPUs in the affinity mask of the service
1390 manager usually matches the number of physical CPUs, but in special and virtual environments might
1391 differ. In particular, in containers the affinity mask usually matches the number of CPUs assigned
1392 to the container and not the physically available ones.</para></listitem>
1393 </varlistentry>
1394
1395 <varlistentry>
1396 <term><varname>AssertArchitecture=</varname></term>
1397 <term><varname>AssertVirtualization=</varname></term>
1398 <term><varname>AssertHost=</varname></term>
1399 <term><varname>AssertKernelCommandLine=</varname></term>
1400 <term><varname>AssertKernelVersion=</varname></term>
1401 <term><varname>AssertSecurity=</varname></term>
1402 <term><varname>AssertCapability=</varname></term>
1403 <term><varname>AssertACPower=</varname></term>
1404 <term><varname>AssertNeedsUpdate=</varname></term>
1405 <term><varname>AssertFirstBoot=</varname></term>
1406 <term><varname>AssertPathExists=</varname></term>
1407 <term><varname>AssertPathExistsGlob=</varname></term>
1408 <term><varname>AssertPathIsDirectory=</varname></term>
1409 <term><varname>AssertPathIsSymbolicLink=</varname></term>
1410 <term><varname>AssertPathIsMountPoint=</varname></term>
1411 <term><varname>AssertPathIsReadWrite=</varname></term>
1412 <term><varname>AssertDirectoryNotEmpty=</varname></term>
1413 <term><varname>AssertFileNotEmpty=</varname></term>
1414 <term><varname>AssertFileIsExecutable=</varname></term>
1415 <term><varname>AssertUser=</varname></term>
1416 <term><varname>AssertGroup=</varname></term>
1417 <term><varname>AssertControlGroupController=</varname></term>
1418
1419 <listitem><para>Similar to the <varname>ConditionArchitecture=</varname>,
1420 <varname>ConditionVirtualization=</varname>, …, condition settings described above, these settings
1421 add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
1422 assertion setting that is not met results in failure of the start job (which means this is logged
1423 loudly). Note that hitting a configured assertion does not cause the unit to enter the
1424 <literal>failed</literal> state (or in fact result in any state change of the unit), it affects
1425 only the job queued for it. Use assertion expressions for units that cannot operate when specific
1426 requirements are not met, and when this is something the administrator or user should look
1427 into.</para>
1428 </listitem>
1429 </varlistentry>
1430 </variablelist>
1431 </refsect2>
1432 </refsect1>
1433
1434 <refsect1>
1435 <title>Mapping of unit properties to their inverses</title>
1436
1437 <para>Unit settings that create a relationship with a second unit usually show up
1438 in properties of both units, for example in <command>systemctl show</command>
1439 output. In some cases the name of the property is the same as the name of the
1440 configuration setting, but not always. This table lists the properties
1441 that are shown on two units which are connected through some dependency, and shows
1442 which property on "source" unit corresponds to which property on the "target" unit.
1443 </para>
1444
1445 <table>
1446 <title>
1447 "Forward" and "reverse" unit properties
1448 </title>
1449
1450 <tgroup cols='4'>
1451 <colspec colname='forward' />
1452 <colspec colname='reverse' />
1453 <colspec colname='fuse' />
1454 <colspec colname='ruse' />
1455 <thead>
1456 <row>
1457 <entry>"Forward" property</entry>
1458 <entry>"Reverse" property</entry>
1459 <entry namest='fuse' nameend='ruse' valign='middle'>Where used</entry>
1460 </row>
1461 </thead>
1462 <tbody>
1463 <row>
1464 <entry><varname>Before=</varname></entry>
1465 <entry><varname>After=</varname></entry>
1466 <entry morerows='1' namest='fuse' nameend='ruse' valign='middle'>[Unit] section</entry>
1467 </row>
1468 <row>
1469 <entry><varname>After=</varname></entry>
1470 <entry><varname>Before=</varname></entry>
1471 </row>
1472 <row>
1473 <entry><varname>Requires=</varname></entry>
1474 <entry><varname>RequiredBy=</varname></entry>
1475 <entry>[Unit] section</entry>
1476 <entry>[Install] section</entry>
1477 </row>
1478 <row>
1479 <entry><varname>Wants=</varname></entry>
1480 <entry><varname>WantedBy=</varname></entry>
1481 <entry>[Unit] section</entry>
1482 <entry>[Install] section</entry>
1483 </row>
1484 <row>
1485 <entry><varname>PartOf=</varname></entry>
1486 <entry><varname>ConsistsOf=</varname></entry>
1487 <entry>[Unit] section</entry>
1488 <entry>an automatic property</entry>
1489 </row>
1490 <row>
1491 <entry><varname>BindsTo=</varname></entry>
1492 <entry><varname>BoundBy=</varname></entry>
1493 <entry>[Unit] section</entry>
1494 <entry>an automatic property</entry>
1495 </row>
1496 <row>
1497 <entry><varname>Requisite=</varname></entry>
1498 <entry><varname>RequisiteOf=</varname></entry>
1499 <entry>[Unit] section</entry>
1500 <entry>an automatic property</entry>
1501 </row>
1502 <row>
1503 <entry><varname>Triggers=</varname></entry>
1504 <entry><varname>TriggeredBy=</varname></entry>
1505 <entry namest='fuse' nameend='ruse' valign='middle'>Automatic properties, see notes below</entry>
1506 </row>
1507 <row>
1508 <entry><varname>Conflicts=</varname></entry>
1509 <entry><varname>ConflictedBy=</varname></entry>
1510 <entry>[Unit] section</entry>
1511 <entry>an automatic property</entry>
1512 </row>
1513 <row>
1514 <entry><varname>PropagatesReloadTo=</varname></entry>
1515 <entry><varname>ReloadPropagatedFrom=</varname></entry>
1516 <entry morerows='1' namest='fuse' nameend='ruse' valign='middle'>[Unit] section</entry>
1517 </row>
1518 <row>
1519 <entry><varname>ReloadPropagatedFrom=</varname></entry>
1520 <entry><varname>PropagatesReloadTo=</varname></entry>
1521 </row>
1522 <row>
1523 <entry><varname>Following=</varname></entry>
1524 <entry>n/a</entry>
1525 <entry>An automatic property</entry>
1526 </row>
1527 </tbody>
1528 </tgroup>
1529 </table>
1530
1531 <para>Note: <varname>WantedBy=</varname> and <varname>RequiredBy=</varname> are
1532 used in the [Install] section to create symlinks in <filename>.wants/</filename>
1533 and <filename>.requires/</filename> directories. They cannot be used directly as a
1534 unit configuration setting.</para>
1535
1536 <para>Note: <varname>ConsistsOf=</varname>, <varname>BoundBy=</varname>,
1537 <varname>RequisiteOf=</varname>, <varname>ConflictedBy=</varname> are created
1538 implicitly along with their reverse and cannot be specified directly.</para>
1539
1540 <para>Note: <varname>Triggers=</varname> is created implicitly between a socket,
1541 path unit, or an automount unit, and the unit they activate. By default a unit
1542 with the same name is triggered, but this can be overridden using
1543 <varname>Sockets=</varname>, <varname>Service=</varname>, and <varname>Unit=</varname>
1544 settings. See
1545 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1546 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1547 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1548 and
1549 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1550 for details. <varname>TriggersBy=</varname> is created implicitly on the
1551 triggered unit.</para>
1552
1553 <para>Note: <varname>Following=</varname> is used to group device aliases and points to the
1554 "primary" device unit that systemd is using to track device state, usually corresponding to a
1555 sysfs path. It does not show up in the "target" unit.</para>
1556 </refsect1>
1557
1558 <refsect1>
1559 <title>[Install] Section Options</title>
1560
1561 <para>Unit files may include an <literal>[Install]</literal> section, which carries installation information for
1562 the unit. This section is not interpreted by
1563 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> during runtime; it is
1564 used by the <command>enable</command> and <command>disable</command> commands of the
1565 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> tool during
1566 installation of a unit.</para>
1567
1568 <variablelist class='unit-directives'>
1569 <varlistentry>
1570 <term><varname>Alias=</varname></term>
1571
1572 <listitem><para>A space-separated list of additional names this unit shall be installed under. The names listed
1573 here must have the same suffix (i.e. type) as the unit filename. This option may be specified more than once,
1574 in which case all listed names are used. At installation time, <command>systemctl enable</command> will create
1575 symlinks from these names to the unit filename. Note that not all unit types support such alias names, and this
1576 setting is not supported for them. Specifically, mount, slice, swap, and automount units do not support
1577 aliasing.</para></listitem>
1578 </varlistentry>
1579
1580 <varlistentry>
1581 <term><varname>WantedBy=</varname></term>
1582 <term><varname>RequiredBy=</varname></term>
1583
1584 <listitem><para>This option may be used more than once, or a
1585 space-separated list of unit names may be given. A symbolic
1586 link is created in the <filename>.wants/</filename> or
1587 <filename>.requires/</filename> directory of each of the
1588 listed units when this unit is installed by <command>systemctl
1589 enable</command>. This has the effect that a dependency of
1590 type <varname>Wants=</varname> or <varname>Requires=</varname>
1591 is added from the listed unit to the current unit. The primary
1592 result is that the current unit will be started when the
1593 listed unit is started. See the description of
1594 <varname>Wants=</varname> and <varname>Requires=</varname> in
1595 the [Unit] section for details.</para>
1596
1597 <para><command>WantedBy=foo.service</command> in a service
1598 <filename>bar.service</filename> is mostly equivalent to
1599 <command>Alias=foo.service.wants/bar.service</command> in the
1600 same file. In case of template units, <command>systemctl
1601 enable</command> must be called with an instance name, and
1602 this instance will be added to the
1603 <filename>.wants/</filename> or
1604 <filename>.requires/</filename> list of the listed unit. E.g.
1605 <command>WantedBy=getty.target</command> in a service
1606 <filename>getty@.service</filename> will result in
1607 <command>systemctl enable getty@tty2.service</command>
1608 creating a
1609 <filename>getty.target.wants/getty@tty2.service</filename>
1610 link to <filename>getty@.service</filename>.
1611 </para></listitem>
1612 </varlistentry>
1613
1614 <varlistentry>
1615 <term><varname>Also=</varname></term>
1616
1617 <listitem><para>Additional units to install/deinstall when
1618 this unit is installed/deinstalled. If the user requests
1619 installation/deinstallation of a unit with this option
1620 configured, <command>systemctl enable</command> and
1621 <command>systemctl disable</command> will automatically
1622 install/uninstall units listed in this option as well.</para>
1623
1624 <para>This option may be used more than once, or a
1625 space-separated list of unit names may be
1626 given.</para></listitem>
1627 </varlistentry>
1628
1629 <varlistentry>
1630 <term><varname>DefaultInstance=</varname></term>
1631
1632 <listitem><para>In template unit files, this specifies for
1633 which instance the unit shall be enabled if the template is
1634 enabled without any explicitly set instance. This option has
1635 no effect in non-template unit files. The specified string
1636 must be usable as instance identifier.</para></listitem>
1637 </varlistentry>
1638 </variablelist>
1639
1640 <para>The following specifiers are interpreted in the Install
1641 section: %n, %N, %p, %i, %j, %g, %G, %U, %u, %m, %H, %b, %v. For their
1642 meaning see the next section.
1643 </para>
1644 </refsect1>
1645
1646 <refsect1>
1647 <title>Specifiers</title>
1648
1649 <para>Many settings resolve specifiers which may be used to write
1650 generic unit files referring to runtime or unit parameters that
1651 are replaced when the unit files are loaded. Specifiers must be known
1652 and resolvable for the setting to be valid. The following
1653 specifiers are understood:</para>
1654
1655 <table>
1656 <title>Specifiers available in unit files</title>
1657 <tgroup cols='3' align='left' colsep='1' rowsep='1'>
1658 <colspec colname="spec" />
1659 <colspec colname="mean" />
1660 <colspec colname="detail" />
1661 <thead>
1662 <row>
1663 <entry>Specifier</entry>
1664 <entry>Meaning</entry>
1665 <entry>Details</entry>
1666 </row>
1667 </thead>
1668 <tbody>
1669 <row>
1670 <entry><literal>%b</literal></entry>
1671 <entry>Boot ID</entry>
1672 <entry>The boot ID of the running system, formatted as string. See <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for more information.</entry>
1673 </row>
1674 <row>
1675 <entry><literal>%C</literal></entry>
1676 <entry>Cache directory root</entry>
1677 <entry>This is either <filename>/var/cache</filename> (for the system manager) or the path <literal>$XDG_CACHE_HOME</literal> resolves to (for user managers).</entry>
1678 </row>
1679 <row>
1680 <entry><literal>%E</literal></entry>
1681 <entry>Configuration directory root</entry>
1682 <entry>This is either <filename>/etc</filename> (for the system manager) or the path <literal>$XDG_CONFIG_HOME</literal> resolves to (for user managers).</entry>
1683 </row>
1684 <row>
1685 <entry><literal>%f</literal></entry>
1686 <entry>Unescaped filename</entry>
1687 <entry>This is either the unescaped instance name (if applicable) with <filename>/</filename> prepended (if applicable), or the unescaped prefix name prepended with <filename>/</filename>. This implements unescaping according to the rules for escaping absolute file system paths discussed above.</entry>
1688 </row>
1689 <row>
1690 <entry><literal>%h</literal></entry>
1691 <entry>User home directory</entry>
1692 <entry>This is the home directory of the <emphasis>user running the service manager instance</emphasis>. In case of the system manager this resolves to <literal>/root</literal>.
1693
1694 Note that this setting is <emphasis>not</emphasis> influenced by the <varname>User=</varname> setting configurable in the [Service] section of the service unit.</entry>
1695 </row>
1696 <row>
1697 <entry><literal>%H</literal></entry>
1698 <entry>Host name</entry>
1699 <entry>The hostname of the running system at the point in time the unit configuration is loaded.</entry>
1700 </row>
1701 <row>
1702 <entry><literal>%i</literal></entry>
1703 <entry>Instance name</entry>
1704 <entry>For instantiated units this is the string between the first <literal>@</literal> character and the type suffix. Empty for non-instantiated units.</entry>
1705 </row>
1706 <row>
1707 <entry><literal>%I</literal></entry>
1708 <entry>Unescaped instance name</entry>
1709 <entry>Same as <literal>%i</literal>, but with escaping undone.</entry>
1710 </row>
1711 <row>
1712 <entry><literal>%j</literal></entry>
1713 <entry>Final component of the prefix</entry>
1714 <entry>This is the string between the last <literal>-</literal> and the end of the prefix name. If there is no <literal>-</literal>, this is the same as <literal>%p</literal>.</entry>
1715 </row>
1716 <row>
1717 <entry><literal>%J</literal></entry>
1718 <entry>Unescaped final component of the prefix</entry>
1719 <entry>Same as <literal>%j</literal>, but with escaping undone.</entry>
1720 </row>
1721 <row>
1722 <entry><literal>%L</literal></entry>
1723 <entry>Log directory root</entry>
1724 <entry>This is either <filename>/var/log</filename> (for the system manager) or the path <literal>$XDG_CONFIG_HOME</literal> resolves to with <filename noindex='true'>/log</filename> appended (for user managers).</entry>
1725 </row>
1726 <row>
1727 <entry><literal>%m</literal></entry>
1728 <entry>Machine ID</entry>
1729 <entry>The machine ID of the running system, formatted as string. See <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry>
1730 </row>
1731 <row>
1732 <entry><literal>%n</literal></entry>
1733 <entry>Full unit name</entry>
1734 <entry></entry>
1735 </row>
1736 <row>
1737 <entry><literal>%N</literal></entry>
1738 <entry>Full unit name</entry>
1739 <entry>Same as <literal>%n</literal>, but with the type suffix removed.</entry>
1740 </row>
1741 <row>
1742 <entry><literal>%p</literal></entry>
1743 <entry>Prefix name</entry>
1744 <entry>For instantiated units, this refers to the string before the first <literal>@</literal> character of the unit name. For non-instantiated units, same as <literal>%N</literal>.</entry>
1745 </row>
1746 <row>
1747 <entry><literal>%P</literal></entry>
1748 <entry>Unescaped prefix name</entry>
1749 <entry>Same as <literal>%p</literal>, but with escaping undone.</entry>
1750 </row>
1751 <row>
1752 <entry><literal>%s</literal></entry>
1753 <entry>User shell</entry>
1754 <entry>This is the shell of the user running the service manager instance. In case of the system manager this resolves to <literal>/bin/sh</literal>.</entry>
1755 </row>
1756 <row>
1757 <entry><literal>%S</literal></entry>
1758 <entry>State directory root</entry>
1759 <entry>This is either <filename>/var/lib</filename> (for the system manager) or the path <literal>$XDG_CONFIG_HOME</literal> resolves to (for user managers).</entry>
1760 </row>
1761 <row>
1762 <entry><literal>%t</literal></entry>
1763 <entry>Runtime directory root</entry>
1764 <entry>This is either <filename>/run</filename> (for the system manager) or the path <literal>$XDG_RUNTIME_DIR</literal> resolves to (for user managers).</entry>
1765 </row>
1766 <row>
1767 <entry><literal>%T</literal></entry>
1768 <entry>Directory for temporary files</entry>
1769 <entry>This is either <filename>/tmp</filename> or the path <literal>$TMPDIR</literal>, <literal>$TEMP</literal> or <literal>$TMP</literal> are set to.</entry>
1770 </row>
1771 <row>
1772 <entry><literal>%g</literal></entry>
1773 <entry>User group</entry>
1774 <entry>This is the name of the group running the service manager instance. In case of the system manager this resolves to <literal>root</literal>.</entry>
1775 </row>
1776 <row>
1777 <entry><literal>%G</literal></entry>
1778 <entry>User GID</entry>
1779 <entry>This is the numeric GID of the user running the service manager instance. In case of the system manager this resolves to <literal>0</literal>.</entry>
1780 </row>
1781 <row>
1782 <entry><literal>%u</literal></entry>
1783 <entry>User name</entry>
1784 <entry>This is the name of the <emphasis>user running the service manager instance</emphasis>. In case of the system manager this resolves to <literal>root</literal>.
1785
1786 Note that this setting is <emphasis>not</emphasis> influenced by the <varname>User=</varname> setting configurable in the [Service] section of the service unit.</entry>
1787 </row>
1788 <row>
1789 <entry><literal>%U</literal></entry>
1790 <entry>User UID</entry>
1791 <entry>This is the numeric UID of the <emphasis>user running the service manager instance</emphasis>. In case of the system manager this resolves to <literal>0</literal>.
1792
1793 Note that this setting is <emphasis>not</emphasis> influenced by the <varname>User=</varname> setting configurable in the [Service] section of the service unit.</entry>
1794 </row>
1795 <row>
1796 <entry><literal>%v</literal></entry>
1797 <entry>Kernel release</entry>
1798 <entry>Identical to <command>uname -r</command> output</entry>
1799 </row>
1800 <row>
1801 <entry><literal>%V</literal></entry>
1802 <entry>Directory for larger and persistent temporary files</entry>
1803 <entry>This is either <filename>/var/tmp</filename> or the path <literal>$TMPDIR</literal>, <literal>$TEMP</literal> or <literal>$TMP</literal> are set to.</entry>
1804 </row>
1805 <row>
1806 <entry><literal>%%</literal></entry>
1807 <entry>Single percent sign</entry>
1808 <entry>Use <literal>%%</literal> in place of <literal>%</literal> to specify a single percent sign.</entry>
1809 </row>
1810 </tbody>
1811 </tgroup>
1812 </table>
1813 </refsect1>
1814
1815 <refsect1>
1816 <title>Examples</title>
1817
1818 <example>
1819 <title>Allowing units to be enabled</title>
1820
1821 <para>The following snippet (highlighted) allows a unit (e.g.
1822 <filename>foo.service</filename>) to be enabled via
1823 <command>systemctl enable</command>:</para>
1824
1825 <programlisting>[Unit]
1826 Description=Foo
1827
1828 [Service]
1829 ExecStart=/usr/sbin/foo-daemon
1830
1831 <emphasis>[Install]</emphasis>
1832 <emphasis>WantedBy=multi-user.target</emphasis></programlisting>
1833
1834 <para>After running <command>systemctl enable</command>, a
1835 symlink
1836 <filename>/etc/systemd/system/multi-user.target.wants/foo.service</filename>
1837 linking to the actual unit will be created. It tells systemd to
1838 pull in the unit when starting
1839 <filename>multi-user.target</filename>. The inverse
1840 <command>systemctl disable</command> will remove that symlink
1841 again.</para>
1842 </example>
1843
1844 <example>
1845 <title>Overriding vendor settings</title>
1846
1847 <para>There are two methods of overriding vendor settings in
1848 unit files: copying the unit file from
1849 <filename>/usr/lib/systemd/system</filename> to
1850 <filename>/etc/systemd/system</filename> and modifying the
1851 chosen settings. Alternatively, one can create a directory named
1852 <filename><replaceable>unit</replaceable>.d/</filename> within
1853 <filename>/etc/systemd/system</filename> and place a drop-in
1854 file <filename><replaceable>name</replaceable>.conf</filename>
1855 there that only changes the specific settings one is interested
1856 in. Note that multiple such drop-in files are read if
1857 present, processed in lexicographic order of their filename.</para>
1858
1859 <para>The advantage of the first method is that one easily
1860 overrides the complete unit, the vendor unit is not parsed at
1861 all anymore. It has the disadvantage that improvements to the
1862 unit file by the vendor are not automatically incorporated on
1863 updates.</para>
1864
1865 <para>The advantage of the second method is that one only
1866 overrides the settings one specifically wants, where updates to
1867 the unit by the vendor automatically apply. This has the
1868 disadvantage that some future updates by the vendor might be
1869 incompatible with the local changes.</para>
1870
1871 <para>This also applies for user instances of systemd, but with
1872 different locations for the unit files. See the section on unit
1873 load paths for further details.</para>
1874
1875 <para>Suppose there is a vendor-supplied unit
1876 <filename>/usr/lib/systemd/system/httpd.service</filename> with
1877 the following contents:</para>
1878
1879 <programlisting>[Unit]
1880 Description=Some HTTP server
1881 After=remote-fs.target sqldb.service
1882 Requires=sqldb.service
1883 AssertPathExists=/srv/webserver
1884
1885 [Service]
1886 Type=notify
1887 ExecStart=/usr/sbin/some-fancy-httpd-server
1888 Nice=5
1889
1890 [Install]
1891 WantedBy=multi-user.target</programlisting>
1892
1893 <para>Now one wants to change some settings as an administrator:
1894 firstly, in the local setup, <filename>/srv/webserver</filename>
1895 might not exist, because the HTTP server is configured to use
1896 <filename>/srv/www</filename> instead. Secondly, the local
1897 configuration makes the HTTP server also depend on a memory
1898 cache service, <filename>memcached.service</filename>, that
1899 should be pulled in (<varname>Requires=</varname>) and also be
1900 ordered appropriately (<varname>After=</varname>). Thirdly, in
1901 order to harden the service a bit more, the administrator would
1902 like to set the <varname>PrivateTmp=</varname> setting (see
1903 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1904 for details). And lastly, the administrator would like to reset
1905 the niceness of the service to its default value of 0.</para>
1906
1907 <para>The first possibility is to copy the unit file to
1908 <filename>/etc/systemd/system/httpd.service</filename> and
1909 change the chosen settings:</para>
1910
1911 <programlisting>[Unit]
1912 Description=Some HTTP server
1913 After=remote-fs.target sqldb.service <emphasis>memcached.service</emphasis>
1914 Requires=sqldb.service <emphasis>memcached.service</emphasis>
1915 AssertPathExists=<emphasis>/srv/www</emphasis>
1916
1917 [Service]
1918 Type=notify
1919 ExecStart=/usr/sbin/some-fancy-httpd-server
1920 <emphasis>Nice=0</emphasis>
1921 <emphasis>PrivateTmp=yes</emphasis>
1922
1923 [Install]
1924 WantedBy=multi-user.target</programlisting>
1925
1926 <para>Alternatively, the administrator could create a drop-in
1927 file
1928 <filename>/etc/systemd/system/httpd.service.d/local.conf</filename>
1929 with the following contents:</para>
1930
1931 <programlisting>[Unit]
1932 After=memcached.service
1933 Requires=memcached.service
1934 # Reset all assertions and then re-add the condition we want
1935 AssertPathExists=
1936 AssertPathExists=/srv/www
1937
1938 [Service]
1939 Nice=0
1940 PrivateTmp=yes</programlisting>
1941
1942 <para>Note that for drop-in files, if one wants to remove
1943 entries from a setting that is parsed as a list (and is not a
1944 dependency), such as <varname>AssertPathExists=</varname> (or
1945 e.g. <varname>ExecStart=</varname> in service units), one needs
1946 to first clear the list before re-adding all entries except the
1947 one that is to be removed. Dependencies (<varname>After=</varname>, etc.)
1948 cannot be reset to an empty list, so dependencies can only be
1949 added in drop-ins. If you want to remove dependencies, you have
1950 to override the entire unit.</para>
1951
1952 </example>
1953 </refsect1>
1954
1955 <refsect1>
1956 <title>See Also</title>
1957 <para>
1958 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1959 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1960 <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1961 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1962 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1963 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1964 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1965 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1966 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1967 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1968 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1969 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1970 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1971 <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1972 <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1973 <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1974 <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1975 <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1976 <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1977 <citerefentry project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1978 </para>
1979 </refsect1>
1980
1981 </refentry>