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