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>$XDG_RUNTIME_DIR/systemd/user/*</filename>
77 <filename>/run/systemd/user/*</filename>
78 <filename>$XDG_DATA_HOME/systemd/user/*</filename>
79 <filename>$HOME/.local/share/systemd/user/*</filename>
80 <filename>/usr/lib/systemd/user/*</filename>
81 <filename>...</filename>
82 </literallayout></para>
86 <title>Description</title>
88 <para>A unit configuration file encodes information
89 about a service, a socket, a device, a mount point, an
90 automount point, a swap file or partition, a start-up
91 target, a watched file system path, a timer controlled
93 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
94 a temporary system state snapshot, a resource
95 management slice or a group of externally created
96 processes. The syntax is inspired by <ulink
97 url="http://standards.freedesktop.org/desktop-entry-spec/latest/">XDG
98 Desktop Entry Specification</ulink>
99 <filename>.desktop</filename> files, which are in turn
100 inspired by Microsoft Windows
101 <filename>.ini</filename> files.</para>
103 <para>This man page lists the common configuration
104 options of all the unit types. These options need to
105 be configured in the [Unit] or [Install]
106 sections of the unit files.</para>
108 <para>In addition to the generic [Unit] and [Install]
109 sections described here, each unit may have a
110 type-specific section, e.g. [Service] for a service
111 unit. See the respective man pages for more
113 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
114 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
115 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
116 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
117 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
118 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
119 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
120 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
121 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
122 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
123 <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
124 <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
127 <para>Various settings are allowed to be specified
128 more than once, in which case the interpretation
129 depends on the setting. Often, multiple settings form
130 a list, and setting to an empty value "resets", which
131 means that previous assignments are ignored. When this
132 is allowed, it is mentioned in the description of the
133 setting. Note that using multiple assignments to the
134 same value makes the unit file incompatible with
135 parsers for the XDG <filename>.desktop</filename> file
138 <para>Unit files are loaded from a set of paths
139 determined during compilation, described in the next section.
142 <para>Unit files may contain additional options on top
143 of those listed here. If systemd encounters an unknown
144 option, it will write a warning log message but
145 continue loading the unit. If an option or section name
146 is prefixed with <option>X-</option>, it is ignored
147 completely by systemd. Options within an ignored
148 section do not need the prefix. Applications may use
149 this to include additional information in the unit
152 <para>Boolean arguments used in unit files can be
153 written in various formats. For positive settings the
154 strings <option>1</option>, <option>yes</option>,
155 <option>true</option> and <option>on</option> are
156 equivalent. For negative settings, the strings
157 <option>0</option>, <option>no</option>,
158 <option>false</option> and <option>off</option> are
161 <para>Time span values encoded in unit files can be
162 written in various formats. A stand-alone number
163 specifies a time in seconds. If suffixed with a time
164 unit, the unit is honored. A concatenation of multiple
165 values with units is supported, in which case the
166 values are added up. Example: "50" refers to 50
167 seconds; "2min 200ms" refers to 2 minutes plus 200
168 milliseconds, i.e. 120200ms. The following time units
169 are understood: s, min, h, d, w, ms, us. For details
171 <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
173 <para>Empty lines and lines starting with # or ; are
174 ignored. This may be used for commenting. Lines ending
175 in a backslash are concatenated with the following
176 line while reading and the backslash is replaced by a
177 space character. This may be used to wrap long lines.</para>
179 <para>Along with a unit file
180 <filename>foo.service</filename>, the directory
181 <filename>foo.service.wants/</filename> may exist. All
182 unit files symlinked from such a directory are
183 implicitly added as dependencies of type
184 <varname>Wants=</varname> to the unit. This is useful
185 to hook units into the start-up of other units,
186 without having to modify their unit files. For details
187 about the semantics of <varname>Wants=</varname>, see
188 below. The preferred way to create symlinks in the
189 <filename>.wants/</filename> directory of a unit file
190 is with the <command>enable</command> command of the
191 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
192 tool which reads information from the [Install]
193 section of unit files (see below). A similar
194 functionality exists for <varname>Requires=</varname>
195 type dependencies as well, the directory suffix is
196 <filename>.requires/</filename> in this case.</para>
198 <para>Along with a unit file
199 <filename>foo.service</filename>, a directory
200 <filename>foo.service.d/</filename> may exist. All
201 files with the suffix <literal>.conf</literal> from
202 this directory will be parsed after the file itself is
203 parsed. This is useful to alter or add configuration
204 settings to a unit, without having to modify their
205 unit files. Make sure that the file that is included
206 has the appropriate section headers before any
207 directive. Note that for instanced units this logic
208 will first look for the instance
209 <literal>.d/</literal> subdirectory and read its
210 <literal>.conf</literal> files, followed by the
211 template <literal>.d/</literal> subdirectory and reads
212 its <literal>.conf</literal> files.</para>
214 <para>Note that while systemd offers a flexible
215 dependency system between units it is recommended to
216 use this functionality only sparingly and instead rely
217 on techniques such as bus-based or socket-based
218 activation which make dependencies implicit, resulting
219 in a both simpler and more flexible system.</para>
221 <para>Some unit names reflect paths existing in the
222 file system namespace. Example: a device unit
223 <filename>dev-sda.device</filename> refers to a device
224 with the device node <filename noindex='true'>/dev/sda</filename> in
225 the file system namespace. If this applies, a special
226 way to escape the path name is used, so that the
227 result is usable as part of a filename. Basically,
228 given a path, "/" is replaced by "-", and all
229 unprintable characters and the "-" are replaced by
230 C-style "\x2d" escapes. The root directory "/" is
231 encoded as single dash, while otherwise the initial
232 and ending "/" is removed from all paths during
233 transformation. This escaping is reversible.</para>
235 <para>Optionally, units may be instantiated from a
236 template file at runtime. This allows creation of
237 multiple units from a single configuration file. If
238 systemd looks for a unit configuration file, it will
239 first search for the literal unit name in the
240 file system. If that yields no success and the unit
241 name contains an <literal>@</literal> character, systemd will look for a
242 unit template that shares the same name but with the
243 instance string (i.e. the part between the <literal>@</literal> character
244 and the suffix) removed. Example: if a service
245 <filename>getty@tty3.service</filename> is requested
246 and no file by that name is found, systemd will look
247 for <filename>getty@.service</filename> and
248 instantiate a service from that configuration file if
251 <para>To refer to the instance string from
252 within the configuration file you may use the special
253 <literal>%i</literal> specifier in many of the
254 configuration options. See below for details.</para>
256 <para>If a unit file is empty (i.e. has the file size
257 0) or is symlinked to <filename>/dev/null</filename>,
258 its configuration will not be loaded and it appears
259 with a load state of <literal>masked</literal>, and
260 cannot be activated. Use this as an effective way to
261 fully disable a unit, making it impossible to start it
262 even manually.</para>
264 <para>The unit file format is covered by the
266 url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
267 Stability Promise</ulink>.</para>
272 <title>Unit Load Path</title>
274 <para>Unit files are loaded from a set of paths
275 determined during compilation, described in the two
276 tables below. Unit files found in directories listed
277 earlier override files with the same name in
278 directories lower in the list.</para>
280 <para>When systemd is running in user mode
281 (<option>--user</option>) and the variable
282 <varname>$SYSTEMD_UNIT_PATH</varname> is set, this
283 contents of this variable overrides the unit load
284 path. If <varname>$SYSTEMD_UNIT_PATH</varname> ends
285 with an empty component (<literal>:</literal>), the
286 usual unit load path will be appended to the contents
287 of the variable.</para>
291 Load path when running in system mode (<option>--system</option>).
295 <colspec colname='path' />
296 <colspec colname='expl' />
300 <entry>Description</entry>
305 <entry><filename>/etc/systemd/system</filename></entry>
306 <entry>Local configuration</entry>
309 <entry><filename>/run/systemd/system</filename></entry>
310 <entry>Runtime units</entry>
313 <entry><filename>/usr/lib/systemd/system</filename></entry>
314 <entry>Units of installed packages</entry>
322 Load path when running in user mode (<option>--user</option>).
326 <colspec colname='path' />
327 <colspec colname='expl' />
331 <entry>Description</entry>
336 <entry><filename>$XDG_CONFIG_HOME/systemd/user</filename></entry>
337 <entry>User configuration (only used when $XDG_CONFIG_HOME is set)</entry>
340 <entry><filename>$HOME/.config/systemd/user</filename></entry>
341 <entry>User configuration (only used when $XDG_CONFIG_HOME is not set)</entry>
344 <entry><filename>/etc/systemd/user</filename></entry>
345 <entry>Local configuration</entry>
348 <entry><filename>$XDG_RUNTIME_DIR/systemd/user</filename></entry>
349 <entry>Runtime units (only used when $XDG_RUNTIME_DIR is set)</entry>
352 <entry><filename>/run/systemd/user</filename></entry>
353 <entry>Runtime units</entry>
356 <entry><filename>$XDG_DATA_HOME/systemd/user</filename></entry>
357 <entry>Units of packages that have been installed in the home directory (only used when $XDG_DATA_HOME is set)</entry>
360 <entry><filename>$HOME/.local/share/systemd/user</filename></entry>
361 <entry>Units of packages that have been installed in the home directory (only used when $XDG_DATA_HOME is not set)</entry>
364 <entry><filename>/usr/lib/systemd/user</filename></entry>
365 <entry>Units of packages that have been installed system-wide</entry>
371 <para>Additional units might be loaded into systemd
372 ("linked") from directories not on the unit load
373 path. See the <command>link</command> command for
374 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. Also,
375 some units are dynamically created via generators
377 url="http://www.freedesktop.org/wiki/Software/systemd/Generators/">Generators</ulink>.
382 <title>[Unit] Section Options</title>
384 <para>Unit file may include a [Unit] section, which
385 carries generic information about the unit that is not
386 dependent on the type of unit:</para>
388 <variablelist class='unit-directives'>
391 <term><varname>Description=</varname></term>
392 <listitem><para>A free-form string
393 describing the unit. This is intended
394 for use in UIs to show descriptive
395 information along with the unit
396 name. The description should contain a name
397 that means something to the end user.
398 <literal>Apache2 Web Server</literal> is a good
399 example. Bad examples are
400 <literal>high-performance light-weight HTTP
401 server</literal> (too generic) or
402 <literal>Apache2</literal> (too specific and
403 meaningless for people who do not know
404 Apache).</para></listitem>
408 <term><varname>Documentation=</varname></term>
409 <listitem><para>A space-separated list
410 of URIs referencing documentation for
412 configuration. Accepted are only URIs
414 <literal>http://</literal>,
415 <literal>https://</literal>,
416 <literal>file:</literal>,
417 <literal>info:</literal>,
418 <literal>man:</literal>. For more
419 information about the syntax of these
421 <citerefentry project='man-pages'><refentrytitle>uri</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
422 URIs should be listed in order of
423 relevance, starting with the most
424 relevant. It is a good idea to first
425 reference documentation that explains
426 what the unit's purpose is, followed
427 by how it is configured, followed by
428 any other related documentation. This
429 option may be specified more than once,
430 in which case the specified list of
431 URIs is merged. If the empty string is
432 assigned to this option, the list is
433 reset and all prior assignments will
434 have no effect.</para></listitem>
438 <term><varname>Requires=</varname></term>
440 <listitem><para>Configures requirement
441 dependencies on other units. If this
442 unit gets activated, the units listed
443 here will be activated as well. If one
444 of the other units gets deactivated or
445 its activation fails, this unit will
446 be deactivated. This option may be
447 specified more than once or multiple
448 space-separated units may be specified
449 in one option in which case
450 requirement dependencies for all
451 listed names will be created. Note
452 that requirement dependencies do not
453 influence the order in which services
454 are started or stopped. This has to be
455 configured independently with the
456 <varname>After=</varname> or
457 <varname>Before=</varname> options. If
459 <filename>foo.service</filename>
461 <filename>bar.service</filename> as
463 <varname>Requires=</varname> and no
464 ordering is configured with
465 <varname>After=</varname> or
466 <varname>Before=</varname>, then both
467 units will be started simultaneously
468 and without any delay between them if
469 <filename>foo.service</filename> is
470 activated. Often it is a better choice
471 to use <varname>Wants=</varname>
473 <varname>Requires=</varname> in order
474 to achieve a system that is more
475 robust when dealing with failing
478 <para>Note that dependencies of this
479 type may also be configured outside of
480 the unit configuration file by
481 adding a symlink to a
482 <filename>.requires/</filename> directory
483 accompanying the unit file. For
484 details see above.</para></listitem>
488 <term><varname>RequiresOverridable=</varname></term>
490 <listitem><para>Similar to
491 <varname>Requires=</varname>.
492 Dependencies listed in
493 <varname>RequiresOverridable=</varname>
494 which cannot be fulfilled or fail to
495 start are ignored if the startup was
496 explicitly requested by the user. If
497 the start-up was pulled in indirectly
498 by some dependency or automatic
499 start-up of units that is not
500 requested by the user, this dependency
501 must be fulfilled and otherwise the
502 transaction fails. Hence, this option
503 may be used to configure dependencies
504 that are normally honored unless the
505 user explicitly starts up the unit, in
506 which case whether they failed or not
507 is irrelevant.</para></listitem>
511 <term><varname>Requisite=</varname></term>
512 <term><varname>RequisiteOverridable=</varname></term>
514 <listitem><para>Similar to
515 <varname>Requires=</varname> and
516 <varname>RequiresOverridable=</varname>,
517 respectively. However, if the units
518 listed here are not started already,
519 they will not be started and the
520 transaction will fail immediately.
525 <term><varname>Wants=</varname></term>
527 <listitem><para>A weaker version of
528 <varname>Requires=</varname>. Units
529 listed in this option will be started
530 if the configuring unit is. However,
531 if the listed units fail to start
532 or cannot be added to the transaction,
533 this has no impact on the validity of
534 the transaction as a whole. This is
535 the recommended way to hook start-up
536 of one unit to the start-up of another
539 <para>Note that dependencies of this
540 type may also be configured outside of
541 the unit configuration file by adding
543 <filename>.wants/</filename> directory
544 accompanying the unit file. For
545 details, see above.</para></listitem>
549 <term><varname>BindsTo=</varname></term>
551 <listitem><para>Configures requirement
552 dependencies, very similar in style to
553 <varname>Requires=</varname>, however
554 in addition to this behavior, it also
555 declares that this unit is stopped
556 when any of the units listed suddenly
557 disappears. Units can suddenly,
558 unexpectedly disappear if a service
559 terminates on its own choice, a device
560 is unplugged or a mount point
561 unmounted without involvement of
562 systemd.</para></listitem>
566 <term><varname>PartOf=</varname></term>
568 <listitem><para>Configures dependencies
569 similar to <varname>Requires=</varname>,
570 but limited to stopping and restarting
571 of units. When systemd stops or restarts
572 the units listed here, the action is
573 propagated to this unit.
574 Note that this is a one-way dependency —
575 changes to this unit do not affect the
581 <term><varname>Conflicts=</varname></term>
583 <listitem><para>A space-separated list
584 of unit names. Configures negative
585 requirement dependencies. If a unit
586 has a <varname>Conflicts=</varname>
587 setting on another unit, starting the
588 former will stop the latter and vice
589 versa. Note that this setting is
590 independent of and orthogonal to the
591 <varname>After=</varname> and
592 <varname>Before=</varname> ordering
595 <para>If a unit A that conflicts with
596 a unit B is scheduled to be started at
597 the same time as B, the transaction
598 will either fail (in case both are
599 required part of the transaction) or
600 be modified to be fixed (in case one
601 or both jobs are not a required part
602 of the transaction). In the latter
603 case, the job that is not the required
604 will be removed, or in case both are
605 not required, the unit that conflicts
606 will be started and the unit that is
608 stopped.</para></listitem>
612 <term><varname>Before=</varname></term>
613 <term><varname>After=</varname></term>
615 <listitem><para>A space-separated list
616 of unit names. Configures ordering
617 dependencies between units. If a unit
618 <filename>foo.service</filename>
620 <option>Before=bar.service</option>
621 and both units are being started,
622 <filename>bar.service</filename>'s
623 start-up is delayed until
624 <filename>foo.service</filename> is
625 started up. Note that this setting is
626 independent of and orthogonal to the
627 requirement dependencies as configured
628 by <varname>Requires=</varname>. It is
629 a common pattern to include a unit
631 <varname>After=</varname> and
632 <varname>Requires=</varname> option, in
633 which case the unit listed will be
634 started before the unit that is
635 configured with these options. This
636 option may be specified more than
637 once, in which case ordering
638 dependencies for all listed names are
639 created. <varname>After=</varname> is
641 <varname>Before=</varname>, i.e. while
642 <varname>After=</varname> ensures that
643 the configured unit is started after
644 the listed unit finished starting up,
645 <varname>Before=</varname> ensures the
646 opposite, i.e. that the configured
647 unit is fully started up before the
648 listed unit is started. Note that when
649 two units with an ordering dependency
650 between them are shut down, the
651 inverse of the start-up order is
652 applied. i.e. if a unit is configured
653 with <varname>After=</varname> on
654 another unit, the former is stopped
655 before the latter if both are shut
656 down. If one unit with an ordering
657 dependency on another unit is shut
658 down while the latter is started up,
659 the shut down is ordered before the
660 start-up regardless of whether the
661 ordering dependency is actually of
662 type <varname>After=</varname> or
663 <varname>Before=</varname>. If two
664 units have no ordering dependencies
665 between them, they are shut down or
666 started up simultaneously, and no
668 place. </para></listitem>
672 <term><varname>OnFailure=</varname></term>
674 <listitem><para>A space-separated list
675 of one or more units that are
676 activated when this unit enters the
677 <literal>failed</literal>
678 state.</para></listitem>
682 <term><varname>PropagatesReloadTo=</varname></term>
683 <term><varname>ReloadPropagatedFrom=</varname></term>
685 <listitem><para>A space-separated list
686 of one or more units where reload
687 requests on this unit will be
688 propagated to, or reload requests on
689 the other unit will be propagated to
690 this unit, respectively. Issuing a
691 reload request on a unit will
692 automatically also enqueue a reload
693 request on all units that the reload
694 request shall be propagated to via
695 these two settings.</para></listitem>
699 <term><varname>JoinsNamespaceOf=</varname></term>
701 <listitem><para>For units that start
702 processes (such as service units),
703 lists one or more other units whose
704 network and/or temporary file
705 namespace to join. This only applies
706 to unit types which support the
707 <varname>PrivateNetwork=</varname> and
708 <varname>PrivateTmp=</varname>
710 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
711 for details). If a unit that has this
712 setting set is started, its processes
714 <filename>/tmp</filename>,
715 <filename>/tmp/var</filename> and
716 network namespace as one listed unit
717 that is started. If multiple listed
718 units are already started, it is not
719 defined which namespace is
720 joined. Note that this setting only
722 <varname>PrivateNetwork=</varname>
723 and/or <varname>PrivateTmp=</varname>
724 is enabled for both the unit that
725 joins the namespace and the unit whose
726 namespace is joined.</para></listitem>
730 <term><varname>RequiresMountsFor=</varname></term>
732 <listitem><para>Takes a
733 space-separated list of absolute
734 paths. Automatically adds dependencies
735 of type <varname>Requires=</varname>
736 and <varname>After=</varname> for all
737 mount units required to access the
738 specified path.</para>
740 <para>Mount points marked with
741 <option>noauto</option> are not
742 mounted automatically and will be
743 ignored for the purposes of this
744 option. If such a mount should be a
745 requirement for this unit,
746 direct dependencies on the mount
748 (<varname>Requires=</varname> and
749 <varname>After=</varname> or
750 some other combination).
755 <term><varname>OnFailureJobMode=</varname></term>
757 <listitem><para>Takes a value of
758 <literal>fail</literal>,
759 <literal>replace</literal>,
760 <literal>replace-irreversibly</literal>,
761 <literal>isolate</literal>,
762 <literal>flush</literal>,
763 <literal>ignore-dependencies</literal>
765 <literal>ignore-requirements</literal>. Defaults
767 <literal>replace</literal>. Specifies
768 how the units listed in
769 <varname>OnFailure=</varname> will be
771 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
772 <option>--job-mode=</option> option
773 for details on the possible values. If
775 <literal>isolate</literal>, only a
776 single unit may be listed in
777 <varname>OnFailure=</varname>..</para></listitem>
781 <term><varname>IgnoreOnIsolate=</varname></term>
783 <listitem><para>Takes a boolean
784 argument. If <option>true</option>,
785 this unit will not be stopped when
786 isolating another unit. Defaults to
787 <option>false</option>.</para></listitem>
791 <term><varname>IgnoreOnSnapshot=</varname></term>
793 <listitem><para>Takes a boolean
794 argument. If <option>true</option>,
795 this unit will not be included in
796 snapshots. Defaults to
797 <option>true</option> for device and
798 snapshot units, <option>false</option>
799 for the others.</para></listitem>
803 <term><varname>StopWhenUnneeded=</varname></term>
805 <listitem><para>Takes a boolean
806 argument. If <option>true</option>,
807 this unit will be stopped when it is
808 no longer used. Note that in order to
809 minimize the work to be executed,
810 systemd will not stop units by default
811 unless they are conflicting with other
812 units, or the user explicitly
813 requested their shut down. If this
814 option is set, a unit will be
815 automatically cleaned up if no other
816 active unit requires it. Defaults to
817 <option>false</option>.</para></listitem>
821 <term><varname>RefuseManualStart=</varname></term>
822 <term><varname>RefuseManualStop=</varname></term>
824 <listitem><para>Takes a boolean
825 argument. If <option>true</option>,
826 this unit can only be activated
827 or deactivated indirectly. In
828 this case, explicit start-up
829 or termination requested by the
830 user is denied, however if it is
831 started or stopped as a
832 dependency of another unit, start-up
833 or termination will succeed. This
834 is mostly a safety feature to ensure
835 that the user does not accidentally
836 activate units that are not intended
837 to be activated explicitly, and not
838 accidentally deactivate units that are
839 not intended to be deactivated.
840 These options default to
841 <option>false</option>.</para></listitem>
845 <term><varname>AllowIsolate=</varname></term>
847 <listitem><para>Takes a boolean
848 argument. If <option>true</option>,
849 this unit may be used with the
850 <command>systemctl isolate</command>
851 command. Otherwise, this will be
852 refused. It probably is a good idea to
853 leave this disabled except for target
854 units that shall be used similar to
855 runlevels in SysV init systems, just
856 as a precaution to avoid unusable
857 system states. This option defaults to
858 <option>false</option>.</para></listitem>
862 <term><varname>DefaultDependencies=</varname></term>
864 <listitem><para>Takes a boolean
865 argument. If <option>true</option>,
866 (the default), a few default
867 dependencies will implicitly be
868 created for the unit. The actual
869 dependencies created depend on the
870 unit type. For example, for service
871 units, these dependencies ensure that
872 the service is started only after
873 basic system initialization is
874 completed and is properly terminated on
875 system shutdown. See the respective
876 man pages for details. Generally, only
877 services involved with early boot or
878 late shutdown should set this option
879 to <option>false</option>. It is
880 highly recommended to leave this
881 option enabled for the majority of
882 common units. If set to
883 <option>false</option>, this option
884 does not disable all implicit
885 dependencies, just non-essential
886 ones.</para></listitem>
890 <term><varname>JobTimeoutSec=</varname></term>
892 <listitem><para>When clients are
893 waiting for a job of this unit to
894 complete, time out after the specified
895 time. If this time limit is reached,
896 the job will be cancelled, the unit
897 however will not change state or even
898 enter the <literal>failed</literal>
899 mode. This value defaults to 0 (job
900 timeouts disabled), except for device
901 units. NB: this timeout is independent
902 from any unit-specific timeout (for
903 example, the timeout set with
904 <varname>Timeout=</varname> in service
905 units) as the job timeout has no
906 effect on the unit itself, only on the
907 job that might be pending for it. Or
908 in other words: unit-specific timeouts
909 are useful to abort unit state
910 changes, and revert them. The job
911 timeout set with this option however
912 is useful to abort only the job
913 waiting for the unit state to
914 change.</para></listitem>
918 <term><varname>ConditionArchitecture=</varname></term>
919 <term><varname>ConditionVirtualization=</varname></term>
920 <term><varname>ConditionHost=</varname></term>
921 <term><varname>ConditionKernelCommandLine=</varname></term>
922 <term><varname>ConditionSecurity=</varname></term>
923 <term><varname>ConditionCapability=</varname></term>
924 <term><varname>ConditionACPower=</varname></term>
925 <term><varname>ConditionNeedsUpdate=</varname></term>
926 <term><varname>ConditionFirstBoot=</varname></term>
927 <term><varname>ConditionPathExists=</varname></term>
928 <term><varname>ConditionPathExistsGlob=</varname></term>
929 <term><varname>ConditionPathIsDirectory=</varname></term>
930 <term><varname>ConditionPathIsSymbolicLink=</varname></term>
931 <term><varname>ConditionPathIsMountPoint=</varname></term>
932 <term><varname>ConditionPathIsReadWrite=</varname></term>
933 <term><varname>ConditionDirectoryNotEmpty=</varname></term>
934 <term><varname>ConditionFileNotEmpty=</varname></term>
935 <term><varname>ConditionFileIsExecutable=</varname></term>
936 <term><varname>ConditionNull=</varname></term>
938 <listitem><para>Before starting a unit
939 verify that the specified condition is
940 true. If it is not true, the starting
941 of the unit will be skipped, however
942 all ordering dependencies of it are
943 still respected. A failing condition
944 will not result in the unit being
945 moved into a failure state. The
946 condition is checked at the time the
947 queued start job is to be
950 <para><varname>ConditionArchitecture=</varname>
951 may be used to check whether the
952 system is running on a specific
953 architecture. Takes one of
954 <varname>x86</varname>,
955 <varname>x86-64</varname>,
956 <varname>ppc</varname>,
957 <varname>ppc-le</varname>,
958 <varname>ppc64</varname>,
959 <varname>ppc64-le</varname>,
960 <varname>ia64</varname>,
961 <varname>parisc</varname>,
962 <varname>parisc64</varname>,
963 <varname>s390</varname>,
964 <varname>s390x</varname>,
965 <varname>sparc</varname>,
966 <varname>sparc64</varname>,
967 <varname>mips</varname>,
968 <varname>mips-le</varname>,
969 <varname>mips64</varname>,
970 <varname>mips64-le</varname>,
971 <varname>alpha</varname>,
972 <varname>arm</varname>,
973 <varname>arm-be</varname>,
974 <varname>arm64</varname>,
975 <varname>arm64-be</varname>,
976 <varname>sh</varname>,
977 <varname>sh64</varname>,
978 <varname>m86k</varname>,
979 <varname>tilegx</varname>,
980 <varname>cris</varname> to test
981 against a specific architecture. The
982 architecture is determined from the
983 information returned by
984 <citerefentry><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
985 and is thus subject to
986 <citerefentry><refentrytitle>personality</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Note
987 that a <varname>Personality=</varname>
988 setting in the same unit file has no
989 effect on this condition. A special
991 <varname>native</varname> is mapped to
992 the architecture the system manager
993 itself is compiled for. The test may
994 be negated by prepending an
995 exclamation mark.</para>
997 <para><varname>ConditionVirtualization=</varname>
998 may be used to check whether the
999 system is executed in a virtualized
1000 environment and optionally test
1001 whether it is a specific
1002 implementation. Takes either boolean
1003 value to check if being executed in
1004 any virtualized environment, or one of
1005 <varname>vm</varname> and
1006 <varname>container</varname> to test
1007 against a generic type of
1008 virtualization solution, or one of
1009 <varname>qemu</varname>,
1010 <varname>kvm</varname>,
1011 <varname>zvm</varname>,
1012 <varname>vmware</varname>,
1013 <varname>microsoft</varname>,
1014 <varname>oracle</varname>,
1015 <varname>xen</varname>,
1016 <varname>bochs</varname>,
1017 <varname>uml</varname>,
1018 <varname>openvz</varname>,
1019 <varname>lxc</varname>,
1020 <varname>lxc-libvirt</varname>,
1021 <varname>systemd-nspawn</varname>,
1022 <varname>docker</varname> to test
1023 against a specific implementation. See
1024 <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1025 for a full list of known
1026 virtualization technologies and their
1027 identifiers. If multiple
1028 virtualization technologies are
1029 nested, only the innermost is
1030 considered. The test may be negated by
1031 prepending an exclamation mark.</para>
1033 <para><varname>ConditionHost=</varname>
1034 may be used to match against the
1035 hostname or machine ID of the
1036 host. This either takes a hostname
1037 string (optionally with shell style
1038 globs) which is tested against the
1039 locally set hostname as returned by
1040 <citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
1041 or a machine ID formatted as string
1043 <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
1044 The test may be negated by prepending
1045 an exclamation mark.</para>
1047 <para><varname>ConditionKernelCommandLine=</varname>
1048 may be used to check whether a
1049 specific kernel command line option is
1050 set (or if prefixed with the
1051 exclamation mark unset). The argument
1052 must either be a single word, or an
1053 assignment (i.e. two words, separated
1054 <literal>=</literal>). In the former
1055 case the kernel command line is
1056 searched for the word appearing as is,
1057 or as left hand side of an
1058 assignment. In the latter case, the
1059 exact assignment is looked for with
1060 right and left hand side
1063 <para><varname>ConditionSecurity=</varname>
1064 may be used to check whether the given
1065 security module is enabled on the
1066 system. Currently the recognized values
1067 values are <varname>selinux</varname>,
1068 <varname>apparmor</varname>,
1069 <varname>ima</varname> and
1070 <varname>smack</varname>.
1071 The test may be negated by prepending
1075 <para><varname>ConditionCapability=</varname>
1076 may be used to check whether the given
1077 capability exists in the capability
1078 bounding set of the service manager
1079 (i.e. this does not check whether
1080 capability is actually available in
1081 the permitted or effective sets, see
1082 <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1083 for details). Pass a capability name
1084 such as <literal>CAP_MKNOD</literal>,
1085 possibly prefixed with an exclamation
1086 mark to negate the check.</para>
1088 <para><varname>ConditionACPower=</varname>
1089 may be used to check whether the
1090 system has AC power, or is exclusively
1091 battery powered at the time of
1092 activation of the unit. This takes a
1093 boolean argument. If set to
1094 <varname>true</varname>, the condition
1095 will hold only if at least one AC
1096 connector of the system is connected
1097 to a power source, or if no AC
1098 connectors are known. Conversely, if
1099 set to <varname>false</varname>, the
1100 condition will hold only if there is
1101 at least one AC connector known and
1102 all AC connectors are disconnected
1103 from a power source.</para>
1105 <para><varname>ConditionNeedsUpdate=</varname>
1106 takes one of <filename>/var</filename>
1107 or <filename>/etc</filename> as
1108 argument, possibly prefixed with a
1109 <literal>!</literal> (for inverting
1110 the condition). This condition may be
1111 used to conditionalize units on
1112 whether the specified directory
1113 requires an update because
1114 <filename>/usr</filename>'s
1115 modification time is newer than the
1117 <filename>.updated</filename> in the
1118 specified directory. This is useful to
1119 implement offline updates of the
1120 vendor operating system resources in
1121 <filename>/usr</filename> that require
1122 updating of <filename>/etc</filename>
1123 or <filename>/var</filename> on the
1124 next following boot. Units making use
1125 of this condition should order
1127 <citerefentry><refentrytitle>systemd-update-done.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1128 to make sure they run before the stamp
1129 files's modification time gets reset
1130 indicating a completed update.</para>
1132 <para><varname>ConditionFirstBoot=</varname>
1133 takes a boolean argument. This
1134 condition may be used to
1135 conditionalize units on whether the
1136 system is booting up with an
1137 unpopulated <filename>/etc</filename>
1138 directory. This may be used to
1139 populate <filename>/etc</filename> on
1140 the first boot after factory reset, or
1141 when a new system instances boots up
1142 for the first time.</para>
1145 <varname>ConditionPathExists=</varname>
1146 a file existence condition is
1147 checked before a unit is started. If
1148 the specified absolute path name does
1149 not exist, the condition will
1150 fail. If the absolute path name passed
1152 <varname>ConditionPathExists=</varname>
1153 is prefixed with an exclamation mark
1154 (<literal>!</literal>), the test is negated, and the unit
1155 is only started if the path does not
1158 <para><varname>ConditionPathExistsGlob=</varname>
1160 <varname>ConditionPathExists=</varname>,
1161 but checks for the existence of at
1162 least one file or directory matching
1163 the specified globbing pattern.</para>
1165 <para><varname>ConditionPathIsDirectory=</varname>
1167 <varname>ConditionPathExists=</varname>
1168 but verifies whether a certain path
1172 <para><varname>ConditionPathIsSymbolicLink=</varname>
1174 <varname>ConditionPathExists=</varname>
1175 but verifies whether a certain path
1176 exists and is a symbolic
1179 <para><varname>ConditionPathIsMountPoint=</varname>
1181 <varname>ConditionPathExists=</varname>
1182 but verifies whether a certain path
1183 exists and is a mount
1186 <para><varname>ConditionPathIsReadWrite=</varname>
1188 <varname>ConditionPathExists=</varname>
1189 but verifies whether the underlying
1190 file system is readable and writable
1194 <para><varname>ConditionDirectoryNotEmpty=</varname>
1196 <varname>ConditionPathExists=</varname>
1197 but verifies whether a certain path
1198 exists and is a non-empty
1201 <para><varname>ConditionFileNotEmpty=</varname>
1203 <varname>ConditionPathExists=</varname>
1204 but verifies whether a certain path
1205 exists and refers to a regular file
1206 with a non-zero size.</para>
1208 <para><varname>ConditionFileIsExecutable=</varname>
1210 <varname>ConditionPathExists=</varname>
1211 but verifies whether a certain path
1212 exists, is a regular file and marked
1216 <varname>ConditionNull=</varname> may
1217 be used to add a constant condition
1218 check value to the unit. It takes a
1219 boolean argument. If set to
1220 <varname>false</varname>, the condition
1221 will always fail, otherwise
1224 <para>If multiple conditions are
1225 specified, the unit will be executed if
1226 all of them apply (i.e. a logical AND
1227 is applied). Condition checks can be
1228 prefixed with a pipe symbol (|) in
1229 which case a condition becomes a
1230 triggering condition. If at least one
1231 triggering condition is defined for a
1232 unit, then the unit will be executed if
1233 at least one of the triggering
1234 conditions apply and all of the
1235 non-triggering conditions. If you
1236 prefix an argument with the pipe
1237 symbol and an exclamation mark, the
1238 pipe symbol must be passed first, the
1239 exclamation second. Except for
1240 <varname>ConditionPathIsSymbolicLink=</varname>,
1241 all path checks follow symlinks. If
1242 any of these options is assigned the
1243 empty string, the list of conditions is
1244 reset completely, all previous
1245 condition settings (of any kind) will
1246 have no effect.</para></listitem>
1250 <term><varname>SourcePath=</varname></term>
1251 <listitem><para>A path to a
1252 configuration file this unit has been
1253 generated from. This is primarily
1254 useful for implementation of generator
1255 tools that convert configuration from
1256 an external configuration file format
1257 into native unit files. This
1258 functionality should not be used in
1259 normal units.</para></listitem>
1266 <title>[Install] Section Options</title>
1268 <para>Unit file may include an
1269 <literal>[Install]</literal> section, which carries
1270 installation information for the unit. This section is
1272 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1273 during runtime. It is used exclusively by the
1274 <command>enable</command> and
1275 <command>disable</command> commands of the
1276 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1277 tool during installation of a unit:</para>
1279 <variablelist class='unit-directives'>
1281 <term><varname>Alias=</varname></term>
1283 <listitem><para>A space-separated list
1284 of additional names this unit shall be
1285 installed under. The names listed here
1286 must have the same suffix (i.e. type)
1287 as the unit file name. This option may
1288 be specified more than once, in which
1289 case all listed names are used. At
1290 installation time, <command>systemctl
1291 enable</command> will create symlinks
1292 from these names to the unit
1293 filename.</para></listitem>
1297 <term><varname>WantedBy=</varname></term>
1298 <term><varname>RequiredBy=</varname></term>
1300 <listitem><para>This option may be
1301 used more than once, or a
1302 space-separated list of unit names may
1303 be given. A symbolic link is created
1304 in the <filename>.wants/</filename> or
1305 <filename>.requires/</filename>
1306 directory of each of the listed units
1307 when this unit is installed by
1308 <command>systemctl enable</command>.
1309 This has the effect that a dependency
1310 of type <varname>Wants=</varname> or
1311 <varname>Requires=</varname> is added
1312 from the listed unit to the current
1313 unit. The primary result is that the
1314 current unit will be started when the
1315 listed unit is started. See the
1317 <varname>Wants=</varname> and
1318 <varname>Requires=</varname> in the
1319 [Unit] section for details.</para>
1321 <para><command>WantedBy=foo.service</command>
1323 <filename>bar.service</filename> is
1324 mostly equivalent to
1325 <command>Alias=foo.service.wants/bar.service</command>
1326 in the same file. In case of template
1327 units, <command>systemctl enable</command>
1328 must be called with an instance name, and
1329 this instance will be added to the
1330 <filename>.wants/</filename> or
1331 <filename>.requires/</filename> list
1333 E.g. <command>WantedBy=getty.target</command>
1335 <filename>getty@.service</filename>
1336 will result in <command>systemctl
1337 enable getty@tty2.service</command>
1339 <filename>getty.target.wants/getty@tty2.service</filename>
1340 link to <filename>getty@.service</filename>.
1345 <term><varname>Also=</varname></term>
1347 <listitem><para>Additional units to
1348 install/deinstall when this unit is
1349 installed/deinstalled. If the user
1350 requests installation/deinstallation
1351 of a unit with this option configured,
1352 <command>systemctl enable</command>
1353 and <command>systemctl
1354 disable</command> will automatically
1355 install/uninstall units listed in this option as
1358 <para>This option may be used more
1359 than once, or a space-separated list
1360 of unit names may be
1361 given.</para></listitem>
1365 <term><varname>DefaultInstance=</varname></term>
1367 <listitem><para>In template unit files,
1368 this specifies for which instance the
1369 unit shall be enabled if the template
1370 is enabled without any explicitly set
1371 instance. This option has no effect in
1372 non-template unit files. The specified
1373 string must be usable as instance
1374 identifier.</para></listitem>
1378 <para>The following specifiers are interpreted in the
1379 Install section: %n, %N, %p, %i, %U, %u, %m, %H, %b, %v.
1380 For their meaning see the next section.
1385 <title>Specifiers</title>
1387 <para>Many settings resolve specifiers which may be
1388 used to write generic unit files referring to runtime
1389 or unit parameters that are replaced when the unit
1390 files are loaded. The following specifiers are
1394 <title>Specifiers available in unit files</title>
1395 <tgroup cols='3' align='left' colsep='1' rowsep='1'>
1396 <colspec colname="spec" />
1397 <colspec colname="mean" />
1398 <colspec colname="detail" />
1401 <entry>Specifier</entry>
1402 <entry>Meaning</entry>
1403 <entry>Details</entry>
1408 <entry><literal>%n</literal></entry>
1409 <entry>Full unit name</entry>
1413 <entry><literal>%N</literal></entry>
1414 <entry>Unescaped full unit name</entry>
1415 <entry>Same as <literal>%n</literal>, but with escaping undone</entry>
1418 <entry><literal>%p</literal></entry>
1419 <entry>Prefix name</entry>
1420 <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>
1423 <entry><literal>%P</literal></entry>
1424 <entry>Unescaped prefix name</entry>
1425 <entry>Same as <literal>%p</literal>, but with escaping undone</entry>
1428 <entry><literal>%i</literal></entry>
1429 <entry>Instance name</entry>
1430 <entry>For instantiated units: this is the string between the <literal>@</literal> character and the suffix of the unit name.</entry>
1433 <entry><literal>%I</literal></entry>
1434 <entry>Unescaped instance name</entry>
1435 <entry>Same as <literal>%i</literal>, but with escaping undone</entry>
1438 <entry><literal>%f</literal></entry>
1439 <entry>Unescaped filename</entry>
1440 <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>
1443 <entry><literal>%c</literal></entry>
1444 <entry>Control group path of the unit</entry>
1445 <entry>This path does not include the <filename>/sys/fs/cgroup/systemd/</filename> prefix.</entry>
1448 <entry><literal>%r</literal></entry>
1449 <entry>Control group path of the slice the unit is placed in</entry>
1450 <entry>This usually maps to the parent cgroup path of <literal>%c</literal>.</entry>
1453 <entry><literal>%R</literal></entry>
1454 <entry>Root control group path below which slices and units are placed</entry>
1455 <entry>For system instances, this resolves to <filename>/</filename>, except in containers, where this maps to the container's root control group path.</entry>
1458 <entry><literal>%t</literal></entry>
1459 <entry>Runtime directory</entry>
1460 <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>
1463 <entry><literal>%u</literal></entry>
1464 <entry>User name</entry>
1465 <entry>This is the name of the configured user of the unit, or (if none is set) the user running the systemd instance.</entry>
1468 <entry><literal>%U</literal></entry>
1469 <entry>User UID</entry>
1470 <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>
1473 <entry><literal>%h</literal></entry>
1474 <entry>User home directory</entry>
1475 <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>
1478 <entry><literal>%s</literal></entry>
1479 <entry>User shell</entry>
1480 <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>
1483 <entry><literal>%m</literal></entry>
1484 <entry>Machine ID</entry>
1485 <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>
1488 <entry><literal>%b</literal></entry>
1489 <entry>Boot ID</entry>
1490 <entry>The boot ID of the running system, formatted as string. See <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for more information.</entry>
1493 <entry><literal>%H</literal></entry>
1494 <entry>Host name</entry>
1495 <entry>The hostname of the running system at the point in time the unit configuation is loaded.</entry>
1498 <entry><literal>%v</literal></entry>
1499 <entry>Kernel release</entry>
1500 <entry>Identical to <command>uname -r</command> output</entry>
1503 <entry><literal>%%</literal></entry>
1504 <entry>Single percent sign</entry>
1505 <entry>Use <literal>%%</literal> in place of <literal>%</literal> to specify a single percent sign.</entry>
1513 <title>See Also</title>
1515 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1516 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1517 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1518 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1519 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1520 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1521 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1522 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1523 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1524 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1525 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1526 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1527 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1528 <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1529 <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1530 <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1531 <citerefentry><refentrytitle>systemd-verify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1532 <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1533 <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1534 <citerefentry><refentrytitle>uname</refentrytitle><manvolnum>1</manvolnum></citerefentry>