1 <?xml version='1.0'?> <!--*-nxml-*-->
2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
4 <!ENTITY % entities SYSTEM "custom-entities.ent" >
9 This file is part of systemd.
11 Copyright 2010 Lennart Poettering
13 systemd is free software; you can redistribute it and/or modify it
14 under the terms of the GNU Lesser General Public License as published by
15 the Free Software Foundation; either version 2.1 of the License, or
16 (at your option) any later version.
18 systemd is distributed in the hope that it will be useful, but
19 WITHOUT ANY WARRANTY; without even the implied warranty of
20 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
21 Lesser General Public License for more details.
23 You should have received a copy of the GNU Lesser General Public License
24 along with systemd; If not, see <http://www.gnu.org/licenses/>.
27 <refentry id="systemd.unit">
30 <title>systemd.unit</title>
31 <productname>systemd</productname>
35 <contrib>Developer</contrib>
36 <firstname>Lennart</firstname>
37 <surname>Poettering</surname>
38 <email>lennart@poettering.net</email>
44 <refentrytitle>systemd.unit</refentrytitle>
45 <manvolnum>5</manvolnum>
49 <refname>systemd.unit</refname>
50 <refpurpose>Unit configuration</refpurpose>
54 <para><filename><replaceable>service</replaceable>.service</filename>,
55 <filename><replaceable>socket</replaceable>.socket</filename>,
56 <filename><replaceable>device</replaceable>.device</filename>,
57 <filename><replaceable>mount</replaceable>.mount</filename>,
58 <filename><replaceable>automount</replaceable>.automount</filename>,
59 <filename><replaceable>swap</replaceable>.swap</filename>,
60 <filename><replaceable>target</replaceable>.target</filename>,
61 <filename><replaceable>path</replaceable>.path</filename>,
62 <filename><replaceable>timer</replaceable>.timer</filename>,
63 <filename><replaceable>snapshot</replaceable>.snapshot</filename>,
64 <filename><replaceable>slice</replaceable>.slice</filename>,
65 <filename><replaceable>scope</replaceable>.scope</filename></para>
67 <para><literallayout><filename>/etc/systemd/system/*</filename>
68 <filename>/run/systemd/system/*</filename>
69 <filename>/usr/lib/systemd/system/*</filename>
70 <filename>...</filename>
71 </literallayout></para>
73 <para><literallayout><filename>$XDG_CONFIG_HOME/systemd/user/*</filename>
74 <filename>$HOME/.config/systemd/user/*</filename>
75 <filename>/etc/systemd/user/*</filename>
76 <filename>/run/systemd/user/*</filename>
77 <filename>$XDG_DATA_HOME/systemd/user/*</filename>
78 <filename>$HOME/.local/share/systemd/user/*</filename>
79 <filename>/usr/lib/systemd/user/*</filename>
80 <filename>...</filename>
81 </literallayout></para>
85 <title>Description</title>
87 <para>A unit configuration file encodes information
88 about a service, a socket, a device, a mount point, an
89 automount point, a swap file or partition, a start-up
90 target, a watched file system path, a timer controlled
92 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
93 a temporary system state snapshot, a resource
94 management slice or a group of externally created
95 processes. The syntax is inspired by <ulink
96 url="http://standards.freedesktop.org/desktop-entry-spec/latest/">XDG
97 Desktop Entry Specification</ulink>
98 <filename>.desktop</filename> files, which are in turn
99 inspired by Microsoft Windows
100 <filename>.ini</filename> files.</para>
102 <para>This man page lists the common configuration
103 options of all the unit types. These options need to
104 be configured in the [Unit] or [Install]
105 sections of the unit files.</para>
107 <para>In addition to the generic [Unit] and [Install]
108 sections described here, each unit may have a
109 type-specific section, e.g. [Service] for a service
110 unit. See the respective man pages for more
112 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
113 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
114 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
115 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
116 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
117 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
118 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
119 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
120 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
121 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
122 <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
123 <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
126 <para>Various settings are allowed to be specified
127 more than once, in which case the interpretation
128 depends on the setting. Often, multiple settings form
129 a list, and setting to an empty value "resets", which
130 means that previous assignments are ignored. When this
131 is allowed, it is mentioned in the description of the
132 setting. Note that using multiple assignments to the
133 same value makes the unit file incompatible with
134 parsers for the XDG <filename>.desktop</filename> file
137 <para>Unit files are loaded from a set of paths
138 determined during compilation, described in the next section.
141 <para>Unit files may contain additional options on top
142 of those listed here. If systemd encounters an unknown
143 option, it will write a warning log message but
144 continue loading the unit. If an option or section name
145 is prefixed with <option>X-</option>, it is ignored
146 completely by systemd. Options within an ignored
147 section do not need the prefix. Applications may use
148 this to include additional information in the unit
151 <para>Boolean arguments used in unit files can be
152 written in various formats. For positive settings the
153 strings <option>1</option>, <option>yes</option>,
154 <option>true</option> and <option>on</option> are
155 equivalent. For negative settings, the strings
156 <option>0</option>, <option>no</option>,
157 <option>false</option> and <option>off</option> are
160 <para>Time span values encoded in unit files can be
161 written in various formats. A stand-alone number
162 specifies a time in seconds. If suffixed with a time
163 unit, the unit is honored. A concatenation of multiple
164 values with units is supported, in which case the
165 values are added up. Example: "50" refers to 50
166 seconds; "2min 200ms" refers to 2 minutes plus 200
167 milliseconds, i.e. 120200ms. The following time units
168 are understood: s, min, h, d, w, ms, us. For details
170 <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
172 <para>Empty lines and lines starting with # or ; are
173 ignored. This may be used for commenting. Lines ending
174 in a backslash are concatenated with the following
175 line while reading and the backslash is replaced by a
176 space character. This may be used to wrap long lines.</para>
178 <para>Along with a unit file
179 <filename>foo.service</filename>, the directory
180 <filename>foo.service.wants/</filename> may exist. All
181 unit files symlinked from such a directory are
182 implicitly added as dependencies of type
183 <varname>Wanted=</varname> to the unit. This is useful
184 to hook units into the start-up of other units,
185 without having to modify their unit files. For details
186 about the semantics of <varname>Wanted=</varname>, see
187 below. The preferred way to create symlinks in the
188 <filename>.wants/</filename> directory of a unit file
189 is with the <command>enable</command> command of the
190 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
191 tool which reads information from the [Install]
192 section of unit files (see below). A similar
193 functionality exists for <varname>Requires=</varname>
194 type dependencies as well, the directory suffix is
195 <filename>.requires/</filename> in this case.</para>
197 <para>Along with a unit file
198 <filename>foo.service</filename>, a directory
199 <filename>foo.service.d/</filename> may exist. All
200 files with the suffix <literal>.conf</literal> from
201 this directory will be parsed after the file itself is
202 parsed. This is useful to alter or add configuration
203 settings to a unit, without having to modify their
204 unit files. Make sure that the file that is included
205 has the appropriate section headers before any
206 directive. Note that for instanced units this logic
207 will first look for the instance
208 <literal>.d/</literal> subdirectory and read its
209 <literal>.conf</literal> files, followed by the
210 template <literal>.d/</literal> subdirectory and reads
211 its <literal>.conf</literal> files.</para>
213 <para>Note that while systemd offers a flexible
214 dependency system between units it is recommended to
215 use this functionality only sparingly and instead rely
216 on techniques such as bus-based or socket-based
217 activation which make dependencies implicit, resulting
218 in a both simpler and more flexible system.</para>
220 <para>Some unit names reflect paths existing in the
221 file system namespace. Example: a device unit
222 <filename>dev-sda.device</filename> refers to a device
223 with the device node <filename noindex='true'>/dev/sda</filename> in
224 the file system namespace. If this applies, a special
225 way to escape the path name is used, so that the
226 result is usable as part of a filename. Basically,
227 given a path, "/" is replaced by "-", and all
228 unprintable characters and the "-" are replaced by
229 C-style "\x20" escapes. The root directory "/" is
230 encoded as single dash, while otherwise the initial
231 and ending "/" is removed from all paths during
232 transformation. This escaping is reversible.</para>
234 <para>Optionally, units may be instantiated from a
235 template file at runtime. This allows creation of
236 multiple units from a single configuration file. If
237 systemd looks for a unit configuration file, it will
238 first search for the literal unit name in the
239 file system. If that yields no success and the unit
240 name contains an <literal>@</literal> character, systemd will look for a
241 unit template that shares the same name but with the
242 instance string (i.e. the part between the <literal>@</literal> character
243 and the suffix) removed. Example: if a service
244 <filename>getty@tty3.service</filename> is requested
245 and no file by that name is found, systemd will look
246 for <filename>getty@.service</filename> and
247 instantiate a service from that configuration file if
250 <para>To refer to the instance string from
251 within the configuration file you may use the special
252 <literal>%i</literal> specifier in many of the
253 configuration options. See below for details.</para>
255 <para>If a unit file is empty (i.e. has the file size
256 0) or is symlinked to <filename>/dev/null</filename>,
257 its configuration will not be loaded and it appears
258 with a load state of <literal>masked</literal>, and
259 cannot be activated. Use this as an effective way to
260 fully disable a unit, making it impossible to start it
261 even manually.</para>
263 <para>The unit file format is covered by the
265 url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
266 Stability Promise</ulink>.</para>
271 <title>Unit Load Path</title>
273 <para>Unit files are loaded from a set of paths
274 determined during compilation, described in the two
275 tables below. Unit files found in directories listed
276 earlier override files with the same name in
277 directories lower in the list.</para>
279 <para>When systemd is running in user mode
280 (<option>--user</option>) and the variable
281 <varname>$SYSTEMD_UNIT_PATH</varname> is set, this
282 contents of this variable overrides the unit load
283 path. If <varname>$SYSTEMD_UNIT_PATH</varname> ends
284 with an empty component (<literal>:</literal>), the
285 usual unit load path will be appended to the contents
286 of the variable.</para>
290 Load path when running in system mode (<option>--system</option>).
294 <colspec colname='path' />
295 <colspec colname='expl' />
299 <entry>Description</entry>
304 <entry><filename>/etc/systemd/system</filename></entry>
305 <entry>Local configuration</entry>
308 <entry><filename>/run/systemd/system</filename></entry>
309 <entry>Runtime units</entry>
312 <entry><filename>/usr/lib/systemd/system</filename></entry>
313 <entry>Units of installed packages</entry>
321 Load path when running in user mode (<option>--user</option>).
325 <colspec colname='path' />
326 <colspec colname='expl' />
330 <entry>Description</entry>
335 <entry><filename>$XDG_CONFIG_HOME/systemd/user</filename></entry>
336 <entry>User configuration (only used when $XDG_CONFIG_HOME is set)</entry>
339 <entry><filename>$HOME/.config/systemd/user</filename></entry>
340 <entry>User configuration (only used when $XDG_CONFIG_HOME is not set)</entry>
343 <entry><filename>/etc/systemd/user</filename></entry>
344 <entry>Local configuration</entry>
347 <entry><filename>/run/systemd/user</filename></entry>
348 <entry>Runtime units</entry>
351 <entry><filename>$XDG_DATA_HOME/systemd/user</filename></entry>
352 <entry>Units of packages that have been installed in the home directory (only used when $XDG_DATA_HOME is set)</entry>
355 <entry><filename>$HOME/.local/share/systemd/user</filename></entry>
356 <entry>Units of packages that have been installed in the home directory (only used when $XDG_DATA_HOME is not set)</entry>
359 <entry><filename>/usr/lib/systemd/user</filename></entry>
360 <entry>Units of packages that have been installed system-wide</entry>
366 <para>Additional units might be loaded into systemd
367 ("linked") from directories not on the unit load
368 path. See the <command>link</command> command for
369 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. Also,
370 some units are dynamically created via generators
372 url="http://www.freedesktop.org/wiki/Software/systemd/Generators/">Generators</ulink>.
377 <title>[Unit] Section Options</title>
379 <para>Unit file may include a [Unit] section, which
380 carries generic information about the unit that is not
381 dependent on the type of unit:</para>
383 <variablelist class='unit-directives'>
386 <term><varname>Description=</varname></term>
387 <listitem><para>A free-form string
388 describing the unit. This is intended
389 for use in UIs to show descriptive
390 information along with the unit
391 name. The description should contain a name
392 that means something to the end user.
393 <literal>Apache2 Web Server</literal> is a good
394 example. Bad examples are
395 <literal>high-performance light-weight HTTP
396 server</literal> (too generic) or
397 <literal>Apache2</literal> (too specific and
398 meaningless for people who do not know
399 Apache).</para></listitem>
403 <term><varname>Documentation=</varname></term>
404 <listitem><para>A space-separated list
405 of URIs referencing documentation for
407 configuration. Accepted are only URIs
409 <literal>http://</literal>,
410 <literal>https://</literal>,
411 <literal>file:</literal>,
412 <literal>info:</literal>,
413 <literal>man:</literal>. For more
414 information about the syntax of these
416 <citerefentry project='man-pages'><refentrytitle>uri</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
417 URIs should be listed in order of
418 relevance, starting with the most
419 relevant. It is a good idea to first
420 reference documentation that explains
421 what the unit's purpose is, followed
422 by how it is configured, followed by
423 any other related documentation. This
424 option may be specified more than once,
425 in which case the specified list of
426 URIs is merged. If the empty string is
427 assigned to this option, the list is
428 reset and all prior assignments will
429 have no effect.</para></listitem>
433 <term><varname>Requires=</varname></term>
435 <listitem><para>Configures requirement
436 dependencies on other units. If this
437 unit gets activated, the units listed
438 here will be activated as well. If one
439 of the other units gets deactivated or
440 its activation fails, this unit will
441 be deactivated. This option may be
442 specified more than once or multiple
443 space-separated units may be specified
444 in one option in which case
445 requirement dependencies for all
446 listed names will be created. Note
447 that requirement dependencies do not
448 influence the order in which services
449 are started or stopped. This has to be
450 configured independently with the
451 <varname>After=</varname> or
452 <varname>Before=</varname> options. If
454 <filename>foo.service</filename>
456 <filename>bar.service</filename> as
458 <varname>Requires=</varname> and no
459 ordering is configured with
460 <varname>After=</varname> or
461 <varname>Before=</varname>, then both
462 units will be started simultaneously
463 and without any delay between them if
464 <filename>foo.service</filename> is
465 activated. Often it is a better choice
466 to use <varname>Wants=</varname>
468 <varname>Requires=</varname> in order
469 to achieve a system that is more
470 robust when dealing with failing
473 <para>Note that dependencies of this
474 type may also be configured outside of
475 the unit configuration file by
476 adding a symlink to a
477 <filename>.requires/</filename> directory
478 accompanying the unit file. For
479 details see above.</para></listitem>
483 <term><varname>RequiresOverridable=</varname></term>
485 <listitem><para>Similar to
486 <varname>Requires=</varname>.
487 Dependencies listed in
488 <varname>RequiresOverridable=</varname>
489 which cannot be fulfilled or fail to
490 start are ignored if the startup was
491 explicitly requested by the user. If
492 the start-up was pulled in indirectly
493 by some dependency or automatic
494 start-up of units that is not
495 requested by the user, this dependency
496 must be fulfilled and otherwise the
497 transaction fails. Hence, this option
498 may be used to configure dependencies
499 that are normally honored unless the
500 user explicitly starts up the unit, in
501 which case whether they failed or not
502 is irrelevant.</para></listitem>
506 <term><varname>Requisite=</varname></term>
507 <term><varname>RequisiteOverridable=</varname></term>
509 <listitem><para>Similar to
510 <varname>Requires=</varname> and
511 <varname>RequiresOverridable=</varname>,
512 respectively. However, if the units
513 listed here are not started already,
514 they will not be started and the
515 transaction will fail immediately.
520 <term><varname>Wants=</varname></term>
522 <listitem><para>A weaker version of
523 <varname>Requires=</varname>. Units
524 listed in this option will be started
525 if the configuring unit is. However,
526 if the listed units fail to start
527 or cannot be added to the transaction,
528 this has no impact on the validity of
529 the transaction as a whole. This is
530 the recommended way to hook start-up
531 of one unit to the start-up of another
534 <para>Note that dependencies of this
535 type may also be configured outside of
536 the unit configuration file by adding
538 <filename>.wants/</filename> directory
539 accompanying the unit file. For
540 details, see above.</para></listitem>
544 <term><varname>BindsTo=</varname></term>
546 <listitem><para>Configures requirement
547 dependencies, very similar in style to
548 <varname>Requires=</varname>, however
549 in addition to this behavior, it also
550 declares that this unit is stopped
551 when any of the units listed suddenly
552 disappears. Units can suddenly,
553 unexpectedly disappear if a service
554 terminates on its own choice, a device
555 is unplugged or a mount point
556 unmounted without involvement of
557 systemd.</para></listitem>
561 <term><varname>PartOf=</varname></term>
563 <listitem><para>Configures dependencies
564 similar to <varname>Requires=</varname>,
565 but limited to stopping and restarting
566 of units. When systemd stops or restarts
567 the units listed here, the action is
568 propagated to this unit.
569 Note that this is a one-way dependency —
570 changes to this unit do not affect the
576 <term><varname>Conflicts=</varname></term>
578 <listitem><para>A space-separated list
579 of unit names. Configures negative
580 requirement dependencies. If a unit
581 has a <varname>Conflicts=</varname>
582 setting on another unit, starting the
583 former will stop the latter and vice
584 versa. Note that this setting is
585 independent of and orthogonal to the
586 <varname>After=</varname> and
587 <varname>Before=</varname> ordering
590 <para>If a unit A that conflicts with
591 a unit B is scheduled to be started at
592 the same time as B, the transaction
593 will either fail (in case both are
594 required part of the transaction) or
595 be modified to be fixed (in case one
596 or both jobs are not a required part
597 of the transaction). In the latter
598 case, the job that is not the required
599 will be removed, or in case both are
600 not required, the unit that conflicts
601 will be started and the unit that is
603 stopped.</para></listitem>
607 <term><varname>Before=</varname></term>
608 <term><varname>After=</varname></term>
610 <listitem><para>A space-separated list
611 of unit names. Configures ordering
612 dependencies between units. If a unit
613 <filename>foo.service</filename>
615 <option>Before=bar.service</option>
616 and both units are being started,
617 <filename>bar.service</filename>'s
618 start-up is delayed until
619 <filename>foo.service</filename> is
620 started up. Note that this setting is
621 independent of and orthogonal to the
622 requirement dependencies as configured
623 by <varname>Requires=</varname>. It is
624 a common pattern to include a unit
626 <varname>After=</varname> and
627 <varname>Requires=</varname> option, in
628 which case the unit listed will be
629 started before the unit that is
630 configured with these options. This
631 option may be specified more than
632 once, in which case ordering
633 dependencies for all listed names are
634 created. <varname>After=</varname> is
636 <varname>Before=</varname>, i.e. while
637 <varname>After=</varname> ensures that
638 the configured unit is started after
639 the listed unit finished starting up,
640 <varname>Before=</varname> ensures the
641 opposite, i.e. that the configured
642 unit is fully started up before the
643 listed unit is started. Note that when
644 two units with an ordering dependency
645 between them are shut down, the
646 inverse of the start-up order is
647 applied. i.e. if a unit is configured
648 with <varname>After=</varname> on
649 another unit, the former is stopped
650 before the latter if both are shut
651 down. If one unit with an ordering
652 dependency on another unit is shut
653 down while the latter is started up,
654 the shut down is ordered before the
655 start-up regardless of whether the
656 ordering dependency is actually of
657 type <varname>After=</varname> or
658 <varname>Before=</varname>. If two
659 units have no ordering dependencies
660 between them, they are shut down or
661 started up simultaneously, and no
663 place. </para></listitem>
667 <term><varname>OnFailure=</varname></term>
669 <listitem><para>A space-separated list
670 of one or more units that are
671 activated when this unit enters the
672 <literal>failed</literal>
673 state.</para></listitem>
677 <term><varname>PropagatesReloadTo=</varname></term>
678 <term><varname>ReloadPropagatedFrom=</varname></term>
680 <listitem><para>A space-separated list
681 of one or more units where reload
682 requests on this unit will be
683 propagated to, or reload requests on
684 the other unit will be propagated to
685 this unit, respectively. Issuing a
686 reload request on a unit will
687 automatically also enqueue a reload
688 request on all units that the reload
689 request shall be propagated to via
690 these two settings.</para></listitem>
694 <term><varname>JoinsNamespaceOf=</varname></term>
696 <listitem><para>For units that start
697 processes (such as service units),
698 lists one or more other units whose
699 network and/or temporary file
700 namespace to join. This only applies
701 to unit types which support the
702 <varname>PrivateNetwork=</varname> and
703 <varname>PrivateTmp=</varname>
705 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
706 for details). If a unit that has this
707 setting set is started, its processes
709 <filename>/tmp</filename>,
710 <filename>/tmp/var</filename> and
711 network namespace as one listed unit
712 that is started. If multiple listed
713 units are already started, it is not
714 defined which namespace is
715 joined. Note that this setting only
717 <varname>PrivateNetwork=</varname>
718 and/or <varname>PrivateTmp=</varname>
719 is enabled for both the unit that
720 joins the namespace and the unit whose
721 namespace is joined.</para></listitem>
725 <term><varname>RequiresMountsFor=</varname></term>
727 <listitem><para>Takes a
728 space-separated list of absolute
729 paths. Automatically adds dependencies
730 of type <varname>Requires=</varname>
731 and <varname>After=</varname> for all
732 mount units required to access the
733 specified path.</para>
735 <para>Mount points marked with
736 <option>noauto</option> are not
737 mounted automatically and will be
738 ignored for the purposes of this
739 option. If such a mount should be a
740 requirement for this unit,
741 direct dependencies on the mount
743 (<varname>Requires=</varname> and
744 <varname>After=</varname> or
745 some other combination).
750 <term><varname>OnFailureJobMode=</varname></term>
752 <listitem><para>Takes a value of
753 <literal>fail</literal>,
754 <literal>replace</literal>,
755 <literal>replace-irreversibly</literal>,
756 <literal>isolate</literal>,
757 <literal>flush</literal>,
758 <literal>ignore-dependencies</literal>
760 <literal>ignore-requirements</literal>. Defaults
762 <literal>replace</literal>. Specifies
763 how the units listed in
764 <varname>OnFailure=</varname> will be
766 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
767 <option>--job-mode=</option> option
768 for details on the possible values. If
770 <literal>isolate</literal>, only a
771 single unit may be listed in
772 <varname>OnFailure=</varname>..</para></listitem>
776 <term><varname>IgnoreOnIsolate=</varname></term>
778 <listitem><para>Takes a boolean
779 argument. If <option>true</option>,
780 this unit will not be stopped when
781 isolating another unit. Defaults to
782 <option>false</option>.</para></listitem>
786 <term><varname>IgnoreOnSnapshot=</varname></term>
788 <listitem><para>Takes a boolean
789 argument. If <option>true</option>,
790 this unit will not be included in
791 snapshots. Defaults to
792 <option>true</option> for device and
793 snapshot units, <option>false</option>
794 for the others.</para></listitem>
798 <term><varname>StopWhenUnneeded=</varname></term>
800 <listitem><para>Takes a boolean
801 argument. If <option>true</option>,
802 this unit will be stopped when it is
803 no longer used. Note that in order to
804 minimize the work to be executed,
805 systemd will not stop units by default
806 unless they are conflicting with other
807 units, or the user explicitly
808 requested their shut down. If this
809 option is set, a unit will be
810 automatically cleaned up if no other
811 active unit requires it. Defaults to
812 <option>false</option>.</para></listitem>
816 <term><varname>RefuseManualStart=</varname></term>
817 <term><varname>RefuseManualStop=</varname></term>
819 <listitem><para>Takes a boolean
820 argument. If <option>true</option>,
821 this unit can only be activated
822 or deactivated indirectly. In
823 this case, explicit start-up
824 or termination requested by the
825 user is denied, however if it is
826 started or stopped as a
827 dependency of another unit, start-up
828 or termination will succeed. This
829 is mostly a safety feature to ensure
830 that the user does not accidentally
831 activate units that are not intended
832 to be activated explicitly, and not
833 accidentally deactivate units that are
834 not intended to be deactivated.
835 These options default to
836 <option>false</option>.</para></listitem>
840 <term><varname>AllowIsolate=</varname></term>
842 <listitem><para>Takes a boolean
843 argument. If <option>true</option>,
844 this unit may be used with the
845 <command>systemctl isolate</command>
846 command. Otherwise, this will be
847 refused. It probably is a good idea to
848 leave this disabled except for target
849 units that shall be used similar to
850 runlevels in SysV init systems, just
851 as a precaution to avoid unusable
852 system states. This option defaults to
853 <option>false</option>.</para></listitem>
857 <term><varname>DefaultDependencies=</varname></term>
859 <listitem><para>Takes a boolean
860 argument. If <option>true</option>,
861 (the default), a few default
862 dependencies will implicitly be
863 created for the unit. The actual
864 dependencies created depend on the
865 unit type. For example, for service
866 units, these dependencies ensure that
867 the service is started only after
868 basic system initialization is
869 completed and is properly terminated on
870 system shutdown. See the respective
871 man pages for details. Generally, only
872 services involved with early boot or
873 late shutdown should set this option
874 to <option>false</option>. It is
875 highly recommended to leave this
876 option enabled for the majority of
877 common units. If set to
878 <option>false</option>, this option
879 does not disable all implicit
880 dependencies, just non-essential
881 ones.</para></listitem>
885 <term><varname>JobTimeoutSec=</varname></term>
887 <listitem><para>When clients are
888 waiting for a job of this unit to
889 complete, time out after the specified
890 time. If this time limit is reached,
891 the job will be cancelled, the unit
892 however will not change state or even
893 enter the <literal>failed</literal>
894 mode. This value defaults to 0 (job
895 timeouts disabled), except for device
896 units. NB: this timeout is independent
897 from any unit-specific timeout (for
898 example, the timeout set with
899 <varname>Timeout=</varname> in service
900 units) as the job timeout has no
901 effect on the unit itself, only on the
902 job that might be pending for it. Or
903 in other words: unit-specific timeouts
904 are useful to abort unit state
905 changes, and revert them. The job
906 timeout set with this option however
907 is useful to abort only the job
908 waiting for the unit state to
909 change.</para></listitem>
913 <term><varname>ConditionArchitecture=</varname></term>
914 <term><varname>ConditionVirtualization=</varname></term>
915 <term><varname>ConditionHost=</varname></term>
916 <term><varname>ConditionKernelCommandLine=</varname></term>
917 <term><varname>ConditionSecurity=</varname></term>
918 <term><varname>ConditionCapability=</varname></term>
919 <term><varname>ConditionACPower=</varname></term>
920 <term><varname>ConditionNeedsUpdate=</varname></term>
921 <term><varname>ConditionFirstBoot=</varname></term>
922 <term><varname>ConditionPathExists=</varname></term>
923 <term><varname>ConditionPathExistsGlob=</varname></term>
924 <term><varname>ConditionPathIsDirectory=</varname></term>
925 <term><varname>ConditionPathIsSymbolicLink=</varname></term>
926 <term><varname>ConditionPathIsMountPoint=</varname></term>
927 <term><varname>ConditionPathIsReadWrite=</varname></term>
928 <term><varname>ConditionDirectoryNotEmpty=</varname></term>
929 <term><varname>ConditionFileNotEmpty=</varname></term>
930 <term><varname>ConditionFileIsExecutable=</varname></term>
931 <term><varname>ConditionNull=</varname></term>
933 <listitem><para>Before starting a unit
934 verify that the specified condition is
935 true. If it is not true, the starting
936 of the unit will be skipped, however
937 all ordering dependencies of it are
938 still respected. A failing condition
939 will not result in the unit being
940 moved into a failure state. The
941 condition is checked at the time the
942 queued start job is to be
945 <para><varname>ConditionArchitecture=</varname>
946 may be used to check whether the
947 system is running on a specific
948 architecture. Takes one of
949 <varname>x86</varname>,
950 <varname>x86-64</varname>,
951 <varname>ppc</varname>,
952 <varname>ppc-le</varname>,
953 <varname>ppc64</varname>,
954 <varname>ppc64-le</varname>,
955 <varname>ia64</varname>,
956 <varname>parisc</varname>,
957 <varname>parisc64</varname>,
958 <varname>s390</varname>,
959 <varname>s390x</varname>,
960 <varname>sparc</varname>,
961 <varname>sparc64</varname>,
962 <varname>mips</varname>,
963 <varname>mips-le</varname>,
964 <varname>mips64</varname>,
965 <varname>mips64-le</varname>,
966 <varname>alpha</varname>,
967 <varname>arm</varname>,
968 <varname>arm-be</varname>,
969 <varname>arm64</varname>,
970 <varname>arm64-be</varname>,
971 <varname>sh</varname>,
972 <varname>sh64</varname>,
973 <varname>m86k</varname>,
974 <varname>tilegx</varname>,
975 <varname>cris</varname> to test
976 against a specific architecture. The
977 architecture is determined from the
978 information returned by
979 <citerefentry><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
980 and is thus subject to
981 <citerefentry><refentrytitle>personality</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Note
982 that a <varname>Personality=</varname>
983 setting in the same unit file has no
984 effect on this condition. A special
986 <varname>native</varname> is mapped to
987 the architecture the system manager
988 itself is compiled for. The test may
989 be negated by prepending an
990 exclamation mark.</para>
992 <para><varname>ConditionVirtualization=</varname>
993 may be used to check whether the
994 system is executed in a virtualized
995 environment and optionally test
996 whether it is a specific
997 implementation. Takes either boolean
998 value to check if being executed in
999 any virtualized environment, or one of
1000 <varname>vm</varname> and
1001 <varname>container</varname> to test
1002 against a generic type of
1003 virtualization solution, or one of
1004 <varname>qemu</varname>,
1005 <varname>kvm</varname>,
1006 <varname>zvm</varname>,
1007 <varname>vmware</varname>,
1008 <varname>microsoft</varname>,
1009 <varname>oracle</varname>,
1010 <varname>xen</varname>,
1011 <varname>bochs</varname>,
1012 <varname>uml</varname>,
1013 <varname>openvz</varname>,
1014 <varname>lxc</varname>,
1015 <varname>lxc-libvirt</varname>,
1016 <varname>systemd-nspawn</varname> to
1017 test against a specific
1018 implementation. If multiple
1019 virtualization technologies are nested,
1020 only the innermost is considered. The
1021 test may be negated by prepending an
1022 exclamation mark.</para>
1024 <para><varname>ConditionHost=</varname>
1025 may be used to match against the
1026 hostname or machine ID of the
1027 host. This either takes a hostname
1028 string (optionally with shell style
1029 globs) which is tested against the
1030 locally set hostname as returned by
1031 <citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
1032 or a machine ID formatted as string
1034 <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
1035 The test may be negated by prepending
1036 an exclamation mark.</para>
1038 <para><varname>ConditionKernelCommandLine=</varname>
1039 may be used to check whether a
1040 specific kernel command line option is
1041 set (or if prefixed with the
1042 exclamation mark unset). The argument
1043 must either be a single word, or an
1044 assignment (i.e. two words, separated
1045 <literal>=</literal>). In the former
1046 case the kernel command line is
1047 searched for the word appearing as is,
1048 or as left hand side of an
1049 assignment. In the latter case, the
1050 exact assignment is looked for with
1051 right and left hand side
1054 <para><varname>ConditionSecurity=</varname>
1055 may be used to check whether the given
1056 security module is enabled on the
1057 system. Currently the recognized values
1058 values are <varname>selinux</varname>,
1059 <varname>apparmor</varname>,
1060 <varname>ima</varname> and
1061 <varname>smack</varname>.
1062 The test may be negated by prepending
1066 <para><varname>ConditionCapability=</varname>
1067 may be used to check whether the given
1068 capability exists in the capability
1069 bounding set of the service manager
1070 (i.e. this does not check whether
1071 capability is actually available in
1072 the permitted or effective sets, see
1073 <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1074 for details). Pass a capability name
1075 such as <literal>CAP_MKNOD</literal>,
1076 possibly prefixed with an exclamation
1077 mark to negate the check.</para>
1079 <para><varname>ConditionACPower=</varname>
1080 may be used to check whether the
1081 system has AC power, or is exclusively
1082 battery powered at the time of
1083 activation of the unit. This takes a
1084 boolean argument. If set to
1085 <varname>true</varname>, the condition
1086 will hold only if at least one AC
1087 connector of the system is connected
1088 to a power source, or if no AC
1089 connectors are known. Conversely, if
1090 set to <varname>false</varname>, the
1091 condition will hold only if there is
1092 at least one AC connector known and
1093 all AC connectors are disconnected
1094 from a power source.</para>
1096 <para><varname>ConditionNeedsUpdate=</varname>
1097 takes one of <filename>/var</filename>
1098 or <filename>/etc</filename> as
1099 argument, possibly prefixed with a
1100 <literal>!</literal> (for inverting
1101 the condition). This condition may be
1102 used to conditionalize units on
1103 whether the specified directory
1104 requires an update because
1105 <filename>/usr</filename>'s
1106 modification time is newer than the
1108 <filename>.updated</filename> in the
1109 specified directory. This is useful to
1110 implement offline updates of the
1111 vendor operating system resources in
1112 <filename>/usr</filename> that require
1113 updating of <filename>/etc</filename>
1114 or <filename>/var</filename> on the
1115 next following boot. Units making use
1116 of this condition should order
1118 <citerefentry><refentrytitle>systemd-update-done.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1119 to make sure they run before the stamp
1120 files's modification time gets reset
1121 indicating a completed update.</para>
1123 <para><varname>ConditionFirstBoot=</varname>
1124 takes a boolean argument. This
1125 condition may be used to
1126 conditionalize units on whether the
1127 system is booting up with an
1128 unpopulated <filename>/etc</filename>
1129 directory. This may be used to
1130 populate <filename>/etc</filename> on
1131 the first boot after factory reset, or
1132 when a new system instances boots up
1133 for the first time.</para>
1136 <varname>ConditionPathExists=</varname>
1137 a file existence condition is
1138 checked before a unit is started. If
1139 the specified absolute path name does
1140 not exist, the condition will
1141 fail. If the absolute path name passed
1143 <varname>ConditionPathExists=</varname>
1144 is prefixed with an exclamation mark
1145 (<literal>!</literal>), the test is negated, and the unit
1146 is only started if the path does not
1149 <para><varname>ConditionPathExistsGlob=</varname>
1151 <varname>ConditionPathExists=</varname>,
1152 but checks for the existence of at
1153 least one file or directory matching
1154 the specified globbing pattern.</para>
1156 <para><varname>ConditionPathIsDirectory=</varname>
1158 <varname>ConditionPathExists=</varname>
1159 but verifies whether a certain path
1163 <para><varname>ConditionPathIsSymbolicLink=</varname>
1165 <varname>ConditionPathExists=</varname>
1166 but verifies whether a certain path
1167 exists and is a symbolic
1170 <para><varname>ConditionPathIsMountPoint=</varname>
1172 <varname>ConditionPathExists=</varname>
1173 but verifies whether a certain path
1174 exists and is a mount
1177 <para><varname>ConditionPathIsReadWrite=</varname>
1179 <varname>ConditionPathExists=</varname>
1180 but verifies whether the underlying
1181 file system is readable and writable
1185 <para><varname>ConditionDirectoryNotEmpty=</varname>
1187 <varname>ConditionPathExists=</varname>
1188 but verifies whether a certain path
1189 exists and is a non-empty
1192 <para><varname>ConditionFileNotEmpty=</varname>
1194 <varname>ConditionPathExists=</varname>
1195 but verifies whether a certain path
1196 exists and refers to a regular file
1197 with a non-zero size.</para>
1199 <para><varname>ConditionFileIsExecutable=</varname>
1201 <varname>ConditionPathExists=</varname>
1202 but verifies whether a certain path
1203 exists, is a regular file and marked
1207 <varname>ConditionNull=</varname> may
1208 be used to add a constant condition
1209 check value to the unit. It takes a
1210 boolean argument. If set to
1211 <varname>false</varname>, the condition
1212 will always fail, otherwise
1215 <para>If multiple conditions are
1216 specified, the unit will be executed if
1217 all of them apply (i.e. a logical AND
1218 is applied). Condition checks can be
1219 prefixed with a pipe symbol (|) in
1220 which case a condition becomes a
1221 triggering condition. If at least one
1222 triggering condition is defined for a
1223 unit, then the unit will be executed if
1224 at least one of the triggering
1225 conditions apply and all of the
1226 non-triggering conditions. If you
1227 prefix an argument with the pipe
1228 symbol and an exclamation mark, the
1229 pipe symbol must be passed first, the
1230 exclamation second. Except for
1231 <varname>ConditionPathIsSymbolicLink=</varname>,
1232 all path checks follow symlinks. If
1233 any of these options is assigned the
1234 empty string, the list of conditions is
1235 reset completely, all previous
1236 condition settings (of any kind) will
1237 have no effect.</para></listitem>
1241 <term><varname>SourcePath=</varname></term>
1242 <listitem><para>A path to a
1243 configuration file this unit has been
1244 generated from. This is primarily
1245 useful for implementation of generator
1246 tools that convert configuration from
1247 an external configuration file format
1248 into native unit files. This
1249 functionality should not be used in
1250 normal units.</para></listitem>
1257 <title>[Install] Section Options</title>
1259 <para>Unit file may include a [Install] section, which
1260 carries installation information for the unit. This
1261 section is not interpreted by
1262 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1263 during runtime. It is used exclusively by the
1264 <command>enable</command> and
1265 <command>disable</command> commands of the
1266 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1267 tool during installation of a unit:</para>
1269 <variablelist class='unit-directives'>
1271 <term><varname>Alias=</varname></term>
1273 <listitem><para>A space-seperated list
1274 of additional names this unit shall be
1275 installed under. The names listed here
1276 must have the same suffix (i.e. type)
1277 as the unit file name. This option may
1278 be specified more than once, in which
1279 case all listed names are used. At
1280 installation time, <command>systemctl
1281 enable</command> will create symlinks
1282 from these names to the unit
1283 filename.</para></listitem>
1287 <term><varname>WantedBy=</varname></term>
1288 <term><varname>RequiredBy=</varname></term>
1290 <listitem><para>This option may be
1291 used more than once, or a
1292 space-separated list of unit names may
1293 be given. A symbolic link is created
1294 in the <filename>.wants/</filename> or
1295 <filename>.requires/</filename>
1296 directory of each of the listed units
1297 when this unit is installed by
1298 <command>systemctl enable</command>.
1299 This has the effect that a dependency
1300 of type <varname>Wants=</varname> or
1301 <varname>Requires=</varname> is added
1302 from the listed unit to the current
1303 unit. The primary result is that the
1304 current unit will be started when the
1305 listed unit is started. See the
1307 <varname>Wants=</varname> and
1308 <varname>Requires=</varname> in the
1309 [Unit] section for details.</para>
1311 <para><command>WantedBy=foo.service</command>
1313 <filename>bar.service</filename> is
1314 mostly equivalent to
1315 <command>Alias=foo.service.wants/bar.service</command>
1316 in the same file. In case of template
1317 units, <command>systemctl enable</command>
1318 must be called with an instance name, and
1319 this instance will be added to the
1320 <filename>.wants/</filename> or
1321 <filename>.requires/</filename> list
1323 E.g. <command>WantedBy=getty.target</command>
1325 <filename>getty@.service</filename>
1326 will result in <command>systemctl
1327 enable getty@tty2.service</command>
1329 <filename>getty.target.wants/getty@tty2.service</filename>
1330 link to <filename>getty@.service</filename>.
1335 <term><varname>Also=</varname></term>
1337 <listitem><para>Additional units to
1338 install/deinstall when this unit is
1339 installed/deinstalled. If the user
1340 requests installation/deinstallation
1341 of a unit with this option configured,
1342 <command>systemctl enable</command>
1343 and <command>systemctl
1344 disable</command> will automatically
1345 install/uninstall units listed in this option as
1348 <para>This option may be used more
1349 than once, or a space-separated list
1350 of unit names may be
1351 given.</para></listitem>
1355 <term><varname>DefaultInstance=</varname></term>
1357 <listitem><para>In template unit files,
1358 this specifies for which instance the
1359 unit shall be enabled if the template
1360 is enabled without any explicitly set
1361 instance. This option has no effect in
1362 non-template unit files. The specified
1363 string must be usable as instance
1364 identifier.</para></listitem>
1368 <para>The following specifiers are interpreted in the
1369 Install section: %n, %N, %p, %i, %U, %u, %m, %H, %b, %v.
1370 For their meaning see the next section.
1375 <title>Specifiers</title>
1377 <para>Many settings resolve specifiers which may be
1378 used to write generic unit files referring to runtime
1379 or unit parameters that are replaced when the unit
1380 files are loaded. The following specifiers are
1384 <title>Specifiers available in unit files</title>
1385 <tgroup cols='3' align='left' colsep='1' rowsep='1'>
1386 <colspec colname="spec" />
1387 <colspec colname="mean" />
1388 <colspec colname="detail" />
1391 <entry>Specifier</entry>
1392 <entry>Meaning</entry>
1393 <entry>Details</entry>
1398 <entry><literal>%n</literal></entry>
1399 <entry>Full unit name</entry>
1403 <entry><literal>%N</literal></entry>
1404 <entry>Unescaped full unit name</entry>
1405 <entry>Same as <literal>%n</literal>, but with escaping undone</entry>
1408 <entry><literal>%p</literal></entry>
1409 <entry>Prefix name</entry>
1410 <entry>For instantiated units, this refers to the string before the <literal>@</literal> character of the unit name. For non-instantiated units, this refers to the name of the unit with the type suffix removed.</entry>
1413 <entry><literal>%P</literal></entry>
1414 <entry>Unescaped prefix name</entry>
1415 <entry>Same as <literal>%p</literal>, but with escaping undone</entry>
1418 <entry><literal>%i</literal></entry>
1419 <entry>Instance name</entry>
1420 <entry>For instantiated units: this is the string between the <literal>@</literal> character and the suffix of the unit name.</entry>
1423 <entry><literal>%I</literal></entry>
1424 <entry>Unescaped instance name</entry>
1425 <entry>Same as <literal>%i</literal>, but with escaping undone</entry>
1428 <entry><literal>%f</literal></entry>
1429 <entry>Unescaped filename</entry>
1430 <entry>This is either the unescaped instance name (if applicable) with <filename>/</filename> prepended (if applicable), or the prefix name prepended with <filename>/</filename>.</entry>
1433 <entry><literal>%c</literal></entry>
1434 <entry>Control group path of the unit</entry>
1435 <entry>This path does not include the <filename>/sys/fs/cgroup/systemd/</filename> prefix.</entry>
1438 <entry><literal>%r</literal></entry>
1439 <entry>Control group path of the slice the unit is placed in</entry>
1440 <entry>This usually maps to the parent cgroup path of <literal>%c</literal>.</entry>
1443 <entry><literal>%R</literal></entry>
1444 <entry>Root control group path below which slices and units are placed</entry>
1445 <entry>For system instances, this resolves to <filename>/</filename>, except in containers, where this maps to the container's root control group path.</entry>
1448 <entry><literal>%t</literal></entry>
1449 <entry>Runtime directory</entry>
1450 <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>
1453 <entry><literal>%u</literal></entry>
1454 <entry>User name</entry>
1455 <entry>This is the name of the configured user of the unit, or (if none is set) the user running the systemd instance.</entry>
1458 <entry><literal>%U</literal></entry>
1459 <entry>User UID</entry>
1460 <entry>This is the numeric UID of the configured user of the unit, or (if none is set) the user running the systemd user instance. Note that this specifier is not available for units run by the systemd system instance (as opposed to those run by a systemd user instance), unless the user has been configured as a numeric UID in the first place or the configured user is the root user.</entry>
1463 <entry><literal>%h</literal></entry>
1464 <entry>User home directory</entry>
1465 <entry>This is the home directory of the configured user of the unit, or (if none is set) the user running the systemd user instance. Similar to <literal>%U</literal>, this specifier is not available for units run by the systemd system instance, unless the configured user is the root user.</entry>
1468 <entry><literal>%s</literal></entry>
1469 <entry>User shell</entry>
1470 <entry>This is the shell of the configured user of the unit, or (if none is set) the user running the systemd user instance. Similar to <literal>%U</literal>, this specifier is not available for units run by the systemd system instance, unless the configured user is the root user.</entry>
1473 <entry><literal>%m</literal></entry>
1474 <entry>Machine ID</entry>
1475 <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>
1478 <entry><literal>%b</literal></entry>
1479 <entry>Boot ID</entry>
1480 <entry>The boot ID of the running system, formatted as string. See <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for more information.</entry>
1483 <entry><literal>%H</literal></entry>
1484 <entry>Host name</entry>
1485 <entry>The hostname of the running system at the point in time the unit configuation is loaded.</entry>
1488 <entry><literal>%v</literal></entry>
1489 <entry>Kernel release</entry>
1490 <entry>Identical to <command>uname -r</command> output</entry>
1493 <entry><literal>%%</literal></entry>
1494 <entry>Single percent sign</entry>
1495 <entry>Use <literal>%%</literal> in place of <literal>%</literal> to specify a single percent sign.</entry>
1503 <title>See Also</title>
1505 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1506 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1507 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1508 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1509 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1510 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1511 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1512 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1513 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1514 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1515 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1516 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1517 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1518 <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1519 <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1520 <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1521 <citerefentry><refentrytitle>systemd-verify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1522 <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1523 <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1524 <citerefentry><refentrytitle>uname</refentrytitle><manvolnum>1</manvolnum></citerefentry>