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>Wanted=</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>Wanted=</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> to
1022 test against a specific
1023 implementation. If multiple
1024 virtualization technologies are nested,
1025 only the innermost is considered. The
1026 test may be negated by prepending an
1027 exclamation mark.</para>
1029 <para><varname>ConditionHost=</varname>
1030 may be used to match against the
1031 hostname or machine ID of the
1032 host. This either takes a hostname
1033 string (optionally with shell style
1034 globs) which is tested against the
1035 locally set hostname as returned by
1036 <citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
1037 or a machine ID formatted as string
1039 <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
1040 The test may be negated by prepending
1041 an exclamation mark.</para>
1043 <para><varname>ConditionKernelCommandLine=</varname>
1044 may be used to check whether a
1045 specific kernel command line option is
1046 set (or if prefixed with the
1047 exclamation mark unset). The argument
1048 must either be a single word, or an
1049 assignment (i.e. two words, separated
1050 <literal>=</literal>). In the former
1051 case the kernel command line is
1052 searched for the word appearing as is,
1053 or as left hand side of an
1054 assignment. In the latter case, the
1055 exact assignment is looked for with
1056 right and left hand side
1059 <para><varname>ConditionSecurity=</varname>
1060 may be used to check whether the given
1061 security module is enabled on the
1062 system. Currently the recognized values
1063 values are <varname>selinux</varname>,
1064 <varname>apparmor</varname>,
1065 <varname>ima</varname> and
1066 <varname>smack</varname>.
1067 The test may be negated by prepending
1071 <para><varname>ConditionCapability=</varname>
1072 may be used to check whether the given
1073 capability exists in the capability
1074 bounding set of the service manager
1075 (i.e. this does not check whether
1076 capability is actually available in
1077 the permitted or effective sets, see
1078 <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1079 for details). Pass a capability name
1080 such as <literal>CAP_MKNOD</literal>,
1081 possibly prefixed with an exclamation
1082 mark to negate the check.</para>
1084 <para><varname>ConditionACPower=</varname>
1085 may be used to check whether the
1086 system has AC power, or is exclusively
1087 battery powered at the time of
1088 activation of the unit. This takes a
1089 boolean argument. If set to
1090 <varname>true</varname>, the condition
1091 will hold only if at least one AC
1092 connector of the system is connected
1093 to a power source, or if no AC
1094 connectors are known. Conversely, if
1095 set to <varname>false</varname>, the
1096 condition will hold only if there is
1097 at least one AC connector known and
1098 all AC connectors are disconnected
1099 from a power source.</para>
1101 <para><varname>ConditionNeedsUpdate=</varname>
1102 takes one of <filename>/var</filename>
1103 or <filename>/etc</filename> as
1104 argument, possibly prefixed with a
1105 <literal>!</literal> (for inverting
1106 the condition). This condition may be
1107 used to conditionalize units on
1108 whether the specified directory
1109 requires an update because
1110 <filename>/usr</filename>'s
1111 modification time is newer than the
1113 <filename>.updated</filename> in the
1114 specified directory. This is useful to
1115 implement offline updates of the
1116 vendor operating system resources in
1117 <filename>/usr</filename> that require
1118 updating of <filename>/etc</filename>
1119 or <filename>/var</filename> on the
1120 next following boot. Units making use
1121 of this condition should order
1123 <citerefentry><refentrytitle>systemd-update-done.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1124 to make sure they run before the stamp
1125 files's modification time gets reset
1126 indicating a completed update.</para>
1128 <para><varname>ConditionFirstBoot=</varname>
1129 takes a boolean argument. This
1130 condition may be used to
1131 conditionalize units on whether the
1132 system is booting up with an
1133 unpopulated <filename>/etc</filename>
1134 directory. This may be used to
1135 populate <filename>/etc</filename> on
1136 the first boot after factory reset, or
1137 when a new system instances boots up
1138 for the first time.</para>
1141 <varname>ConditionPathExists=</varname>
1142 a file existence condition is
1143 checked before a unit is started. If
1144 the specified absolute path name does
1145 not exist, the condition will
1146 fail. If the absolute path name passed
1148 <varname>ConditionPathExists=</varname>
1149 is prefixed with an exclamation mark
1150 (<literal>!</literal>), the test is negated, and the unit
1151 is only started if the path does not
1154 <para><varname>ConditionPathExistsGlob=</varname>
1156 <varname>ConditionPathExists=</varname>,
1157 but checks for the existence of at
1158 least one file or directory matching
1159 the specified globbing pattern.</para>
1161 <para><varname>ConditionPathIsDirectory=</varname>
1163 <varname>ConditionPathExists=</varname>
1164 but verifies whether a certain path
1168 <para><varname>ConditionPathIsSymbolicLink=</varname>
1170 <varname>ConditionPathExists=</varname>
1171 but verifies whether a certain path
1172 exists and is a symbolic
1175 <para><varname>ConditionPathIsMountPoint=</varname>
1177 <varname>ConditionPathExists=</varname>
1178 but verifies whether a certain path
1179 exists and is a mount
1182 <para><varname>ConditionPathIsReadWrite=</varname>
1184 <varname>ConditionPathExists=</varname>
1185 but verifies whether the underlying
1186 file system is readable and writable
1190 <para><varname>ConditionDirectoryNotEmpty=</varname>
1192 <varname>ConditionPathExists=</varname>
1193 but verifies whether a certain path
1194 exists and is a non-empty
1197 <para><varname>ConditionFileNotEmpty=</varname>
1199 <varname>ConditionPathExists=</varname>
1200 but verifies whether a certain path
1201 exists and refers to a regular file
1202 with a non-zero size.</para>
1204 <para><varname>ConditionFileIsExecutable=</varname>
1206 <varname>ConditionPathExists=</varname>
1207 but verifies whether a certain path
1208 exists, is a regular file and marked
1212 <varname>ConditionNull=</varname> may
1213 be used to add a constant condition
1214 check value to the unit. It takes a
1215 boolean argument. If set to
1216 <varname>false</varname>, the condition
1217 will always fail, otherwise
1220 <para>If multiple conditions are
1221 specified, the unit will be executed if
1222 all of them apply (i.e. a logical AND
1223 is applied). Condition checks can be
1224 prefixed with a pipe symbol (|) in
1225 which case a condition becomes a
1226 triggering condition. If at least one
1227 triggering condition is defined for a
1228 unit, then the unit will be executed if
1229 at least one of the triggering
1230 conditions apply and all of the
1231 non-triggering conditions. If you
1232 prefix an argument with the pipe
1233 symbol and an exclamation mark, the
1234 pipe symbol must be passed first, the
1235 exclamation second. Except for
1236 <varname>ConditionPathIsSymbolicLink=</varname>,
1237 all path checks follow symlinks. If
1238 any of these options is assigned the
1239 empty string, the list of conditions is
1240 reset completely, all previous
1241 condition settings (of any kind) will
1242 have no effect.</para></listitem>
1246 <term><varname>SourcePath=</varname></term>
1247 <listitem><para>A path to a
1248 configuration file this unit has been
1249 generated from. This is primarily
1250 useful for implementation of generator
1251 tools that convert configuration from
1252 an external configuration file format
1253 into native unit files. This
1254 functionality should not be used in
1255 normal units.</para></listitem>
1262 <title>[Install] Section Options</title>
1264 <para>Unit file may include an
1265 <literal>[Install]</literal> section, which carries
1266 installation information for the unit. This section is
1268 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1269 during runtime. It is used exclusively by the
1270 <command>enable</command> and
1271 <command>disable</command> commands of the
1272 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1273 tool during installation of a unit:</para>
1275 <variablelist class='unit-directives'>
1277 <term><varname>Alias=</varname></term>
1279 <listitem><para>A space-separated list
1280 of additional names this unit shall be
1281 installed under. The names listed here
1282 must have the same suffix (i.e. type)
1283 as the unit file name. This option may
1284 be specified more than once, in which
1285 case all listed names are used. At
1286 installation time, <command>systemctl
1287 enable</command> will create symlinks
1288 from these names to the unit
1289 filename.</para></listitem>
1293 <term><varname>WantedBy=</varname></term>
1294 <term><varname>RequiredBy=</varname></term>
1296 <listitem><para>This option may be
1297 used more than once, or a
1298 space-separated list of unit names may
1299 be given. A symbolic link is created
1300 in the <filename>.wants/</filename> or
1301 <filename>.requires/</filename>
1302 directory of each of the listed units
1303 when this unit is installed by
1304 <command>systemctl enable</command>.
1305 This has the effect that a dependency
1306 of type <varname>Wants=</varname> or
1307 <varname>Requires=</varname> is added
1308 from the listed unit to the current
1309 unit. The primary result is that the
1310 current unit will be started when the
1311 listed unit is started. See the
1313 <varname>Wants=</varname> and
1314 <varname>Requires=</varname> in the
1315 [Unit] section for details.</para>
1317 <para><command>WantedBy=foo.service</command>
1319 <filename>bar.service</filename> is
1320 mostly equivalent to
1321 <command>Alias=foo.service.wants/bar.service</command>
1322 in the same file. In case of template
1323 units, <command>systemctl enable</command>
1324 must be called with an instance name, and
1325 this instance will be added to the
1326 <filename>.wants/</filename> or
1327 <filename>.requires/</filename> list
1329 E.g. <command>WantedBy=getty.target</command>
1331 <filename>getty@.service</filename>
1332 will result in <command>systemctl
1333 enable getty@tty2.service</command>
1335 <filename>getty.target.wants/getty@tty2.service</filename>
1336 link to <filename>getty@.service</filename>.
1341 <term><varname>Also=</varname></term>
1343 <listitem><para>Additional units to
1344 install/deinstall when this unit is
1345 installed/deinstalled. If the user
1346 requests installation/deinstallation
1347 of a unit with this option configured,
1348 <command>systemctl enable</command>
1349 and <command>systemctl
1350 disable</command> will automatically
1351 install/uninstall units listed in this option as
1354 <para>This option may be used more
1355 than once, or a space-separated list
1356 of unit names may be
1357 given.</para></listitem>
1361 <term><varname>DefaultInstance=</varname></term>
1363 <listitem><para>In template unit files,
1364 this specifies for which instance the
1365 unit shall be enabled if the template
1366 is enabled without any explicitly set
1367 instance. This option has no effect in
1368 non-template unit files. The specified
1369 string must be usable as instance
1370 identifier.</para></listitem>
1374 <para>The following specifiers are interpreted in the
1375 Install section: %n, %N, %p, %i, %U, %u, %m, %H, %b, %v.
1376 For their meaning see the next section.
1381 <title>Specifiers</title>
1383 <para>Many settings resolve specifiers which may be
1384 used to write generic unit files referring to runtime
1385 or unit parameters that are replaced when the unit
1386 files are loaded. The following specifiers are
1390 <title>Specifiers available in unit files</title>
1391 <tgroup cols='3' align='left' colsep='1' rowsep='1'>
1392 <colspec colname="spec" />
1393 <colspec colname="mean" />
1394 <colspec colname="detail" />
1397 <entry>Specifier</entry>
1398 <entry>Meaning</entry>
1399 <entry>Details</entry>
1404 <entry><literal>%n</literal></entry>
1405 <entry>Full unit name</entry>
1409 <entry><literal>%N</literal></entry>
1410 <entry>Unescaped full unit name</entry>
1411 <entry>Same as <literal>%n</literal>, but with escaping undone</entry>
1414 <entry><literal>%p</literal></entry>
1415 <entry>Prefix name</entry>
1416 <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>
1419 <entry><literal>%P</literal></entry>
1420 <entry>Unescaped prefix name</entry>
1421 <entry>Same as <literal>%p</literal>, but with escaping undone</entry>
1424 <entry><literal>%i</literal></entry>
1425 <entry>Instance name</entry>
1426 <entry>For instantiated units: this is the string between the <literal>@</literal> character and the suffix of the unit name.</entry>
1429 <entry><literal>%I</literal></entry>
1430 <entry>Unescaped instance name</entry>
1431 <entry>Same as <literal>%i</literal>, but with escaping undone</entry>
1434 <entry><literal>%f</literal></entry>
1435 <entry>Unescaped filename</entry>
1436 <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>
1439 <entry><literal>%c</literal></entry>
1440 <entry>Control group path of the unit</entry>
1441 <entry>This path does not include the <filename>/sys/fs/cgroup/systemd/</filename> prefix.</entry>
1444 <entry><literal>%r</literal></entry>
1445 <entry>Control group path of the slice the unit is placed in</entry>
1446 <entry>This usually maps to the parent cgroup path of <literal>%c</literal>.</entry>
1449 <entry><literal>%R</literal></entry>
1450 <entry>Root control group path below which slices and units are placed</entry>
1451 <entry>For system instances, this resolves to <filename>/</filename>, except in containers, where this maps to the container's root control group path.</entry>
1454 <entry><literal>%t</literal></entry>
1455 <entry>Runtime directory</entry>
1456 <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>
1459 <entry><literal>%u</literal></entry>
1460 <entry>User name</entry>
1461 <entry>This is the name of the configured user of the unit, or (if none is set) the user running the systemd instance.</entry>
1464 <entry><literal>%U</literal></entry>
1465 <entry>User UID</entry>
1466 <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>
1469 <entry><literal>%h</literal></entry>
1470 <entry>User home directory</entry>
1471 <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>
1474 <entry><literal>%s</literal></entry>
1475 <entry>User shell</entry>
1476 <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>
1479 <entry><literal>%m</literal></entry>
1480 <entry>Machine ID</entry>
1481 <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>
1484 <entry><literal>%b</literal></entry>
1485 <entry>Boot ID</entry>
1486 <entry>The boot ID of the running system, formatted as string. See <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for more information.</entry>
1489 <entry><literal>%H</literal></entry>
1490 <entry>Host name</entry>
1491 <entry>The hostname of the running system at the point in time the unit configuation is loaded.</entry>
1494 <entry><literal>%v</literal></entry>
1495 <entry>Kernel release</entry>
1496 <entry>Identical to <command>uname -r</command> output</entry>
1499 <entry><literal>%%</literal></entry>
1500 <entry>Single percent sign</entry>
1501 <entry>Use <literal>%%</literal> in place of <literal>%</literal> to specify a single percent sign.</entry>
1509 <title>See Also</title>
1511 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1512 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1513 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1514 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1515 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1516 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1517 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1518 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1519 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1520 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1521 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1522 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1523 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1524 <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1525 <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1526 <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1527 <citerefentry><refentrytitle>systemd-verify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1528 <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1529 <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1530 <citerefentry><refentrytitle>uname</refentrytitle><manvolnum>1</manvolnum></citerefentry>