1 <?xml version='1.0'?> <!--*-nxml-*-->
2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
4 <!ENTITY % entities SYSTEM "custom-entities.ent" >
9 This file is part of systemd.
11 Copyright 2010 Lennart Poettering
13 systemd is free software; you can redistribute it and/or modify it
14 under the terms of the GNU Lesser General Public License as published by
15 the Free Software Foundation; either version 2.1 of the License, or
16 (at your option) any later version.
18 systemd is distributed in the hope that it will be useful, but
19 WITHOUT ANY WARRANTY; without even the implied warranty of
20 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
21 Lesser General Public License for more details.
23 You should have received a copy of the GNU Lesser General Public License
24 along with systemd; If not, see <http://www.gnu.org/licenses/>.
27 <refentry id="systemd.unit">
30 <title>systemd.unit</title>
31 <productname>systemd</productname>
35 <contrib>Developer</contrib>
36 <firstname>Lennart</firstname>
37 <surname>Poettering</surname>
38 <email>lennart@poettering.net</email>
44 <refentrytitle>systemd.unit</refentrytitle>
45 <manvolnum>5</manvolnum>
49 <refname>systemd.unit</refname>
50 <refpurpose>Unit configuration</refpurpose>
54 <para><filename><replaceable>service</replaceable>.service</filename>,
55 <filename><replaceable>socket</replaceable>.socket</filename>,
56 <filename><replaceable>device</replaceable>.device</filename>,
57 <filename><replaceable>mount</replaceable>.mount</filename>,
58 <filename><replaceable>automount</replaceable>.automount</filename>,
59 <filename><replaceable>swap</replaceable>.swap</filename>,
60 <filename><replaceable>target</replaceable>.target</filename>,
61 <filename><replaceable>path</replaceable>.path</filename>,
62 <filename><replaceable>timer</replaceable>.timer</filename>,
63 <filename><replaceable>snapshot</replaceable>.snapshot</filename>,
64 <filename><replaceable>slice</replaceable>.slice</filename>,
65 <filename><replaceable>scope</replaceable>.scope</filename></para>
67 <para><literallayout><filename>/etc/systemd/system/*</filename>
68 <filename>/run/systemd/system/*</filename>
69 <filename>/usr/lib/systemd/system/*</filename>
70 <filename>...</filename>
71 </literallayout></para>
73 <para><literallayout><filename>$XDG_CONFIG_HOME/systemd/user/*</filename>
74 <filename>$HOME/.config/systemd/user/*</filename>
75 <filename>/etc/systemd/user/*</filename>
76 <filename>$XDG_RUNTIME_DIR/systemd/user/*</filename>
77 <filename>/run/systemd/user/*</filename>
78 <filename>$XDG_DATA_HOME/systemd/user/*</filename>
79 <filename>$HOME/.local/share/systemd/user/*</filename>
80 <filename>/usr/lib/systemd/user/*</filename>
81 <filename>...</filename>
82 </literallayout></para>
86 <title>Description</title>
88 <para>A unit configuration file encodes information
89 about a service, a socket, a device, a mount point, an
90 automount point, a swap file or partition, a start-up
91 target, a watched file system path, a timer controlled
93 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
94 a temporary system state snapshot, a resource
95 management slice or a group of externally created
96 processes. The syntax is inspired by <ulink
97 url="http://standards.freedesktop.org/desktop-entry-spec/latest/">XDG
98 Desktop Entry Specification</ulink>
99 <filename>.desktop</filename> files, which are in turn
100 inspired by Microsoft Windows
101 <filename>.ini</filename> files.</para>
103 <para>This man page lists the common configuration
104 options of all the unit types. These options need to
105 be configured in the [Unit] or [Install]
106 sections of the unit files.</para>
108 <para>In addition to the generic [Unit] and [Install]
109 sections described here, each unit may have a
110 type-specific section, e.g. [Service] for a service
111 unit. See the respective man pages for more
113 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
114 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
115 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
116 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
117 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
118 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
119 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
120 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
121 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
122 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
123 <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
124 <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
127 <para>Various settings are allowed to be specified
128 more than once, in which case the interpretation
129 depends on the setting. Often, multiple settings form
130 a list, and setting to an empty value "resets", which
131 means that previous assignments are ignored. When this
132 is allowed, it is mentioned in the description of the
133 setting. Note that using multiple assignments to the
134 same value makes the unit file incompatible with
135 parsers for the XDG <filename>.desktop</filename> file
138 <para>Unit files are loaded from a set of paths
139 determined during compilation, described in the next section.
142 <para>Unit files may contain additional options on top
143 of those listed here. If systemd encounters an unknown
144 option, it will write a warning log message but
145 continue loading the unit. If an option or section name
146 is prefixed with <option>X-</option>, it is ignored
147 completely by systemd. Options within an ignored
148 section do not need the prefix. Applications may use
149 this to include additional information in the unit
152 <para>Boolean arguments used in unit files can be
153 written in various formats. For positive settings the
154 strings <option>1</option>, <option>yes</option>,
155 <option>true</option> and <option>on</option> are
156 equivalent. For negative settings, the strings
157 <option>0</option>, <option>no</option>,
158 <option>false</option> and <option>off</option> are
161 <para>Time span values encoded in unit files can be
162 written in various formats. A stand-alone number
163 specifies a time in seconds. If suffixed with a time
164 unit, the unit is honored. A concatenation of multiple
165 values with units is supported, in which case the
166 values are added up. Example: "50" refers to 50
167 seconds; "2min 200ms" refers to 2 minutes plus 200
168 milliseconds, i.e. 120200ms. The following time units
169 are understood: s, min, h, d, w, ms, us. For details
171 <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
173 <para>Empty lines and lines starting with # or ; are
174 ignored. This may be used for commenting. Lines ending
175 in a backslash are concatenated with the following
176 line while reading and the backslash is replaced by a
177 space character. This may be used to wrap long lines.</para>
179 <para>Along with a unit file
180 <filename>foo.service</filename>, the directory
181 <filename>foo.service.wants/</filename> may exist. All
182 unit files symlinked from such a directory are
183 implicitly added as dependencies of type
184 <varname>Wants=</varname> to the unit. This is useful
185 to hook units into the start-up of other units,
186 without having to modify their unit files. For details
187 about the semantics of <varname>Wants=</varname>, see
188 below. The preferred way to create symlinks in the
189 <filename>.wants/</filename> directory of a unit file
190 is with the <command>enable</command> command of the
191 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
192 tool which reads information from the [Install]
193 section of unit files (see below). A similar
194 functionality exists for <varname>Requires=</varname>
195 type dependencies as well, the directory suffix is
196 <filename>.requires/</filename> in this case.</para>
198 <para>Along with a unit file
199 <filename>foo.service</filename>, a directory
200 <filename>foo.service.d/</filename> may exist. All
201 files with the suffix <literal>.conf</literal> from
202 this directory will be parsed after the file itself is
203 parsed. This is useful to alter or add configuration
204 settings to a unit, without having to modify their
205 unit files. Make sure that the file that is included
206 has the appropriate section headers before any
207 directive. Note that for instanced units this logic
208 will first look for the instance
209 <literal>.d/</literal> subdirectory and read its
210 <literal>.conf</literal> files, followed by the
211 template <literal>.d/</literal> subdirectory and reads
212 its <literal>.conf</literal> files.</para>
214 <!-- Note that we do not document .include here, as we
215 consider it mostly obsolete, and want people to
216 use .d/ drop-ins instead. -->
218 <para>Note that while systemd offers a flexible
219 dependency system between units it is recommended to
220 use this functionality only sparingly and instead rely
221 on techniques such as bus-based or socket-based
222 activation which make dependencies implicit, resulting
223 in a both simpler and more flexible system.</para>
225 <para>Some unit names reflect paths existing in the
226 file system namespace. Example: a device unit
227 <filename>dev-sda.device</filename> refers to a device
228 with the device node <filename noindex='true'>/dev/sda</filename> in
229 the file system namespace. If this applies, a special
230 way to escape the path name is used, so that the
231 result is usable as part of a filename. Basically,
232 given a path, "/" is replaced by "-", and all
233 unprintable characters and the "-" are replaced by
234 C-style "\x2d" escapes. The root directory "/" is
235 encoded as single dash, while otherwise the initial
236 and ending "/" is removed from all paths during
237 transformation. This escaping is reversible.</para>
239 <para>Optionally, units may be instantiated from a
240 template file at runtime. This allows creation of
241 multiple units from a single configuration file. If
242 systemd looks for a unit configuration file, it will
243 first search for the literal unit name in the
244 file system. If that yields no success and the unit
245 name contains an <literal>@</literal> character, systemd will look for a
246 unit template that shares the same name but with the
247 instance string (i.e. the part between the <literal>@</literal> character
248 and the suffix) removed. Example: if a service
249 <filename>getty@tty3.service</filename> is requested
250 and no file by that name is found, systemd will look
251 for <filename>getty@.service</filename> and
252 instantiate a service from that configuration file if
255 <para>To refer to the instance string from
256 within the configuration file you may use the special
257 <literal>%i</literal> specifier in many of the
258 configuration options. See below for details.</para>
260 <para>If a unit file is empty (i.e. has the file size
261 0) or is symlinked to <filename>/dev/null</filename>,
262 its configuration will not be loaded and it appears
263 with a load state of <literal>masked</literal>, and
264 cannot be activated. Use this as an effective way to
265 fully disable a unit, making it impossible to start it
266 even manually.</para>
268 <para>The unit file format is covered by the
270 url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
271 Stability Promise</ulink>.</para>
276 <title>Unit Load Path</title>
278 <para>Unit files are loaded from a set of paths
279 determined during compilation, described in the two
280 tables below. Unit files found in directories listed
281 earlier override files with the same name in
282 directories lower in the list.</para>
284 <para>When systemd is running in user mode
285 (<option>--user</option>) and the variable
286 <varname>$SYSTEMD_UNIT_PATH</varname> is set, this
287 contents of this variable overrides the unit load
288 path. If <varname>$SYSTEMD_UNIT_PATH</varname> ends
289 with an empty component (<literal>:</literal>), the
290 usual unit load path will be appended to the contents
291 of the variable.</para>
295 Load path when running in system mode (<option>--system</option>).
299 <colspec colname='path' />
300 <colspec colname='expl' />
304 <entry>Description</entry>
309 <entry><filename>/etc/systemd/system</filename></entry>
310 <entry>Local configuration</entry>
313 <entry><filename>/run/systemd/system</filename></entry>
314 <entry>Runtime units</entry>
317 <entry><filename>/usr/lib/systemd/system</filename></entry>
318 <entry>Units of installed packages</entry>
326 Load path when running in user mode (<option>--user</option>).
330 <colspec colname='path' />
331 <colspec colname='expl' />
335 <entry>Description</entry>
340 <entry><filename>$XDG_CONFIG_HOME/systemd/user</filename></entry>
341 <entry>User configuration (only used when $XDG_CONFIG_HOME is set)</entry>
344 <entry><filename>$HOME/.config/systemd/user</filename></entry>
345 <entry>User configuration (only used when $XDG_CONFIG_HOME is not set)</entry>
348 <entry><filename>/etc/systemd/user</filename></entry>
349 <entry>Local configuration</entry>
352 <entry><filename>$XDG_RUNTIME_DIR/systemd/user</filename></entry>
353 <entry>Runtime units (only used when $XDG_RUNTIME_DIR is set)</entry>
356 <entry><filename>/run/systemd/user</filename></entry>
357 <entry>Runtime units</entry>
360 <entry><filename>$XDG_DATA_HOME/systemd/user</filename></entry>
361 <entry>Units of packages that have been installed in the home directory (only used when $XDG_DATA_HOME is set)</entry>
364 <entry><filename>$HOME/.local/share/systemd/user</filename></entry>
365 <entry>Units of packages that have been installed in the home directory (only used when $XDG_DATA_HOME is not set)</entry>
368 <entry><filename>/usr/lib/systemd/user</filename></entry>
369 <entry>Units of packages that have been installed system-wide</entry>
375 <para>Additional units might be loaded into systemd
376 ("linked") from directories not on the unit load
377 path. See the <command>link</command> command for
378 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. Also,
379 some units are dynamically created via generators
381 url="http://www.freedesktop.org/wiki/Software/systemd/Generators/">Generators</ulink>.
386 <title>[Unit] Section Options</title>
388 <para>Unit file may include a [Unit] section, which
389 carries generic information about the unit that is not
390 dependent on the type of unit:</para>
392 <variablelist class='unit-directives'>
395 <term><varname>Description=</varname></term>
396 <listitem><para>A free-form string
397 describing the unit. This is intended
398 for use in UIs to show descriptive
399 information along with the unit
400 name. The description should contain a name
401 that means something to the end user.
402 <literal>Apache2 Web Server</literal> is a good
403 example. Bad examples are
404 <literal>high-performance light-weight HTTP
405 server</literal> (too generic) or
406 <literal>Apache2</literal> (too specific and
407 meaningless for people who do not know
408 Apache).</para></listitem>
412 <term><varname>Documentation=</varname></term>
413 <listitem><para>A space-separated list
414 of URIs referencing documentation for
416 configuration. Accepted are only URIs
418 <literal>http://</literal>,
419 <literal>https://</literal>,
420 <literal>file:</literal>,
421 <literal>info:</literal>,
422 <literal>man:</literal>. For more
423 information about the syntax of these
425 <citerefentry project='man-pages'><refentrytitle>uri</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
426 URIs should be listed in order of
427 relevance, starting with the most
428 relevant. It is a good idea to first
429 reference documentation that explains
430 what the unit's purpose is, followed
431 by how it is configured, followed by
432 any other related documentation. This
433 option may be specified more than once,
434 in which case the specified list of
435 URIs is merged. If the empty string is
436 assigned to this option, the list is
437 reset and all prior assignments will
438 have no effect.</para></listitem>
442 <term><varname>Requires=</varname></term>
444 <listitem><para>Configures requirement
445 dependencies on other units. If this
446 unit gets activated, the units listed
447 here will be activated as well. If one
448 of the other units gets deactivated or
449 its activation fails, this unit will
450 be deactivated. This option may be
451 specified more than once or multiple
452 space-separated units may be specified
453 in one option in which case
454 requirement dependencies for all
455 listed names will be created. Note
456 that requirement dependencies do not
457 influence the order in which services
458 are started or stopped. This has to be
459 configured independently with the
460 <varname>After=</varname> or
461 <varname>Before=</varname> options. If
463 <filename>foo.service</filename>
465 <filename>bar.service</filename> as
467 <varname>Requires=</varname> and no
468 ordering is configured with
469 <varname>After=</varname> or
470 <varname>Before=</varname>, then both
471 units will be started simultaneously
472 and without any delay between them if
473 <filename>foo.service</filename> is
474 activated. Often it is a better choice
475 to use <varname>Wants=</varname>
477 <varname>Requires=</varname> in order
478 to achieve a system that is more
479 robust when dealing with failing
482 <para>Note that dependencies of this
483 type may also be configured outside of
484 the unit configuration file by
485 adding a symlink to a
486 <filename>.requires/</filename> directory
487 accompanying the unit file. For
488 details see above.</para></listitem>
492 <term><varname>RequiresOverridable=</varname></term>
494 <listitem><para>Similar to
495 <varname>Requires=</varname>.
496 Dependencies listed in
497 <varname>RequiresOverridable=</varname>
498 which cannot be fulfilled or fail to
499 start are ignored if the startup was
500 explicitly requested by the user. If
501 the start-up was pulled in indirectly
502 by some dependency or automatic
503 start-up of units that is not
504 requested by the user, this dependency
505 must be fulfilled and otherwise the
506 transaction fails. Hence, this option
507 may be used to configure dependencies
508 that are normally honored unless the
509 user explicitly starts up the unit, in
510 which case whether they failed or not
511 is irrelevant.</para></listitem>
515 <term><varname>Requisite=</varname></term>
516 <term><varname>RequisiteOverridable=</varname></term>
518 <listitem><para>Similar to
519 <varname>Requires=</varname> and
520 <varname>RequiresOverridable=</varname>,
521 respectively. However, if the units
522 listed here are not started already,
523 they will not be started and the
524 transaction will fail immediately.
529 <term><varname>Wants=</varname></term>
531 <listitem><para>A weaker version of
532 <varname>Requires=</varname>. Units
533 listed in this option will be started
534 if the configuring unit is. However,
535 if the listed units fail to start
536 or cannot be added to the transaction,
537 this has no impact on the validity of
538 the transaction as a whole. This is
539 the recommended way to hook start-up
540 of one unit to the start-up of another
543 <para>Note that dependencies of this
544 type may also be configured outside of
545 the unit configuration file by adding
547 <filename>.wants/</filename> directory
548 accompanying the unit file. For
549 details, see above.</para></listitem>
553 <term><varname>BindsTo=</varname></term>
555 <listitem><para>Configures requirement
556 dependencies, very similar in style to
557 <varname>Requires=</varname>, however
558 in addition to this behavior, it also
559 declares that this unit is stopped
560 when any of the units listed suddenly
561 disappears. Units can suddenly,
562 unexpectedly disappear if a service
563 terminates on its own choice, a device
564 is unplugged or a mount point
565 unmounted without involvement of
566 systemd.</para></listitem>
570 <term><varname>PartOf=</varname></term>
572 <listitem><para>Configures dependencies
573 similar to <varname>Requires=</varname>,
574 but limited to stopping and restarting
575 of units. When systemd stops or restarts
576 the units listed here, the action is
577 propagated to this unit.
578 Note that this is a one-way dependency —
579 changes to this unit do not affect the
585 <term><varname>Conflicts=</varname></term>
587 <listitem><para>A space-separated list
588 of unit names. Configures negative
589 requirement dependencies. If a unit
590 has a <varname>Conflicts=</varname>
591 setting on another unit, starting the
592 former will stop the latter and vice
593 versa. Note that this setting is
594 independent of and orthogonal to the
595 <varname>After=</varname> and
596 <varname>Before=</varname> ordering
599 <para>If a unit A that conflicts with
600 a unit B is scheduled to be started at
601 the same time as B, the transaction
602 will either fail (in case both are
603 required part of the transaction) or
604 be modified to be fixed (in case one
605 or both jobs are not a required part
606 of the transaction). In the latter
607 case, the job that is not the required
608 will be removed, or in case both are
609 not required, the unit that conflicts
610 will be started and the unit that is
612 stopped.</para></listitem>
616 <term><varname>Before=</varname></term>
617 <term><varname>After=</varname></term>
619 <listitem><para>A space-separated list
620 of unit names. Configures ordering
621 dependencies between units. If a unit
622 <filename>foo.service</filename>
624 <option>Before=bar.service</option>
625 and both units are being started,
626 <filename>bar.service</filename>'s
627 start-up is delayed until
628 <filename>foo.service</filename> is
629 started up. Note that this setting is
630 independent of and orthogonal to the
631 requirement dependencies as configured
632 by <varname>Requires=</varname>. It is
633 a common pattern to include a unit
635 <varname>After=</varname> and
636 <varname>Requires=</varname> option, in
637 which case the unit listed will be
638 started before the unit that is
639 configured with these options. This
640 option may be specified more than
641 once, in which case ordering
642 dependencies for all listed names are
643 created. <varname>After=</varname> is
645 <varname>Before=</varname>, i.e. while
646 <varname>After=</varname> ensures that
647 the configured unit is started after
648 the listed unit finished starting up,
649 <varname>Before=</varname> ensures the
650 opposite, i.e. that the configured
651 unit is fully started up before the
652 listed unit is started. Note that when
653 two units with an ordering dependency
654 between them are shut down, the
655 inverse of the start-up order is
656 applied. i.e. if a unit is configured
657 with <varname>After=</varname> on
658 another unit, the former is stopped
659 before the latter if both are shut
660 down. If one unit with an ordering
661 dependency on another unit is shut
662 down while the latter is started up,
663 the shut down is ordered before the
664 start-up regardless of whether the
665 ordering dependency is actually of
666 type <varname>After=</varname> or
667 <varname>Before=</varname>. If two
668 units have no ordering dependencies
669 between them, they are shut down or
670 started up simultaneously, and no
672 place. </para></listitem>
676 <term><varname>OnFailure=</varname></term>
678 <listitem><para>A space-separated list
679 of one or more units that are
680 activated when this unit enters the
681 <literal>failed</literal>
682 state.</para></listitem>
686 <term><varname>PropagatesReloadTo=</varname></term>
687 <term><varname>ReloadPropagatedFrom=</varname></term>
689 <listitem><para>A space-separated list
690 of one or more units where reload
691 requests on this unit will be
692 propagated to, or reload requests on
693 the other unit will be propagated to
694 this unit, respectively. Issuing a
695 reload request on a unit will
696 automatically also enqueue a reload
697 request on all units that the reload
698 request shall be propagated to via
699 these two settings.</para></listitem>
703 <term><varname>JoinsNamespaceOf=</varname></term>
705 <listitem><para>For units that start
706 processes (such as service units),
707 lists one or more other units whose
708 network and/or temporary file
709 namespace to join. This only applies
710 to unit types which support the
711 <varname>PrivateNetwork=</varname> and
712 <varname>PrivateTmp=</varname>
714 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
715 for details). If a unit that has this
716 setting set is started, its processes
718 <filename>/tmp</filename>,
719 <filename>/tmp/var</filename> and
720 network namespace as one listed unit
721 that is started. If multiple listed
722 units are already started, it is not
723 defined which namespace is
724 joined. Note that this setting only
726 <varname>PrivateNetwork=</varname>
727 and/or <varname>PrivateTmp=</varname>
728 is enabled for both the unit that
729 joins the namespace and the unit whose
730 namespace is joined.</para></listitem>
734 <term><varname>RequiresMountsFor=</varname></term>
736 <listitem><para>Takes a
737 space-separated list of absolute
738 paths. Automatically adds dependencies
739 of type <varname>Requires=</varname>
740 and <varname>After=</varname> for all
741 mount units required to access the
742 specified path.</para>
744 <para>Mount points marked with
745 <option>noauto</option> are not
746 mounted automatically and will be
747 ignored for the purposes of this
748 option. If such a mount should be a
749 requirement for this unit,
750 direct dependencies on the mount
752 (<varname>Requires=</varname> and
753 <varname>After=</varname> or
754 some other combination).
759 <term><varname>OnFailureJobMode=</varname></term>
761 <listitem><para>Takes a value of
762 <literal>fail</literal>,
763 <literal>replace</literal>,
764 <literal>replace-irreversibly</literal>,
765 <literal>isolate</literal>,
766 <literal>flush</literal>,
767 <literal>ignore-dependencies</literal>
769 <literal>ignore-requirements</literal>. Defaults
771 <literal>replace</literal>. Specifies
772 how the units listed in
773 <varname>OnFailure=</varname> will be
775 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
776 <option>--job-mode=</option> option
777 for details on the possible values. If
779 <literal>isolate</literal>, only a
780 single unit may be listed in
781 <varname>OnFailure=</varname>..</para></listitem>
785 <term><varname>IgnoreOnIsolate=</varname></term>
787 <listitem><para>Takes a boolean
788 argument. If <option>true</option>,
789 this unit will not be stopped when
790 isolating another unit. Defaults to
791 <option>false</option>.</para></listitem>
795 <term><varname>IgnoreOnSnapshot=</varname></term>
797 <listitem><para>Takes a boolean
798 argument. If <option>true</option>,
799 this unit will not be included in
800 snapshots. Defaults to
801 <option>true</option> for device and
802 snapshot units, <option>false</option>
803 for the others.</para></listitem>
807 <term><varname>StopWhenUnneeded=</varname></term>
809 <listitem><para>Takes a boolean
810 argument. If <option>true</option>,
811 this unit will be stopped when it is
812 no longer used. Note that in order to
813 minimize the work to be executed,
814 systemd will not stop units by default
815 unless they are conflicting with other
816 units, or the user explicitly
817 requested their shut down. If this
818 option is set, a unit will be
819 automatically cleaned up if no other
820 active unit requires it. Defaults to
821 <option>false</option>.</para></listitem>
825 <term><varname>RefuseManualStart=</varname></term>
826 <term><varname>RefuseManualStop=</varname></term>
828 <listitem><para>Takes a boolean
829 argument. If <option>true</option>,
830 this unit can only be activated
831 or deactivated indirectly. In
832 this case, explicit start-up
833 or termination requested by the
834 user is denied, however if it is
835 started or stopped as a
836 dependency of another unit, start-up
837 or termination will succeed. This
838 is mostly a safety feature to ensure
839 that the user does not accidentally
840 activate units that are not intended
841 to be activated explicitly, and not
842 accidentally deactivate units that are
843 not intended to be deactivated.
844 These options default to
845 <option>false</option>.</para></listitem>
849 <term><varname>AllowIsolate=</varname></term>
851 <listitem><para>Takes a boolean
852 argument. If <option>true</option>,
853 this unit may be used with the
854 <command>systemctl isolate</command>
855 command. Otherwise, this will be
856 refused. It probably is a good idea to
857 leave this disabled except for target
858 units that shall be used similar to
859 runlevels in SysV init systems, just
860 as a precaution to avoid unusable
861 system states. This option defaults to
862 <option>false</option>.</para></listitem>
866 <term><varname>DefaultDependencies=</varname></term>
868 <listitem><para>Takes a boolean
869 argument. If <option>true</option>,
870 (the default), a few default
871 dependencies will implicitly be
872 created for the unit. The actual
873 dependencies created depend on the
874 unit type. For example, for service
875 units, these dependencies ensure that
876 the service is started only after
877 basic system initialization is
878 completed and is properly terminated on
879 system shutdown. See the respective
880 man pages for details. Generally, only
881 services involved with early boot or
882 late shutdown should set this option
883 to <option>false</option>. It is
884 highly recommended to leave this
885 option enabled for the majority of
886 common units. If set to
887 <option>false</option>, this option
888 does not disable all implicit
889 dependencies, just non-essential
890 ones.</para></listitem>
894 <term><varname>JobTimeoutSec=</varname></term>
895 <term><varname>JobTimeoutAction=</varname></term>
896 <term><varname>JobTimeoutRebootArgument=</varname></term>
898 <listitem><para>When a job for this
899 unit is queued a time-out may be
900 configured. If this time limit is
901 reached, the job will be cancelled,
902 the unit however will not change state
904 <literal>failed</literal> mode. This
905 value defaults to 0 (job timeouts
906 disabled), except for device
907 units. NB: this timeout is independent
908 from any unit-specific timeout (for
909 example, the timeout set with
910 <varname>StartTimeoutSec=</varname> in service
911 units) as the job timeout has no
912 effect on the unit itself, only on the
913 job that might be pending for it. Or
914 in other words: unit-specific timeouts
915 are useful to abort unit state
916 changes, and revert them. The job
917 timeout set with this option however
918 is useful to abort only the job
919 waiting for the unit state to
922 <para><varname>JobTimeoutAction=</varname>
923 optionally configures an additional
924 action to take when the time-out is
925 hit. It takes the same values as the
927 <varname>StartLimitAction=</varname>
929 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
930 for details. Defaults to
931 <option>none</option>. <varname>JobTimeoutRebootArgument=</varname>
932 configures an optional reboot string
934 <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
935 system call.</para></listitem>
939 <term><varname>ConditionArchitecture=</varname></term>
940 <term><varname>ConditionVirtualization=</varname></term>
941 <term><varname>ConditionHost=</varname></term>
942 <term><varname>ConditionKernelCommandLine=</varname></term>
943 <term><varname>ConditionSecurity=</varname></term>
944 <term><varname>ConditionCapability=</varname></term>
945 <term><varname>ConditionACPower=</varname></term>
946 <term><varname>ConditionNeedsUpdate=</varname></term>
947 <term><varname>ConditionFirstBoot=</varname></term>
948 <term><varname>ConditionPathExists=</varname></term>
949 <term><varname>ConditionPathExistsGlob=</varname></term>
950 <term><varname>ConditionPathIsDirectory=</varname></term>
951 <term><varname>ConditionPathIsSymbolicLink=</varname></term>
952 <term><varname>ConditionPathIsMountPoint=</varname></term>
953 <term><varname>ConditionPathIsReadWrite=</varname></term>
954 <term><varname>ConditionDirectoryNotEmpty=</varname></term>
955 <term><varname>ConditionFileNotEmpty=</varname></term>
956 <term><varname>ConditionFileIsExecutable=</varname></term>
958 <!-- We don't document ConditionNull=
959 here as it is not particularly
960 useful and probably just
963 <listitem><para>Before starting a unit
964 verify that the specified condition is
965 true. If it is not true, the starting
966 of the unit will be skipped, however
967 all ordering dependencies of it are
968 still respected. A failing condition
969 will not result in the unit being
970 moved into a failure state. The
971 condition is checked at the time the
972 queued start job is to be
975 <para><varname>ConditionArchitecture=</varname>
976 may be used to check whether the
977 system is running on a specific
978 architecture. Takes one of
979 <varname>x86</varname>,
980 <varname>x86-64</varname>,
981 <varname>ppc</varname>,
982 <varname>ppc-le</varname>,
983 <varname>ppc64</varname>,
984 <varname>ppc64-le</varname>,
985 <varname>ia64</varname>,
986 <varname>parisc</varname>,
987 <varname>parisc64</varname>,
988 <varname>s390</varname>,
989 <varname>s390x</varname>,
990 <varname>sparc</varname>,
991 <varname>sparc64</varname>,
992 <varname>mips</varname>,
993 <varname>mips-le</varname>,
994 <varname>mips64</varname>,
995 <varname>mips64-le</varname>,
996 <varname>alpha</varname>,
997 <varname>arm</varname>,
998 <varname>arm-be</varname>,
999 <varname>arm64</varname>,
1000 <varname>arm64-be</varname>,
1001 <varname>sh</varname>,
1002 <varname>sh64</varname>,
1003 <varname>m86k</varname>,
1004 <varname>tilegx</varname>,
1005 <varname>cris</varname> to test
1006 against a specific architecture. The
1007 architecture is determined from the
1008 information returned by
1009 <citerefentry><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
1010 and is thus subject to
1011 <citerefentry><refentrytitle>personality</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Note
1012 that a <varname>Personality=</varname>
1013 setting in the same unit file has no
1014 effect on this condition. A special
1016 <varname>native</varname> is mapped to
1017 the architecture the system manager
1018 itself is compiled for. The test may
1019 be negated by prepending an
1020 exclamation mark.</para>
1022 <para><varname>ConditionVirtualization=</varname>
1023 may be used to check whether the
1024 system is executed in a virtualized
1025 environment and optionally test
1026 whether it is a specific
1027 implementation. Takes either boolean
1028 value to check if being executed in
1029 any virtualized environment, or one of
1030 <varname>vm</varname> and
1031 <varname>container</varname> to test
1032 against a generic type of
1033 virtualization solution, or one of
1034 <varname>qemu</varname>,
1035 <varname>kvm</varname>,
1036 <varname>zvm</varname>,
1037 <varname>vmware</varname>,
1038 <varname>microsoft</varname>,
1039 <varname>oracle</varname>,
1040 <varname>xen</varname>,
1041 <varname>bochs</varname>,
1042 <varname>uml</varname>,
1043 <varname>openvz</varname>,
1044 <varname>lxc</varname>,
1045 <varname>lxc-libvirt</varname>,
1046 <varname>systemd-nspawn</varname>,
1047 <varname>docker</varname> to test
1048 against a specific implementation. See
1049 <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1050 for a full list of known
1051 virtualization technologies and their
1052 identifiers. If multiple
1053 virtualization technologies are
1054 nested, only the innermost is
1055 considered. The test may be negated by
1056 prepending an exclamation mark.</para>
1058 <para><varname>ConditionHost=</varname>
1059 may be used to match against the
1060 hostname or machine ID of the
1061 host. This either takes a hostname
1062 string (optionally with shell style
1063 globs) which is tested against the
1064 locally set hostname as returned by
1065 <citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
1066 or a machine ID formatted as string
1068 <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
1069 The test may be negated by prepending
1070 an exclamation mark.</para>
1072 <para><varname>ConditionKernelCommandLine=</varname>
1073 may be used to check whether a
1074 specific kernel command line option is
1075 set (or if prefixed with the
1076 exclamation mark unset). The argument
1077 must either be a single word, or an
1078 assignment (i.e. two words, separated
1079 <literal>=</literal>). In the former
1080 case the kernel command line is
1081 searched for the word appearing as is,
1082 or as left hand side of an
1083 assignment. In the latter case, the
1084 exact assignment is looked for with
1085 right and left hand side
1088 <para><varname>ConditionSecurity=</varname>
1089 may be used to check whether the given
1090 security module is enabled on the
1091 system. Currently the recognized
1093 <varname>selinux</varname>,
1094 <varname>apparmor</varname>,
1095 <varname>ima</varname>,
1096 <varname>smack</varname> and
1097 <varname>audit</varname>. The test may
1098 be negated by prepending an
1099 exclamation mark.</para>
1101 <para><varname>ConditionCapability=</varname>
1102 may be used to check whether the given
1103 capability exists in the capability
1104 bounding set of the service manager
1105 (i.e. this does not check whether
1106 capability is actually available in
1107 the permitted or effective sets, see
1108 <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1109 for details). Pass a capability name
1110 such as <literal>CAP_MKNOD</literal>,
1111 possibly prefixed with an exclamation
1112 mark to negate the check.</para>
1114 <para><varname>ConditionACPower=</varname>
1115 may be used to check whether the
1116 system has AC power, or is exclusively
1117 battery powered at the time of
1118 activation of the unit. This takes a
1119 boolean argument. If set to
1120 <varname>true</varname>, the condition
1121 will hold only if at least one AC
1122 connector of the system is connected
1123 to a power source, or if no AC
1124 connectors are known. Conversely, if
1125 set to <varname>false</varname>, the
1126 condition will hold only if there is
1127 at least one AC connector known and
1128 all AC connectors are disconnected
1129 from a power source.</para>
1131 <para><varname>ConditionNeedsUpdate=</varname>
1132 takes one of <filename>/var</filename>
1133 or <filename>/etc</filename> as
1134 argument, possibly prefixed with a
1135 <literal>!</literal> (for inverting
1136 the condition). This condition may be
1137 used to conditionalize units on
1138 whether the specified directory
1139 requires an update because
1140 <filename>/usr</filename>'s
1141 modification time is newer than the
1143 <filename>.updated</filename> in the
1144 specified directory. This is useful to
1145 implement offline updates of the
1146 vendor operating system resources in
1147 <filename>/usr</filename> that require
1148 updating of <filename>/etc</filename>
1149 or <filename>/var</filename> on the
1150 next following boot. Units making use
1151 of this condition should order
1153 <citerefentry><refentrytitle>systemd-update-done.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1154 to make sure they run before the stamp
1155 files's modification time gets reset
1156 indicating a completed update.</para>
1158 <para><varname>ConditionFirstBoot=</varname>
1159 takes a boolean argument. This
1160 condition may be used to
1161 conditionalize units on whether the
1162 system is booting up with an
1163 unpopulated <filename>/etc</filename>
1164 directory. This may be used to
1165 populate <filename>/etc</filename> on
1166 the first boot after factory reset, or
1167 when a new system instances boots up
1168 for the first time.</para>
1171 <varname>ConditionPathExists=</varname>
1172 a file existence condition is
1173 checked before a unit is started. If
1174 the specified absolute path name does
1175 not exist, the condition will
1176 fail. If the absolute path name passed
1178 <varname>ConditionPathExists=</varname>
1179 is prefixed with an exclamation mark
1180 (<literal>!</literal>), the test is negated, and the unit
1181 is only started if the path does not
1184 <para><varname>ConditionPathExistsGlob=</varname>
1186 <varname>ConditionPathExists=</varname>,
1187 but checks for the existence of at
1188 least one file or directory matching
1189 the specified globbing pattern.</para>
1191 <para><varname>ConditionPathIsDirectory=</varname>
1193 <varname>ConditionPathExists=</varname>
1194 but verifies whether a certain path
1198 <para><varname>ConditionPathIsSymbolicLink=</varname>
1200 <varname>ConditionPathExists=</varname>
1201 but verifies whether a certain path
1202 exists and is a symbolic
1205 <para><varname>ConditionPathIsMountPoint=</varname>
1207 <varname>ConditionPathExists=</varname>
1208 but verifies whether a certain path
1209 exists and is a mount
1212 <para><varname>ConditionPathIsReadWrite=</varname>
1214 <varname>ConditionPathExists=</varname>
1215 but verifies whether the underlying
1216 file system is readable and writable
1220 <para><varname>ConditionDirectoryNotEmpty=</varname>
1222 <varname>ConditionPathExists=</varname>
1223 but verifies whether a certain path
1224 exists and is a non-empty
1227 <para><varname>ConditionFileNotEmpty=</varname>
1229 <varname>ConditionPathExists=</varname>
1230 but verifies whether a certain path
1231 exists and refers to a regular file
1232 with a non-zero size.</para>
1234 <para><varname>ConditionFileIsExecutable=</varname>
1236 <varname>ConditionPathExists=</varname>
1237 but verifies whether a certain path
1238 exists, is a regular file and marked
1241 <para>If multiple conditions are
1242 specified, the unit will be executed if
1243 all of them apply (i.e. a logical AND
1244 is applied). Condition checks can be
1245 prefixed with a pipe symbol (|) in
1246 which case a condition becomes a
1247 triggering condition. If at least one
1248 triggering condition is defined for a
1249 unit, then the unit will be executed if
1250 at least one of the triggering
1251 conditions apply and all of the
1252 non-triggering conditions. If you
1253 prefix an argument with the pipe
1254 symbol and an exclamation mark, the
1255 pipe symbol must be passed first, the
1256 exclamation second. Except for
1257 <varname>ConditionPathIsSymbolicLink=</varname>,
1258 all path checks follow symlinks. If
1259 any of these options is assigned the
1260 empty string, the list of conditions is
1261 reset completely, all previous
1262 condition settings (of any kind) will
1263 have no effect.</para></listitem>
1267 <term><varname>AssertArchitecture=</varname></term>
1268 <term><varname>AssertVirtualization=</varname></term>
1269 <term><varname>AssertHost=</varname></term>
1270 <term><varname>AssertKernelCommandLine=</varname></term>
1271 <term><varname>AssertSecurity=</varname></term>
1272 <term><varname>AssertCapability=</varname></term>
1273 <term><varname>AssertACPower=</varname></term>
1274 <term><varname>AssertNeedsUpdate=</varname></term>
1275 <term><varname>AssertFirstBoot=</varname></term>
1276 <term><varname>AssertPathExists=</varname></term>
1277 <term><varname>AssertPathExistsGlob=</varname></term>
1278 <term><varname>AssertPathIsDirectory=</varname></term>
1279 <term><varname>AssertPathIsSymbolicLink=</varname></term>
1280 <term><varname>AssertPathIsMountPoint=</varname></term>
1281 <term><varname>AssertPathIsReadWrite=</varname></term>
1282 <term><varname>AssertDirectoryNotEmpty=</varname></term>
1283 <term><varname>AssertFileNotEmpty=</varname></term>
1284 <term><varname>AssertFileIsExecutable=</varname></term>
1286 <listitem><para>Similar to the
1287 <varname>ConditionArchitecture=</varname>,
1288 <varname>ConditionVirtualization=</varname>,
1289 ... condition settings described above
1290 these settings add assertion checks to
1291 the start-up of the unit. However,
1292 unlike the conditions settings any
1293 assertion setting that is not met
1294 results in failure of the start
1295 job it was triggered by.</para></listitem>
1299 <term><varname>SourcePath=</varname></term>
1300 <listitem><para>A path to a
1301 configuration file this unit has been
1302 generated from. This is primarily
1303 useful for implementation of generator
1304 tools that convert configuration from
1305 an external configuration file format
1306 into native unit files. This
1307 functionality should not be used in
1308 normal units.</para></listitem>
1315 <title>[Install] Section Options</title>
1317 <para>Unit file may include an
1318 <literal>[Install]</literal> section, which carries
1319 installation information for the unit. This section is
1321 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1322 during runtime. It is used exclusively by the
1323 <command>enable</command> and
1324 <command>disable</command> commands of the
1325 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1326 tool during installation of a unit:</para>
1328 <variablelist class='unit-directives'>
1330 <term><varname>Alias=</varname></term>
1332 <listitem><para>A space-separated list
1333 of additional names this unit shall be
1334 installed under. The names listed here
1335 must have the same suffix (i.e. type)
1336 as the unit file name. This option may
1337 be specified more than once, in which
1338 case all listed names are used. At
1339 installation time, <command>systemctl
1340 enable</command> will create symlinks
1341 from these names to the unit
1342 filename.</para></listitem>
1346 <term><varname>WantedBy=</varname></term>
1347 <term><varname>RequiredBy=</varname></term>
1349 <listitem><para>This option may be
1350 used more than once, or a
1351 space-separated list of unit names may
1352 be given. A symbolic link is created
1353 in the <filename>.wants/</filename> or
1354 <filename>.requires/</filename>
1355 directory of each of the listed units
1356 when this unit is installed by
1357 <command>systemctl enable</command>.
1358 This has the effect that a dependency
1359 of type <varname>Wants=</varname> or
1360 <varname>Requires=</varname> is added
1361 from the listed unit to the current
1362 unit. The primary result is that the
1363 current unit will be started when the
1364 listed unit is started. See the
1366 <varname>Wants=</varname> and
1367 <varname>Requires=</varname> in the
1368 [Unit] section for details.</para>
1370 <para><command>WantedBy=foo.service</command>
1372 <filename>bar.service</filename> is
1373 mostly equivalent to
1374 <command>Alias=foo.service.wants/bar.service</command>
1375 in the same file. In case of template
1376 units, <command>systemctl enable</command>
1377 must be called with an instance name, and
1378 this instance will be added to the
1379 <filename>.wants/</filename> or
1380 <filename>.requires/</filename> list
1382 E.g. <command>WantedBy=getty.target</command>
1384 <filename>getty@.service</filename>
1385 will result in <command>systemctl
1386 enable getty@tty2.service</command>
1388 <filename>getty.target.wants/getty@tty2.service</filename>
1389 link to <filename>getty@.service</filename>.
1394 <term><varname>Also=</varname></term>
1396 <listitem><para>Additional units to
1397 install/deinstall when this unit is
1398 installed/deinstalled. If the user
1399 requests installation/deinstallation
1400 of a unit with this option configured,
1401 <command>systemctl enable</command>
1402 and <command>systemctl
1403 disable</command> will automatically
1404 install/uninstall units listed in this option as
1407 <para>This option may be used more
1408 than once, or a space-separated list
1409 of unit names may be
1410 given.</para></listitem>
1414 <term><varname>DefaultInstance=</varname></term>
1416 <listitem><para>In template unit files,
1417 this specifies for which instance the
1418 unit shall be enabled if the template
1419 is enabled without any explicitly set
1420 instance. This option has no effect in
1421 non-template unit files. The specified
1422 string must be usable as instance
1423 identifier.</para></listitem>
1427 <para>The following specifiers are interpreted in the
1428 Install section: %n, %N, %p, %i, %U, %u, %m, %H, %b, %v.
1429 For their meaning see the next section.
1434 <title>Specifiers</title>
1436 <para>Many settings resolve specifiers which may be
1437 used to write generic unit files referring to runtime
1438 or unit parameters that are replaced when the unit
1439 files are loaded. The following specifiers are
1443 <title>Specifiers available in unit files</title>
1444 <tgroup cols='3' align='left' colsep='1' rowsep='1'>
1445 <colspec colname="spec" />
1446 <colspec colname="mean" />
1447 <colspec colname="detail" />
1450 <entry>Specifier</entry>
1451 <entry>Meaning</entry>
1452 <entry>Details</entry>
1457 <entry><literal>%n</literal></entry>
1458 <entry>Full unit name</entry>
1462 <entry><literal>%N</literal></entry>
1463 <entry>Unescaped full unit name</entry>
1464 <entry>Same as <literal>%n</literal>, but with escaping undone</entry>
1467 <entry><literal>%p</literal></entry>
1468 <entry>Prefix name</entry>
1469 <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>
1472 <entry><literal>%P</literal></entry>
1473 <entry>Unescaped prefix name</entry>
1474 <entry>Same as <literal>%p</literal>, but with escaping undone</entry>
1477 <entry><literal>%i</literal></entry>
1478 <entry>Instance name</entry>
1479 <entry>For instantiated units: this is the string between the <literal>@</literal> character and the suffix of the unit name.</entry>
1482 <entry><literal>%I</literal></entry>
1483 <entry>Unescaped instance name</entry>
1484 <entry>Same as <literal>%i</literal>, but with escaping undone</entry>
1487 <entry><literal>%f</literal></entry>
1488 <entry>Unescaped filename</entry>
1489 <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>
1492 <entry><literal>%c</literal></entry>
1493 <entry>Control group path of the unit</entry>
1494 <entry>This path does not include the <filename>/sys/fs/cgroup/systemd/</filename> prefix.</entry>
1497 <entry><literal>%r</literal></entry>
1498 <entry>Control group path of the slice the unit is placed in</entry>
1499 <entry>This usually maps to the parent cgroup path of <literal>%c</literal>.</entry>
1502 <entry><literal>%R</literal></entry>
1503 <entry>Root control group path below which slices and units are placed</entry>
1504 <entry>For system instances, this resolves to <filename>/</filename>, except in containers, where this maps to the container's root control group path.</entry>
1507 <entry><literal>%t</literal></entry>
1508 <entry>Runtime directory</entry>
1509 <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>
1512 <entry><literal>%u</literal></entry>
1513 <entry>User name</entry>
1514 <entry>This is the name of the configured user of the unit, or (if none is set) the user running the systemd instance.</entry>
1517 <entry><literal>%U</literal></entry>
1518 <entry>User UID</entry>
1519 <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>
1522 <entry><literal>%h</literal></entry>
1523 <entry>User home directory</entry>
1524 <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>
1527 <entry><literal>%s</literal></entry>
1528 <entry>User shell</entry>
1529 <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>
1532 <entry><literal>%m</literal></entry>
1533 <entry>Machine ID</entry>
1534 <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>
1537 <entry><literal>%b</literal></entry>
1538 <entry>Boot ID</entry>
1539 <entry>The boot ID of the running system, formatted as string. See <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for more information.</entry>
1542 <entry><literal>%H</literal></entry>
1543 <entry>Host name</entry>
1544 <entry>The hostname of the running system at the point in time the unit configuation is loaded.</entry>
1547 <entry><literal>%v</literal></entry>
1548 <entry>Kernel release</entry>
1549 <entry>Identical to <command>uname -r</command> output</entry>
1552 <entry><literal>%%</literal></entry>
1553 <entry>Single percent sign</entry>
1554 <entry>Use <literal>%%</literal> in place of <literal>%</literal> to specify a single percent sign.</entry>
1562 <title>See Also</title>
1564 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1565 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1566 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1567 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1568 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1569 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1570 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1571 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1572 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1573 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1574 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1575 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1576 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1577 <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1578 <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1579 <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1580 <citerefentry><refentrytitle>systemd-verify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1581 <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1582 <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1583 <citerefentry><refentrytitle>uname</refentrytitle><manvolnum>1</manvolnum></citerefentry>