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">
6 This file is part of systemd.
8 Copyright 2010 Lennart Poettering
10 systemd is free software; you can redistribute it and/or modify it
11 under the terms of the GNU Lesser General Public License as published by
12 the Free Software Foundation; either version 2.1 of the License, or
13 (at your option) any later version.
15 systemd is distributed in the hope that it will be useful, but
16 WITHOUT ANY WARRANTY; without even the implied warranty of
17 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
18 Lesser General Public License for more details.
20 You should have received a copy of the GNU Lesser General Public License
21 along with systemd; If not, see <http://www.gnu.org/licenses/>.
24 <refentry id="systemd.unit">
27 <title>systemd.unit</title>
28 <productname>systemd</productname>
32 <contrib>Developer</contrib>
33 <firstname>Lennart</firstname>
34 <surname>Poettering</surname>
35 <email>lennart@poettering.net</email>
41 <refentrytitle>systemd.unit</refentrytitle>
42 <manvolnum>5</manvolnum>
46 <refname>systemd.unit</refname>
47 <refpurpose>Unit configuration</refpurpose>
51 <para><filename>systemd.service</filename>,
52 <filename>systemd.socket</filename>,
53 <filename>systemd.device</filename>,
54 <filename>systemd.mount</filename>,
55 <filename>systemd.automount</filename>,
56 <filename>systemd.swap</filename>,
57 <filename>systemd.target</filename>,
58 <filename>systemd.path</filename>,
59 <filename>systemd.timer</filename>,
60 <filename>systemd.snapshot</filename></para>
64 <title>Description</title>
66 <para>A unit configuration file encodes information
67 about a service, a socket, a device, a mount point, an
68 automount point, a swap file or partition, a start-up
69 target, a file system path or a timer controlled and
71 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>. The
72 syntax is inspired by <ulink
73 url="http://standards.freedesktop.org/desktop-entry-spec/latest/">XDG
74 Desktop Entry Specification</ulink> <filename>.desktop</filename> files, which are in turn
75 inspired by Microsoft Windows
76 <filename>.ini</filename> files.</para>
78 <para>This man page lists the common configuration
79 options of all the unit types. These options need to
80 be configured in the [Unit] or [Install]
81 sections of the unit files.</para>
83 <para>In addition to the generic [Unit] and [Install]
84 sections described here, each unit should have a
85 type-specific section, e.g. [Service] for a service
86 unit. See the respective man pages for more
89 <para>Unit files may contain additional options on top
90 of those listed here. If systemd encounters an unknown
91 option it will write a warning log message but
92 continue loading the unit. If an option is prefixed
93 with <option>X-</option> it is ignored completely by
94 systemd. Applications may use this to include
95 additional information in the unit files.</para>
97 <para>Boolean arguments used in unit files can be
98 written in various formats. For positive settings the
99 strings <option>1</option>, <option>yes</option>,
100 <option>true</option> and <option>on</option> are
101 equivalent. For negative settings the strings
102 <option>0</option>, <option>no</option>,
103 <option>false</option> and <option>off</option> are
106 <para>Time span values encoded in unit files can be
107 written in various formats. A stand-alone number
108 specifies a time in seconds. If suffixed with a time
109 unit, the unit is honored. A concatenation of
110 multiple values with units is supported, in which case
111 the values are added up. Example: "50" refers to 50
112 seconds; "2min 200ms" refers to 2 minutes plus 200
113 milliseconds, i.e. 120200ms. The following time units
114 are understood: s, min, h, d, w, ms, us.</para>
116 <para>Empty lines and lines starting with # or ; are
117 ignored. This may be used for commenting. Lines ending
118 in a backslash are concatenated with the following
119 line while reading and the backslash is replaced by a
120 space character. This may be used to wrap long lines.</para>
122 <para>If a line starts with <option>.include</option>
123 followed by a file name, the specified file will be
124 parsed at this point. Make sure that the file that is
125 included has the appropriate section headers before
126 any directives.</para>
128 <para>Along with a unit file
129 <filename>foo.service</filename> a directory
130 <filename>foo.service.wants/</filename> may exist. All
131 units symlinked from such a directory are implicitly
132 added as dependencies of type
133 <varname>Wanted=</varname> to the unit. This is useful
134 to hook units into the start-up of other units,
135 without having to modify their unit configuration
136 files. For details about the semantics of
137 <varname>Wanted=</varname> see below. The preferred
138 way to create symlinks in the
139 <filename>.wants/</filename> directory of a service is
140 with the <command>enable</command> command of the
141 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
142 tool which reads information from the [Install]
143 section of unit files. (See below.) A similar
144 functionality exists for <varname>Requires=</varname>
145 type dependencies as well, the directory suffix is
146 <filename>.requires/</filename> in this case.</para>
148 <para>Note that while systemd offers a flexible
149 dependency system between units it is recommended to
150 use this functionality only sparsely and instead rely
151 on techniques such as bus-based or socket-based
152 activation which makes dependencies implicit, which
153 both results in a simpler and more flexible
156 <para>Some unit names reflect paths existing in the
157 file system name space. Example: a device unit
158 <filename>dev-sda.device</filename> refers to a device
159 with the device node <filename>/dev/sda</filename> in
160 the file system namespace. If this applies a special
161 way to escape the path name is used, so that the
162 result is usable as part of a file name. Basically,
163 given a path, "/" is replaced by "-", and all
164 unprintable characters and the "-" are replaced by
165 C-style "\x20" escapes. The root directory "/" is
166 encoded as single dash, while otherwise the initial
167 and ending "/" is removed from all paths during
168 transformation. This escaping is reversible.</para>
170 <para>Optionally, units may be instantiated from a
171 template file at runtime. This allows creation of
172 multiple units from a single configuration file. If
173 systemd looks for a unit configuration file it will
174 first search for the literal unit name in the
175 filesystem. If that yields no success and the unit
176 name contains an @ character, systemd will look for a
177 unit template that shares the same name but with the
178 instance string (i.e. the part between the @ character
179 and the suffix) removed. Example: if a service
180 <filename>getty@tty3.service</filename> is requested
181 and no file by that name is found, systemd will look
182 for <filename>getty@.service</filename> and
183 instantiate a service from that configuration file if
186 <para>To refer to the instance string from
187 within the configuration file you may use the special
188 <literal>%i</literal> specifier in many of the
189 configuration options. Other specifiers exist, the
193 <title>Specifiers available in unit files</title>
194 <tgroup cols='3' align='left' colsep='1' rowsep='1'>
195 <colspec colname="spec" />
196 <colspec colname="mean" />
197 <colspec colname="detail" />
200 <entry>Specifier</entry>
201 <entry>Meaning</entry>
202 <entry>Details</entry>
207 <entry><literal>%n</literal></entry>
208 <entry>Full unit name</entry>
212 <entry><literal>%N</literal></entry>
213 <entry>Unescaped full unit name</entry>
217 <entry><literal>%p</literal></entry>
218 <entry>Prefix name</entry>
219 <entry>This refers to the string before the @, i.e. "getty" in the example above, where "tty3" is the instance name.</entry>
222 <entry><literal>%P</literal></entry>
223 <entry>Unescaped prefix name</entry>
227 <entry><literal>%i</literal></entry>
228 <entry>Instance name</entry>
229 <entry>This is the string between the @ character and the suffix.</entry>
232 <entry><literal>%I</literal></entry>
233 <entry>Unescaped instance name</entry>
237 <entry><literal>%f</literal></entry>
238 <entry>Unescaped file name</entry>
239 <entry>This is either the unescaped instance name (if set) with / prepended (if necessary), or the prefix name similarly prepended with /.</entry>
242 <entry><literal>%c</literal></entry>
243 <entry>Control group path of the unit</entry>
247 <entry><literal>%r</literal></entry>
248 <entry>Root control group path of systemd</entry>
252 <entry><literal>%R</literal></entry>
253 <entry>Parent directory of the root control group path of systemd</entry>
257 <entry><literal>%t</literal></entry>
258 <entry>Runtime socket dir</entry>
259 <entry>This is either /run (for the system manager) or $XDG_RUNTIME_DIR (for user managers).</entry>
262 <entry><literal>%u</literal></entry>
263 <entry>User name</entry>
264 <entry>This is the name of the configured user of the unit, or (if none is set) the user running the systemd instance.</entry>
267 <entry><literal>%h</literal></entry>
268 <entry>User home directory</entry>
269 <entry>This is the home directory of the configured user of the unit, or (if none is set) the user running the systemd instance.</entry>
272 <entry><literal>%s</literal></entry>
273 <entry>User shell</entry>
274 <entry>This is the shell of the configured user of the unit, or (if none is set) the user running the systemd instance.</entry>
277 <entry><literal>%m</literal></entry>
278 <entry>Machine ID</entry>
279 <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>
282 <entry><literal>%b</literal></entry>
283 <entry>Boot ID</entry>
284 <entry>The boot ID of the running system, formatted as string. See <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for more information.</entry>
287 <entry><literal>%H</literal></entry>
288 <entry>Host name</entry>
289 <entry>The host name of the running system.</entry>
295 <para>If a unit file is empty (i.e. has the file size
296 0) or is symlinked to <filename>/dev/null</filename>
297 its configuration will not be loaded and it appears
298 with a load state of <literal>masked</literal>, and
299 cannot be activated. Use this as an effective way to
300 fully disable a unit, making it impossible to start it
301 even manually.</para>
303 <para>The unit file format is covered by the
305 url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
306 Stability Promise</ulink>.</para>
310 <title>Options</title>
312 <para>Unit file may include a [Unit] section, which
313 carries generic information about the unit that is not
314 dependent on the type of unit:</para>
319 <term><varname>Description=</varname></term>
320 <listitem><para>A free-form string
321 describing the unit. This is intended
322 for use in UIs to show descriptive
323 information along with the unit
324 name.</para></listitem>
328 <term><varname>Documentation=</varname></term>
329 <listitem><para>A space separated list
330 of URIs referencing documentation for
332 configuration. Accepted are only URIs
334 <literal>http://</literal>,
335 <literal>https://</literal>,
336 <literal>file:</literal>,
337 <literal>info:</literal>,
338 <literal>man:</literal>. For more
339 information about the syntax of these
341 <citerefentry><refentrytitle>uri</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
342 URIs should be listed in order of
343 relevance, starting with the most
344 relevant. It is a good idea to first
345 reference documentation that explains
346 what the unit's purpose is, followed
347 by how it is configured, followed by
349 documentation.</para></listitem>
353 <term><varname>Requires=</varname></term>
355 <listitem><para>Configures requirement
356 dependencies on other units. If this
357 unit gets activated, the units listed
358 here will be activated as well. If one
359 of the other units gets deactivated or
360 its activation fails, this unit will
361 be deactivated. This option may be
362 specified more than once, in which
363 case requirement dependencies for all
364 listed names are created. Note that
365 requirement dependencies do not
366 influence the order in which services
367 are started or stopped. This has to be
368 configured independently with the
369 <varname>After=</varname> or
370 <varname>Before=</varname> options. If
372 <filename>foo.service</filename>
374 <filename>bar.service</filename> as
376 <varname>Requires=</varname> and no
377 ordering is configured with
378 <varname>After=</varname> or
379 <varname>Before=</varname>, then both
380 units will be started simultaneously
381 and without any delay between them if
382 <filename>foo.service</filename> is
383 activated. Often it is a better choice
384 to use <varname>Wants=</varname>
386 <varname>Requires=</varname> in order
387 to achieve a system that is more
388 robust when dealing with failing
391 <para>Note that dependencies of this
392 type may also be configured outside of
393 the unit configuration file by
394 adding a symlink to a
395 <filename>.requires/</filename> directory
396 accompanying the unit file. For
397 details see above.</para></listitem>
401 <term><varname>RequiresOverridable=</varname></term>
403 <listitem><para>Similar to
404 <varname>Requires=</varname>.
405 Dependencies listed in
406 <varname>RequiresOverridable=</varname>
407 which cannot be fulfilled or fail to
408 start are ignored if the startup was
409 explicitly requested by the user. If
410 the start-up was pulled in indirectly
411 by some dependency or automatic
412 start-up of units that is not
413 requested by the user this dependency
414 must be fulfilled and otherwise the
415 transaction fails. Hence, this option
416 may be used to configure dependencies
417 that are normally honored unless the
418 user explicitly starts up the unit, in
419 which case whether they failed or not
420 is irrelevant.</para></listitem>
424 <term><varname>Requisite=</varname></term>
425 <term><varname>RequisiteOverridable=</varname></term>
427 <listitem><para>Similar to
428 <varname>Requires=</varname>
429 and <varname>RequiresOverridable=</varname>, respectively. However,
430 if a unit listed here is not started
431 already it will not be started and the
433 immediately.</para></listitem>
437 <term><varname>Wants=</varname></term>
439 <listitem><para>A weaker version of
440 <varname>Requires=</varname>. A unit
441 listed in this option will be started
442 if the configuring unit is. However,
443 if the listed unit fails to start up
444 or cannot be added to the transaction
445 this has no impact on the validity of
446 the transaction as a whole. This is
447 the recommended way to hook start-up
448 of one unit to the start-up of another
451 <para>Note that dependencies of this
452 type may also be configured outside of
453 the unit configuration file by
454 adding a symlink to a
455 <filename>.wants/</filename> directory
456 accompanying the unit file. For
457 details see above.</para></listitem>
461 <term><varname>BindsTo=</varname></term>
463 <listitem><para>Configures requirement
464 dependencies, very similar in style to
465 <varname>Requires=</varname>, however
466 in addition to this behavior it also
467 declares that this unit is stopped
468 when any of the units listed suddenly
469 disappears. Units can suddenly,
470 unexpectedly disappear if a service
471 terminates on its own choice, a device
472 is unplugged or a mount point
473 unmounted without involvement of
474 systemd.</para></listitem>
478 <term><varname>PartOf=</varname></term>
480 <listitem><para>Configures dependencies
481 similar to <varname>Requires=</varname>,
482 but limited to stopping and restarting
483 of units. When systemd stops or restarts
484 the units listed here, the action is
485 propagated to this unit.
486 Note that this is a one way dependency -
487 changes to this unit do not affect the
493 <term><varname>Conflicts=</varname></term>
495 <listitem><para>Configures negative
496 requirement dependencies. If a unit
498 <varname>Conflicts=</varname> setting
499 on another unit, starting the former
500 will stop the latter and vice
501 versa. Note that this setting is
502 independent of and orthogonal to the
503 <varname>After=</varname> and
504 <varname>Before=</varname> ordering
507 <para>If a unit A that conflicts with
508 a unit B is scheduled to be started at
509 the same time as B, the transaction
510 will either fail (in case both are
511 required part of the transaction) or
512 be modified to be fixed (in case one
513 or both jobs are not a required part
514 of the transaction). In the latter
515 case the job that is not the required
516 will be removed, or in case both are
517 not required the unit that conflicts
518 will be started and the unit that is
520 stopped.</para></listitem>
524 <term><varname>Before=</varname></term>
525 <term><varname>After=</varname></term>
527 <listitem><para>Configures ordering
528 dependencies between units. If a unit
529 <filename>foo.service</filename>
531 <option>Before=bar.service</option>
532 and both units are being started,
533 <filename>bar.service</filename>'s
534 start-up is delayed until
535 <filename>foo.service</filename> is
536 started up. Note that this setting is
537 independent of and orthogonal to the
538 requirement dependencies as configured
539 by <varname>Requires=</varname>. It is
540 a common pattern to include a unit
542 <varname>After=</varname> and
543 <varname>Requires=</varname> option in
544 which case the unit listed will be
545 started before the unit that is
546 configured with these options. This
547 option may be specified more than
548 once, in which case ordering
549 dependencies for all listed names are
550 created. <varname>After=</varname> is
552 <varname>Before=</varname>, i.e. while
553 <varname>After=</varname> ensures that
554 the configured unit is started after
555 the listed unit finished starting up,
556 <varname>Before=</varname> ensures the
557 opposite, i.e. that the configured
558 unit is fully started up before the
559 listed unit is started. Note that when
560 two units with an ordering dependency
561 between them are shut down, the
562 inverse of the start-up order is
563 applied. i.e. if a unit is configured
564 with <varname>After=</varname> on
565 another unit, the former is stopped
566 before the latter if both are shut
567 down. If one unit with an ordering
568 dependency on another unit is shut
569 down while the latter is started up,
570 the shut down is ordered before the
571 start-up regardless whether the
572 ordering dependency is actually of
573 type <varname>After=</varname> or
574 <varname>Before=</varname>. If two
575 units have no ordering dependencies
576 between them they are shut down
577 or started up simultaneously, and
579 place. </para></listitem>
583 <term><varname>OnFailure=</varname></term>
585 <listitem><para>Lists one or more
586 units that are activated when this
588 '<literal>failed</literal>'
589 state.</para></listitem>
593 <term><varname>PropagatesReloadTo=</varname></term>
594 <term><varname>ReloadPropagatedFrom=</varname></term>
596 <listitem><para>Lists one or more
597 units where reload requests on the
598 unit will be propagated to/on the
599 other unit will be propagated
600 from. Issuing a reload request on a
601 unit will automatically also enqueue a
602 reload request on all units that the
603 reload request shall be propagated to
605 settings.</para></listitem>
609 <term><varname>RequiresMountsFor=</varname></term>
611 <listitem><para>Takes a space
612 separated list of absolute paths. Automatically
613 adds dependencies of type
614 <varname>Requires=</varname> and
615 <varname>After=</varname> for all
616 mount units required to access the
617 specified path.</para></listitem>
621 <term><varname>OnFailureIsolate=</varname></term>
623 <listitem><para>Takes a boolean
624 argument. If <option>true</option> the
626 <varname>OnFailure=</varname> will be
627 enqueued in isolation mode, i.e. all
628 units that are not its dependency will
629 be stopped. If this is set only a
630 single unit may be listed in
631 <varname>OnFailure=</varname>. Defaults
633 <option>false</option>.</para></listitem>
637 <term><varname>IgnoreOnIsolate=</varname></term>
639 <listitem><para>Takes a boolean
640 argument. If <option>true</option>
641 this unit will not be stopped when
642 isolating another unit. Defaults to
643 <option>false</option>.</para></listitem>
647 <term><varname>IgnoreOnSnapshot=</varname></term>
649 <listitem><para>Takes a boolean
650 argument. If <option>true</option>
651 this unit will not be included in
652 snapshots. Defaults to
653 <option>true</option> for device and
654 snapshot units, <option>false</option>
655 for the others.</para></listitem>
659 <term><varname>StopWhenUnneeded=</varname></term>
661 <listitem><para>Takes a boolean
662 argument. If <option>true</option>
663 this unit will be stopped when it is
664 no longer used. Note that in order to
665 minimize the work to be executed,
666 systemd will not stop units by default
667 unless they are conflicting with other
668 units, or the user explicitly
669 requested their shut down. If this
670 option is set, a unit will be
671 automatically cleaned up if no other
672 active unit requires it. Defaults to
673 <option>false</option>.</para></listitem>
677 <term><varname>RefuseManualStart=</varname></term>
678 <term><varname>RefuseManualStop=</varname></term>
680 <listitem><para>Takes a boolean
681 argument. If <option>true</option>
682 this unit can only be activated
683 or deactivated indirectly. In
684 this case explicit start-up
685 or termination requested by the
686 user is denied, however if it is
687 started or stopped as a
688 dependency of another unit, start-up
689 or termination will succeed. This
690 is mostly a safety feature to ensure
691 that the user does not accidentally
692 activate units that are not intended
693 to be activated explicitly, and not
694 accidentally deactivate units that are
695 not intended to be deactivated.
696 These options default to
697 <option>false</option>.</para></listitem>
701 <term><varname>AllowIsolate=</varname></term>
703 <listitem><para>Takes a boolean
704 argument. If <option>true</option>
705 this unit may be used with the
706 <command>systemctl isolate</command>
707 command. Otherwise this will be
708 refused. It probably is a good idea to
709 leave this disabled except for target
710 units that shall be used similar to
711 runlevels in SysV init systems, just
712 as a precaution to avoid unusable
713 system states. This option defaults to
714 <option>false</option>.</para></listitem>
718 <term><varname>DefaultDependencies=</varname></term>
720 <listitem><para>Takes a boolean
721 argument. If <option>true</option>
722 (the default), a few default
723 dependencies will implicitly be
724 created for the unit. The actual
725 dependencies created depend on the
726 unit type. For example, for service
727 units, these dependencies ensure that
728 the service is started only after
729 basic system initialization is
730 completed and is properly terminated on
731 system shutdown. See the respective
732 man pages for details. Generally, only
733 services involved with early boot or
734 late shutdown should set this option
735 to <option>false</option>. It is
736 highly recommended to leave this
737 option enabled for the majority of
738 common units. If set to
739 <option>false</option> this option
740 does not disable all implicit
741 dependencies, just non-essential
742 ones.</para></listitem>
746 <term><varname>JobTimeoutSec=</varname></term>
748 <listitem><para>When clients are
749 waiting for a job of this unit to
750 complete, time out after the specified
751 time. If this time limit is reached
752 the job will be cancelled, the unit
753 however will not change state or even
754 enter the '<literal>failed</literal>'
755 mode. This value defaults to 0 (job
756 timeouts disabled), except for device
757 units. NB: this timeout is independent
758 from any unit-specific timeout (for
759 example, the timeout set with
760 <varname>Timeout=</varname> in service
761 units) as the job timeout has no
762 effect on the unit itself, only on the
763 job that might be pending for it. Or
764 in other words: unit-specific timeouts
765 are useful to abort unit state
766 changes, and revert them. The job
767 timeout set with this option however
768 is useful to abort only the job
769 waiting for the unit state to
770 change.</para></listitem>
774 <term><varname>ConditionPathExists=</varname></term>
775 <term><varname>ConditionPathExistsGlob=</varname></term>
776 <term><varname>ConditionPathIsDirectory=</varname></term>
777 <term><varname>ConditionPathIsSymbolicLink=</varname></term>
778 <term><varname>ConditionPathIsMountPoint=</varname></term>
779 <term><varname>ConditionPathIsReadWrite=</varname></term>
780 <term><varname>ConditionDirectoryNotEmpty=</varname></term>
781 <term><varname>ConditionFileNotEmpty=</varname></term>
782 <term><varname>ConditionFileIsExecutable=</varname></term>
783 <term><varname>ConditionKernelCommandLine=</varname></term>
784 <term><varname>ConditionVirtualization=</varname></term>
785 <term><varname>ConditionSecurity=</varname></term>
786 <term><varname>ConditionCapability=</varname></term>
787 <term><varname>ConditionHost=</varname></term>
788 <term><varname>ConditionNull=</varname></term>
790 <listitem><para>Before starting a unit
791 verify that the specified condition is
792 true. If it is not true the starting
793 of the unit will be skipped, however
794 all ordering dependencies of it are
795 still respected. A failing condition
796 will not result in the unit being
797 moved into a failure state. The
798 condition is checked at the time the
799 queued start job is to be
803 <varname>ConditionPathExists=</varname>
804 a file existence condition is
805 checked before a unit is started. If
806 the specified absolute path name does
807 not exist the condition will
808 fail. If the absolute path name passed
810 <varname>ConditionPathExists=</varname>
811 is prefixed with an exclamation mark
812 ('!'), the test is negated, and the unit
813 is only started if the path does not
816 <para><varname>ConditionPathExistsGlob=</varname>
818 <varname>ConditionPathExists=</varname>,
819 but checks for the existence of at
820 least one file or directory matching
821 the specified globbing pattern.</para>
823 <para><varname>ConditionPathIsDirectory=</varname>
825 <varname>ConditionPathExists=</varname>
826 but verifies whether a certain path
830 <para><varname>ConditionPathIsSymbolicLink=</varname>
832 <varname>ConditionPathExists=</varname>
833 but verifies whether a certain path
834 exists and is a symbolic
837 <para><varname>ConditionPathIsMountPoint=</varname>
839 <varname>ConditionPathExists=</varname>
840 but verifies whether a certain path
841 exists and is a mount
844 <para><varname>ConditionPathIsReadWrite=</varname>
846 <varname>ConditionPathExists=</varname>
847 but verifies whether the underlying
848 file system is readable and writable
852 <para><varname>ConditionDirectoryNotEmpty=</varname>
854 <varname>ConditionPathExists=</varname>
855 but verifies whether a certain path
856 exists and is a non-empty
859 <para><varname>ConditionFileNotEmpty=</varname>
861 <varname>ConditionPathExists=</varname>
862 but verifies whether a certain path
863 exists and refers to a regular file
864 with a non-zero size.</para>
866 <para><varname>ConditionFileIsExecutable=</varname>
868 <varname>ConditionPathExists=</varname>
869 but verifies whether a certain path
870 exists, is a regular file and marked
874 <varname>ConditionKernelCommandLine=</varname>
875 may be used to check whether a
876 specific kernel command line option is
877 set (or if prefixed with the
878 exclamation mark unset). The argument
879 must either be a single word, or an
880 assignment (i.e. two words, separated
882 case the kernel command line is
883 searched for the word appearing as is,
884 or as left hand side of an
885 assignment. In the latter case the
886 exact assignment is looked for with
887 right and left hand side
890 <para><varname>ConditionVirtualization=</varname>
891 may be used to check whether the
892 system is executed in a virtualized
893 environment and optionally test
894 whether it is a specific
895 implementation. Takes either boolean
896 value to check if being executed in
897 any virtualized environment, or one of
898 <varname>vm</varname> and
899 <varname>container</varname> to test
900 against a generic type of
901 virtualization solution, or one of
902 <varname>qemu</varname>,
903 <varname>kvm</varname>,
904 <varname>vmware</varname>,
905 <varname>microsoft</varname>,
906 <varname>oracle</varname>,
907 <varname>xen</varname>,
908 <varname>bochs</varname>,
909 <varname>chroot</varname>,
910 <varname>openvz</varname>,
911 <varname>lxc</varname>,
912 <varname>lxc-libvirt</varname>,
913 <varname>systemd-nspawn</varname> to
914 test against a specific
915 implementation. If multiple
916 virtualization technologies are nested
917 only the innermost is considered. The
918 test may be negated by prepending an
919 exclamation mark.</para>
921 <para><varname>ConditionSecurity=</varname>
922 may be used to check whether the given
923 security module is enabled on the
924 system. Currently the only recognized
925 value is <varname>selinux</varname>.
926 The test may be negated by prepending
930 <para><varname>ConditionCapability=</varname>
931 may be used to check whether the given
932 capability exists in the capability
933 bounding set of the service manager
934 (i.e. this does not check whether
935 capability is actually available in
936 the permitted or effective sets, see
937 <citerefentry><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
938 for details). Pass a capability name
939 such as <literal>CAP_MKNOD</literal>,
940 possibly prefixed with an exclamation
941 mark to negate the check.</para>
943 <para><varname>ConditionHost=</varname>
944 may be used to match against the
945 host name or machine ID of the
946 host. This either takes a host name
947 string (optionally with shell style
948 globs) which is tested against the
949 locally set host name as returned by
950 <citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
951 or a machine ID formatted as string
953 <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
954 The test may be negated by prepending
955 an exclamation mark.</para>
958 <varname>ConditionNull=</varname> may
959 be used to add a constant condition
960 check value to the unit. It takes a
961 boolean argument. If set to
962 <varname>false</varname> the condition
963 will always fail, otherwise
966 <para>If multiple conditions are
967 specified the unit will be executed if
968 all of them apply (i.e. a logical AND
969 is applied). Condition checks can be
970 prefixed with a pipe symbol (|) in
971 which case a condition becomes a
972 triggering condition. If at least one
973 triggering condition is defined for a
974 unit then the unit will be executed if
975 at least one of the triggering
976 conditions apply and all of the
977 non-triggering conditions. If you
978 prefix an argument with the pipe
979 symbol and an exclamation mark the
980 pipe symbol must be passed first, the
981 exclamation second. Except for
982 <varname>ConditionPathIsSymbolicLink=</varname>,
983 all path checks follow
984 symlinks.</para></listitem>
988 <term><varname>SourcePath=</varname></term>
989 <listitem><para>A path to a
990 configuration file this unit has been
991 generated from. This is primarily
992 useful for implementation of generator
993 tools that convert configuration from
994 an external configuration file format
995 into native unit files. Thus
996 functionality should not be used in
997 normal units.</para></listitem>
1001 <para>Unit file may include a [Install] section, which
1002 carries installation information for the unit. This
1003 section is not interpreted by
1004 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1005 during runtime. It is used exclusively by the
1006 <command>enable</command> and
1007 <command>disable</command> commands of the
1008 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1009 tool during installation of a unit:</para>
1013 <term><varname>Alias=</varname></term>
1015 <listitem><para>Additional names this
1016 unit shall be installed under. The
1017 names listed here must have the same
1018 suffix (i.e. type) as the unit file
1019 name. This option may be specified
1020 more than once, in which case all
1021 listed names are used. At installation
1023 <command>systemctl enable</command>
1024 will create symlinks from these names
1025 to the unit file name.</para></listitem>
1029 <term><varname>WantedBy=</varname></term>
1030 <term><varname>RequiredBy=</varname></term>
1032 <listitem><para>Installs a symlink in
1033 the <filename>.wants/</filename>
1034 or <filename>.requires/</filename>
1035 subdirectory for a unit, respectively. This has the
1036 effect that when the listed unit name
1037 is activated the unit listing it is
1039 too. <command>WantedBy=foo.service</command>
1041 <filename>bar.service</filename> is
1042 mostly equivalent to
1043 <command>Alias=foo.service.wants/bar.service</command>
1044 in the same file.</para></listitem>
1048 <term><varname>Also=</varname></term>
1050 <listitem><para>Additional units to
1051 install when this unit is
1052 installed. If the user requests
1053 installation of a unit with this
1055 <command>systemctl enable</command>
1056 will automatically install units
1057 listed in this option as
1058 well.</para></listitem>
1065 <title>See Also</title>
1067 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1068 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1069 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1070 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1071 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1072 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1073 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1074 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1075 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1076 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1077 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1078 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1079 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1080 <citerefentry><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>