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 pages lists the common configuration
79 options of all the unit types. These options need to
80 be configured in the [Unit] resp. [Install]
81 section 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>
280 <para>If a unit file is empty (i.e. has the file size
281 0) or is symlinked to <filename>/dev/null</filename>
282 its configuration will not be loaded and it appears
283 with a load state of <literal>masked</literal>, and
284 cannot be activated. Use this as an effective way to
285 fully disable a unit, making it impossible to start it
286 even manually.</para>
288 <para>The unit file format is covered by the
290 url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
291 Stability Promise</ulink>.</para>
295 <title>Options</title>
297 <para>Unit file may include a [Unit] section, which
298 carries generic information about the unit that is not
299 dependent on the type of unit:</para>
304 <term><varname>Description=</varname></term>
305 <listitem><para>A free-form string
306 describing the unit. This is intended
307 for use in UIs to show descriptive
308 information along with the unit
309 name.</para></listitem>
313 <term><varname>Documentation=</varname></term>
314 <listitem><para>A space separated list
315 of URIs referencing documentation for
317 configuration. Accepted are only URIs
319 <literal>http://</literal>,
320 <literal>https://</literal>,
321 <literal>file:</literal>,
322 <literal>info:</literal>,
323 <literal>man:</literal>. For more
324 information about the syntax of these
326 <citerefentry><refentrytitle>uri</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
330 <term><varname>Requires=</varname></term>
332 <listitem><para>Configures requirement
333 dependencies on other units. If this
334 unit gets activated, the units listed
335 here will be activated as well. If one
336 of the other units gets deactivated or
337 its activation fails, this unit will
338 be deactivated. This option may be
339 specified more than once, in which
340 case requirement dependencies for all
341 listed names are created. Note that
342 requirement dependencies do not
343 influence the order in which services
344 are started or stopped. This has to be
345 configured independently with the
346 <varname>After=</varname> or
347 <varname>Before=</varname> options. If
349 <filename>foo.service</filename>
351 <filename>bar.service</filename> as
353 <varname>Requires=</varname> and no
354 ordering is configured with
355 <varname>After=</varname> or
356 <varname>Before=</varname>, then both
357 units will be started simultaneously
358 and without any delay between them if
359 <filename>foo.service</filename> is
360 activated. Often it is a better choice
361 to use <varname>Wants=</varname>
363 <varname>Requires=</varname> in order
364 to achieve a system that is more
365 robust when dealing with failing
368 <para>Note that dependencies of this
369 type may also be configured outside of
370 the unit configuration file by
371 adding a symlink to a
372 <filename>.requires/</filename> directory
373 accompanying the unit file. For
374 details see above.</para></listitem>
378 <term><varname>RequiresOverridable=</varname></term>
380 <listitem><para>Similar to
381 <varname>Requires=</varname>.
382 Dependencies listed in
383 <varname>RequiresOverridable=</varname>
384 which cannot be fulfilled or fail to
385 start are ignored if the startup was
386 explicitly requested by the user. If
387 the start-up was pulled in indirectly
388 by some dependency or automatic
389 start-up of units that is not
390 requested by the user this dependency
391 must be fulfilled and otherwise the
392 transaction fails. Hence, this option
393 may be used to configure dependencies
394 that are normally honored unless the
395 user explicitly starts up the unit, in
396 which case whether they failed or not
397 is irrelevant.</para></listitem>
401 <term><varname>Requisite=</varname></term>
402 <term><varname>RequisiteOverridable=</varname></term>
404 <listitem><para>Similar to
405 <varname>Requires=</varname>
406 resp. <varname>RequiresOverridable=</varname>. However,
407 if a unit listed here is not started
408 already it will not be started and the
410 immediately.</para></listitem>
414 <term><varname>Wants=</varname></term>
416 <listitem><para>A weaker version of
417 <varname>Requires=</varname>. A unit
418 listed in this option will be started
419 if the configuring unit is. However,
420 if the listed unit fails to start up
421 or cannot be added to the transaction
422 this has no impact on the validity of
423 the transaction as a whole. This is
424 the recommended way to hook start-up
425 of one unit to the start-up of another
428 <para>Note that dependencies of this
429 type may also be configured outside of
430 the unit configuration file by
431 adding a symlink to a
432 <filename>.wants/</filename> directory
433 accompanying the unit file. For
434 details see above.</para></listitem>
438 <term><varname>BindsTo=</varname></term>
440 <listitem><para>Configures requirement
441 dependencies, very similar in style to
442 <varname>Requires=</varname>, however
443 in addition to this behavior it also
444 declares that this unit is stopped
445 when any of the units listed suddenly
446 disappears. Units can suddenly,
447 unexpectedly disappear if a service
448 terminates on its own choice, a device
449 is unplugged or a mount point
450 unmounted without involvement of
451 systemd.</para></listitem>
455 <term><varname>PartOf=</varname></term>
457 <listitem><para>Configures dependencies
458 similar to <varname>Requires=</varname>,
459 but limited to stopping and restarting
460 of units. When systemd stops or restarts
461 the units listed here, the action is
462 propagated to this unit.
463 Note that this is a one way dependency -
464 changes to this unit do not affect the
470 <term><varname>Conflicts=</varname></term>
472 <listitem><para>Configures negative
473 requirement dependencies. If a unit
475 <varname>Conflicts=</varname> setting
476 on another unit, starting the former
477 will stop the latter and vice
478 versa. Note that this setting is
479 independent of and orthogonal to the
480 <varname>After=</varname> and
481 <varname>Before=</varname> ordering
484 <para>If a unit A that conflicts with
485 a unit B is scheduled to be started at
486 the same time as B, the transaction
487 will either fail (in case both are
488 required part of the transaction) or
489 be modified to be fixed (in case one
490 or both jobs are not a required part
491 of the transaction). In the latter
492 case the job that is not the required
493 will be removed, or in case both are
494 not required the unit that conflicts
495 will be started and the unit that is
497 stopped.</para></listitem>
501 <term><varname>Before=</varname></term>
502 <term><varname>After=</varname></term>
504 <listitem><para>Configures ordering
505 dependencies between units. If a unit
506 <filename>foo.service</filename>
508 <option>Before=bar.service</option>
509 and both units are being started,
510 <filename>bar.service</filename>'s
511 start-up is delayed until
512 <filename>foo.service</filename> is
513 started up. Note that this setting is
514 independent of and orthogonal to the
515 requirement dependencies as configured
516 by <varname>Requires=</varname>. It is
517 a common pattern to include a unit
519 <varname>After=</varname> and
520 <varname>Requires=</varname> option in
521 which case the unit listed will be
522 started before the unit that is
523 configured with these options. This
524 option may be specified more than
525 once, in which case ordering
526 dependencies for all listed names are
527 created. <varname>After=</varname> is
529 <varname>Before=</varname>, i.e. while
530 <varname>After=</varname> ensures that
531 the configured unit is started after
532 the listed unit finished starting up,
533 <varname>Before=</varname> ensures the
534 opposite, i.e. that the configured
535 unit is fully started up before the
536 listed unit is started. Note that when
537 two units with an ordering dependency
538 between them are shut down, the
539 inverse of the start-up order is
540 applied. i.e. if a unit is configured
541 with <varname>After=</varname> on
542 another unit, the former is stopped
543 before the latter if both are shut
544 down. If one unit with an ordering
545 dependency on another unit is shut
546 down while the latter is started up,
547 the shut down is ordered before the
548 start-up regardless whether the
549 ordering dependency is actually of
550 type <varname>After=</varname> or
551 <varname>Before=</varname>. If two
552 units have no ordering dependencies
553 between them they are shut down
554 resp. started up simultaneously, and
556 place. </para></listitem>
560 <term><varname>OnFailure=</varname></term>
562 <listitem><para>Lists one or more
563 units that are activated when this
565 '<literal>failed</literal>'
566 state.</para></listitem>
570 <term><varname>PropagatesReloadTo=</varname></term>
571 <term><varname>ReloadPropagatedFrom=</varname></term>
573 <listitem><para>Lists one or more
574 units where reload requests on the
575 unit will be propagated to/on the
576 other unit will be propagated
577 from. Issuing a reload request on a
578 unit will automatically also enqueue a
579 reload request on all units that the
580 reload request shall be propagated to
582 settings.</para></listitem>
586 <term><varname>RequiresMountsFor=</varname></term>
588 <listitem><para>Takes a space
589 separated list of absolute paths. Automatically
590 adds dependencies of type
591 <varname>Requires=</varname> and
592 <varname>After=</varname> for all
593 mount units required to access the
594 specified path.</para></listitem>
598 <term><varname>OnFailureIsolate=</varname></term>
600 <listitem><para>Takes a boolean
601 argument. If <option>true</option> the
603 <varname>OnFailure=</varname> will be
604 enqueued in isolation mode, i.e. all
605 units that are not its dependency will
606 be stopped. If this is set only a
607 single unit may be listed in
608 <varname>OnFailure=</varname>. Defaults
610 <option>false</option>.</para></listitem>
614 <term><varname>IgnoreOnIsolate=</varname></term>
616 <listitem><para>Takes a boolean
617 argument. If <option>true</option>
618 this unit will not be stopped when
619 isolating another unit. Defaults to
620 <option>false</option>.</para></listitem>
624 <term><varname>IgnoreOnSnapshot=</varname></term>
626 <listitem><para>Takes a boolean
627 argument. If <option>true</option>
628 this unit will not be included in
629 snapshots. Defaults to
630 <option>true</option> for device and
631 snapshot units, <option>false</option>
632 for the others.</para></listitem>
636 <term><varname>StopWhenUnneeded=</varname></term>
638 <listitem><para>Takes a boolean
639 argument. If <option>true</option>
640 this unit will be stopped when it is
641 no longer used. Note that in order to
642 minimize the work to be executed,
643 systemd will not stop units by default
644 unless they are conflicting with other
645 units, or the user explicitly
646 requested their shut down. If this
647 option is set, a unit will be
648 automatically cleaned up if no other
649 active unit requires it. Defaults to
650 <option>false</option>.</para></listitem>
654 <term><varname>RefuseManualStart=</varname></term>
655 <term><varname>RefuseManualStop=</varname></term>
657 <listitem><para>Takes a boolean
658 argument. If <option>true</option>
659 this unit can only be activated
660 (resp. deactivated) indirectly. In
661 this case explicit start-up
662 (resp. termination) requested by the
663 user is denied, however if it is
664 started (resp. stopped) as a
665 dependency of another unit, start-up
666 (resp. termination) will succeed. This
667 is mostly a safety feature to ensure
668 that the user does not accidentally
669 activate units that are not intended
670 to be activated explicitly, and not
671 accidentally deactivate units that are
672 not intended to be deactivated.
673 These options default to
674 <option>false</option>.</para></listitem>
678 <term><varname>AllowIsolate=</varname></term>
680 <listitem><para>Takes a boolean
681 argument. If <option>true</option>
682 this unit may be used with the
683 <command>systemctl isolate</command>
684 command. Otherwise this will be
685 refused. It probably is a good idea to
686 leave this disabled except for target
687 units that shall be used similar to
688 runlevels in SysV init systems, just
689 as a precaution to avoid unusable
690 system states. This option defaults to
691 <option>false</option>.</para></listitem>
695 <term><varname>DefaultDependencies=</varname></term>
697 <listitem><para>Takes a boolean
698 argument. If <option>true</option>
699 (the default), a few default
700 dependencies will implicitly be
701 created for the unit. The actual
702 dependencies created depend on the
703 unit type. For example, for service
704 units, these dependencies ensure that
705 the service is started only after
706 basic system initialization is
707 completed and is properly terminated on
708 system shutdown. See the respective
709 man pages for details. Generally, only
710 services involved with early boot or
711 late shutdown should set this option
712 to <option>false</option>. It is
713 highly recommended to leave this
714 option enabled for the majority of
715 common units. If set to
716 <option>false</option> this option
717 does not disable all implicit
718 dependencies, just non-essential
719 ones.</para></listitem>
723 <term><varname>JobTimeoutSec=</varname></term>
725 <listitem><para>When clients are
726 waiting for a job of this unit to
727 complete, time out after the specified
728 time. If this time limit is reached
729 the job will be cancelled, the unit
730 however will not change state or even
731 enter the '<literal>failed</literal>'
732 mode. This value defaults to 0 (job
733 timeouts disabled), except for device
734 units. NB: this timeout is independent
735 from any unit-specific timeout (for
736 example, the timeout set with
737 <varname>Timeout=</varname> in service
738 units) as the job timeout has no
739 effect on the unit itself, only on the
740 job that might be pending for it. Or
741 in other words: unit-specific timeouts
742 are useful to abort unit state
743 changes, and revert them. The job
744 timeout set with this option however
745 is useful to abort only the job
746 waiting for the unit state to
747 change.</para></listitem>
751 <term><varname>ConditionPathExists=</varname></term>
752 <term><varname>ConditionPathExistsGlob=</varname></term>
753 <term><varname>ConditionPathIsDirectory=</varname></term>
754 <term><varname>ConditionPathIsSymbolicLink=</varname></term>
755 <term><varname>ConditionPathIsMountPoint=</varname></term>
756 <term><varname>ConditionPathIsReadWrite=</varname></term>
757 <term><varname>ConditionDirectoryNotEmpty=</varname></term>
758 <term><varname>ConditionFileNotEmpty=</varname></term>
759 <term><varname>ConditionFileIsExecutable=</varname></term>
760 <term><varname>ConditionKernelCommandLine=</varname></term>
761 <term><varname>ConditionVirtualization=</varname></term>
762 <term><varname>ConditionSecurity=</varname></term>
763 <term><varname>ConditionCapability=</varname></term>
764 <term><varname>ConditionHost=</varname></term>
765 <term><varname>ConditionNull=</varname></term>
767 <listitem><para>Before starting a unit
768 verify that the specified condition is
769 true. If it is not true the starting
770 of the unit will be skipped, however
771 all ordering dependencies of it are
772 still respected. A failing condition
773 will not result in the unit being
774 moved into a failure state. The
775 condition is checked at the time the
776 queued start job is to be
780 <varname>ConditionPathExists=</varname>
781 a file existence condition is
782 checked before a unit is started. If
783 the specified absolute path name does
784 not exist the condition will
785 fail. If the absolute path name passed
787 <varname>ConditionPathExists=</varname>
788 is prefixed with an exclamation mark
789 ('!'), the test is negated, and the unit
790 is only started if the path does not
793 <para><varname>ConditionPathExistsGlob=</varname>
795 <varname>ConditionPathExists=</varname>,
796 but checks for the existence of at
797 least one file or directory matching
798 the specified globbing pattern.</para>
800 <para><varname>ConditionPathIsDirectory=</varname>
802 <varname>ConditionPathExists=</varname>
803 but verifies whether a certain path
807 <para><varname>ConditionPathIsSymbolicLink=</varname>
809 <varname>ConditionPathExists=</varname>
810 but verifies whether a certain path
811 exists and is a symbolic
814 <para><varname>ConditionPathIsMountPoint=</varname>
816 <varname>ConditionPathExists=</varname>
817 but verifies whether a certain path
818 exists and is a mount
821 <para><varname>ConditionPathIsReadWrite=</varname>
823 <varname>ConditionPathExists=</varname>
824 but verifies whether the underlying
825 file system is readable and writable
829 <para><varname>ConditionDirectoryNotEmpty=</varname>
831 <varname>ConditionPathExists=</varname>
832 but verifies whether a certain path
833 exists and is a non-empty
836 <para><varname>ConditionFileNotEmpty=</varname>
838 <varname>ConditionPathExists=</varname>
839 but verifies whether a certain path
840 exists and refers to a regular file
841 with a non-zero size.</para>
843 <para><varname>ConditionFileIsExecutable=</varname>
845 <varname>ConditionPathExists=</varname>
846 but verifies whether a certain path
847 exists, is a regular file and marked
851 <varname>ConditionKernelCommandLine=</varname>
852 may be used to check whether a
853 specific kernel command line option is
854 set (or if prefixed with the
855 exclamation mark unset). The argument
856 must either be a single word, or an
857 assignment (i.e. two words, separated
859 case the kernel command line is
860 searched for the word appearing as is,
861 or as left hand side of an
862 assignment. In the latter case the
863 exact assignment is looked for with
864 right and left hand side
867 <para><varname>ConditionVirtualization=</varname>
868 may be used to check whether the
869 system is executed in a virtualized
870 environment and optionally test
871 whether it is a specific
872 implementation. Takes either boolean
873 value to check if being executed in
874 any virtualized environment, or one of
875 <varname>vm</varname> and
876 <varname>container</varname> to test
877 against a generic type of
878 virtualization solution, or one of
879 <varname>qemu</varname>,
880 <varname>kvm</varname>,
881 <varname>vmware</varname>,
882 <varname>microsoft</varname>,
883 <varname>oracle</varname>,
884 <varname>xen</varname>,
885 <varname>bochs</varname>,
886 <varname>chroot</varname>,
887 <varname>openvz</varname>,
888 <varname>lxc</varname>,
889 <varname>lxc-libvirt</varname>,
890 <varname>systemd-nspawn</varname> to
891 test against a specific
892 implementation. If multiple
893 virtualization technologies are nested
894 only the innermost is considered. The
895 test may be negated by prepending an
896 exclamation mark.</para>
898 <para><varname>ConditionSecurity=</varname>
899 may be used to check whether the given
900 security module is enabled on the
901 system. Currently the only recognized
902 value is <varname>selinux</varname>.
903 The test may be negated by prepending
907 <para><varname>ConditionCapability=</varname>
908 may be used to check whether the given
909 capability exists in the capability
910 bounding set of the service manager
911 (i.e. this does not check whether
912 capability is actually available in
913 the permitted or effective sets, see
914 <citerefentry><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
915 for details). Pass a capability name
916 such as <literal>CAP_MKNOD</literal>,
917 possibly prefixed with an exclamation
918 mark to negate the check.</para>
920 <para><varname>ConditionHost=</varname>
921 may be used to match against the
922 host name or machine ID of the
923 host. This either takes a host name
924 string (optionally with shell style
925 globs) which is tested against the
926 locally set host name as returned by
927 <citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
928 or a machine ID formatted as string
930 <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
931 The test may be negated by prepending
932 an exclamation mark.</para>
935 <varname>ConditionNull=</varname> may
936 be used to add a constant condition
937 check value to the unit. It takes a
938 boolean argument. If set to
939 <varname>false</varname> the condition
940 will always fail, otherwise
943 <para>If multiple conditions are
944 specified the unit will be executed if
945 all of them apply (i.e. a logical AND
946 is applied). Condition checks can be
947 prefixed with a pipe symbol (|) in
948 which case a condition becomes a
949 triggering condition. If at least one
950 triggering condition is defined for a
951 unit then the unit will be executed if
952 at least one of the triggering
953 conditions apply and all of the
954 non-triggering conditions. If you
955 prefix an argument with the pipe
956 symbol and an exclamation mark the
957 pipe symbol must be passed first, the
958 exclamation second. Except for
959 <varname>ConditionPathIsSymbolicLink=</varname>,
960 all path checks follow
961 symlinks.</para></listitem>
965 <term><varname>SourcePath=</varname></term>
966 <listitem><para>A path to a
967 configuration file this unit has been
968 generated from. This is primarily
969 useful for implementation of generator
970 tools that convert configuration from
971 an external configuration file format
972 into native unit files. Thus
973 functionality should not be used in
974 normal units.</para></listitem>
978 <para>Unit file may include a [Install] section, which
979 carries installation information for the unit. This
980 section is not interpreted by
981 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
982 during runtime. It is used exclusively by the
983 <command>enable</command> and
984 <command>disable</command> commands of the
985 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
986 tool during installation of a unit:</para>
990 <term><varname>Alias=</varname></term>
992 <listitem><para>Additional names this
993 unit shall be installed under. The
994 names listed here must have the same
995 suffix (i.e. type) as the unit file
996 name. This option may be specified
997 more than once, in which case all
998 listed names are used. At installation
1000 <command>systemctl enable</command>
1001 will create symlinks from these names
1002 to the unit file name.</para></listitem>
1006 <term><varname>WantedBy=</varname></term>
1007 <term><varname>RequiredBy=</varname></term>
1009 <listitem><para>Installs a symlink in
1010 the <filename>.wants/</filename>
1011 resp. <filename>.requires/</filename>
1012 subdirectory for a unit. This has the
1013 effect that when the listed unit name
1014 is activated the unit listing it is
1016 too. <command>WantedBy=foo.service</command>
1018 <filename>bar.service</filename> is
1019 mostly equivalent to
1020 <command>Alias=foo.service.wants/bar.service</command>
1021 in the same file.</para></listitem>
1025 <term><varname>Also=</varname></term>
1027 <listitem><para>Additional units to
1028 install when this unit is
1029 installed. If the user requests
1030 installation of a unit with this
1032 <command>systemctl enable</command>
1033 will automatically install units
1034 listed in this option as
1035 well.</para></listitem>
1042 <title>See Also</title>
1044 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1045 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1046 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1047 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1048 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1049 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1050 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1051 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1052 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1053 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1054 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1055 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1056 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1057 <citerefentry><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>