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
366 services.</para></listitem>
370 <term><varname>RequiresOverridable=</varname></term>
372 <listitem><para>Similar to
373 <varname>Requires=</varname>.
374 Dependencies listed in
375 <varname>RequiresOverridable=</varname>
376 which cannot be fulfilled or fail to
377 start are ignored if the startup was
378 explicitly requested by the user. If
379 the start-up was pulled in indirectly
380 by some dependency or automatic
381 start-up of units that is not
382 requested by the user this dependency
383 must be fulfilled and otherwise the
384 transaction fails. Hence, this option
385 may be used to configure dependencies
386 that are normally honored unless the
387 user explicitly starts up the unit, in
388 which case whether they failed or not
389 is irrelevant.</para></listitem>
393 <term><varname>Requisite=</varname></term>
394 <term><varname>RequisiteOverridable=</varname></term>
396 <listitem><para>Similar to
397 <varname>Requires=</varname>
398 resp. <varname>RequiresOverridable=</varname>. However,
399 if a unit listed here is not started
400 already it will not be started and the
402 immediately.</para></listitem>
406 <term><varname>Wants=</varname></term>
408 <listitem><para>A weaker version of
409 <varname>Requires=</varname>. A unit
410 listed in this option will be started
411 if the configuring unit is. However,
412 if the listed unit fails to start up
413 or cannot be added to the transaction
414 this has no impact on the validity of
415 the transaction as a whole. This is
416 the recommended way to hook start-up
417 of one unit to the start-up of another
418 unit. Note that dependencies of this
419 type may also be configured outside of
420 the unit configuration file by
421 adding a symlink to a
422 <filename>.wants/</filename> directory
423 accompanying the unit file. For
424 details see above.</para></listitem>
428 <term><varname>BindsTo=</varname></term>
430 <listitem><para>Configures requirement
431 dependencies, very similar in style to
432 <varname>Requires=</varname>, however
433 in addition to this behaviour it also
434 declares that this unit is stopped
435 when any of the units listed suddenly
436 disappears. Units can suddenly,
437 unexpectedly disappear if a service
438 terminates on its own choice, a device
439 is unplugged or a mount point
440 unmounted without involvement of
441 systemd.</para></listitem>
445 <term><varname>PartOf=</varname></term>
447 <listitem><para>Configures dependencies
448 similar to <varname>Requires=</varname>,
449 but limited to stopping and restarting
450 of units. When systemd stops or restarts
451 the units listed here, the action is
452 propagated to this unit.
453 Note that this is a one way dependency -
454 changes to this unit do not affect the
460 <term><varname>Conflicts=</varname></term>
462 <listitem><para>Configures negative
463 requirement dependencies. If a unit
465 <varname>Conflicts=</varname> setting
466 on another unit, starting the former
467 will stop the latter and vice
468 versa. Note that this setting is
469 independent of and orthogonal to the
470 <varname>After=</varname> and
471 <varname>Before=</varname> ordering
474 <para>If a unit A that conflicts with
475 a unit B is scheduled to be started at
476 the same time as B, the transaction
477 will either fail (in case both are
478 required part of the transaction) or
479 be modified to be fixed (in case one
480 or both jobs are not a required part
481 of the transaction). In the latter
482 case the job that is not the required
483 will be removed, or in case both are
484 not required the unit that conflicts
485 will be started and the unit that is
487 stopped.</para></listitem>
491 <term><varname>Before=</varname></term>
492 <term><varname>After=</varname></term>
494 <listitem><para>Configures ordering
495 dependencies between units. If a unit
496 <filename>foo.service</filename>
498 <option>Before=bar.service</option>
499 and both units are being started,
500 <filename>bar.service</filename>'s
501 start-up is delayed until
502 <filename>foo.service</filename> is
503 started up. Note that this setting is
504 independent of and orthogonal to the
505 requirement dependencies as configured
506 by <varname>Requires=</varname>. It is
507 a common pattern to include a unit
509 <varname>After=</varname> and
510 <varname>Requires=</varname> option in
511 which case the unit listed will be
512 started before the unit that is
513 configured with these options. This
514 option may be specified more than
515 once, in which case ordering
516 dependencies for all listed names are
517 created. <varname>After=</varname> is
519 <varname>Before=</varname>, i.e. while
520 <varname>After=</varname> ensures that
521 the configured unit is started after
522 the listed unit finished starting up,
523 <varname>Before=</varname> ensures the
524 opposite, i.e. that the configured
525 unit is fully started up before the
526 listed unit is started. Note that when
527 two units with an ordering dependency
528 between them are shut down, the
529 inverse of the start-up order is
530 applied. i.e. if a unit is configured
531 with <varname>After=</varname> on
532 another unit, the former is stopped
533 before the latter if both are shut
534 down. If one unit with an ordering
535 dependency on another unit is shut
536 down while the latter is started up,
537 the shut down is ordered before the
538 start-up regardless whether the
539 ordering dependency is actually of
540 type <varname>After=</varname> or
541 <varname>Before=</varname>. If two
542 units have no ordering dependencies
543 between them they are shut down
544 resp. started up simultaneously, and
546 place. </para></listitem>
550 <term><varname>OnFailure=</varname></term>
552 <listitem><para>Lists one or more
553 units that are activated when this
555 '<literal>failed</literal>'
556 state.</para></listitem>
560 <term><varname>PropagatesReloadTo=</varname></term>
561 <term><varname>ReloadPropagatedFrom=</varname></term>
563 <listitem><para>Lists one or more
564 units where reload requests on the
565 unit will be propagated to/on the
566 other unit will be propagated
567 from. Issuing a reload request on a
568 unit will automatically also enqueue a
569 reload request on all units that the
570 reload request shall be propagated to
572 settings.</para></listitem>
576 <term><varname>RequiresMountsFor=</varname></term>
578 <listitem><para>Takes a space
579 separated list of paths. Automatically
580 adds dependencies of type
581 <varname>Requires=</varname> and
582 <varname>After=</varname> for all
583 mount units required to access the
584 specified path.</para></listitem>
588 <term><varname>OnFailureIsolate=</varname></term>
590 <listitem><para>Takes a boolean
591 argument. If <option>true</option> the
593 <varname>OnFailure=</varname> will be
594 enqueued in isolation mode, i.e. all
595 units that are not its dependency will
596 be stopped. If this is set only a
597 single unit may be listed in
598 <varname>OnFailure=</varname>. Defaults
600 <option>false</option>.</para></listitem>
604 <term><varname>IgnoreOnIsolate=</varname></term>
606 <listitem><para>Takes a boolean
607 argument. If <option>true</option>
608 this unit will not be stopped when
609 isolating another unit. Defaults to
610 <option>false</option>.</para></listitem>
614 <term><varname>IgnoreOnSnapshot=</varname></term>
616 <listitem><para>Takes a boolean
617 argument. If <option>true</option>
618 this unit will not be included in
619 snapshots. Defaults to
620 <option>true</option> for device and
621 snapshot units, <option>false</option>
622 for the others.</para></listitem>
626 <term><varname>StopWhenUnneeded=</varname></term>
628 <listitem><para>Takes a boolean
629 argument. If <option>true</option>
630 this unit will be stopped when it is
631 no longer used. Note that in order to
632 minimize the work to be executed,
633 systemd will not stop units by default
634 unless they are conflicting with other
635 units, or the user explicitly
636 requested their shut down. If this
637 option is set, a unit will be
638 automatically cleaned up if no other
639 active unit requires it. Defaults to
640 <option>false</option>.</para></listitem>
644 <term><varname>RefuseManualStart=</varname></term>
645 <term><varname>RefuseManualStop=</varname></term>
647 <listitem><para>Takes a boolean
648 argument. If <option>true</option>
649 this unit can only be activated
650 (resp. deactivated) indirectly. In
651 this case explicit start-up
652 (resp. termination) requested by the
653 user is denied, however if it is
654 started (resp. stopped) as a
655 dependency of another unit, start-up
656 (resp. termination) will succeed. This
657 is mostly a safety feature to ensure
658 that the user does not accidentally
659 activate units that are not intended
660 to be activated explicitly, and not
661 accidentally deactivate units that are
662 not intended to be deactivated.
663 These options default to
664 <option>false</option>.</para></listitem>
668 <term><varname>AllowIsolate=</varname></term>
670 <listitem><para>Takes a boolean
671 argument. If <option>true</option>
672 this unit may be used with the
673 <command>systemctl isolate</command>
674 command. Otherwise this will be
675 refused. It probably is a good idea to
676 leave this disabled except for target
677 units that shall be used similar to
678 runlevels in SysV init systems, just
679 as a precaution to avoid unusable
680 system states. This option defaults to
681 <option>false</option>.</para></listitem>
685 <term><varname>DefaultDependencies=</varname></term>
687 <listitem><para>Takes a boolean
688 argument. If <option>true</option>
689 (the default), a few default
690 dependencies will implicitly be
691 created for the unit. The actual
692 dependencies created depend on the
693 unit type. For example, for service
694 units, these dependencies ensure that
695 the service is started only after
696 basic system initialization is
697 completed and is properly terminated on
698 system shutdown. See the respective
699 man pages for details. Generally, only
700 services involved with early boot or
701 late shutdown should set this option
702 to <option>false</option>. It is
703 highly recommended to leave this
704 option enabled for the majority of
705 common units. If set to
706 <option>false</option> this option
707 does not disable all implicit
708 dependencies, just non-essential
709 ones.</para></listitem>
713 <term><varname>JobTimeoutSec=</varname></term>
715 <listitem><para>When clients are
716 waiting for a job of this unit to
717 complete, time out after the specified
718 time. If this time limit is reached
719 the job will be cancelled, the unit
720 however will not change state or even
721 enter the '<literal>failed</literal>'
722 mode. This value defaults to 0 (job
723 timeouts disabled), except for device
724 units. NB: this timeout is independent
725 from any unit-specific timeout (for
726 example, the timeout set with
727 <varname>Timeout=</varname> in service
728 units) as the job timeout has no
729 effect on the unit itself, only on the
730 job that might be pending for it. Or
731 in other words: unit-specific timeouts
732 are useful to abort unit state
733 changes, and revert them. The job
734 timeout set with this option however
735 is useful to abort only the job
736 waiting for the unit state to
737 change.</para></listitem>
741 <term><varname>ConditionPathExists=</varname></term>
742 <term><varname>ConditionPathExistsGlob=</varname></term>
743 <term><varname>ConditionPathIsDirectory=</varname></term>
744 <term><varname>ConditionPathIsSymbolicLink=</varname></term>
745 <term><varname>ConditionPathIsMountPoint=</varname></term>
746 <term><varname>ConditionPathIsReadWrite=</varname></term>
747 <term><varname>ConditionDirectoryNotEmpty=</varname></term>
748 <term><varname>ConditionFileIsExecutable=</varname></term>
749 <term><varname>ConditionKernelCommandLine=</varname></term>
750 <term><varname>ConditionVirtualization=</varname></term>
751 <term><varname>ConditionSecurity=</varname></term>
752 <term><varname>ConditionCapability=</varname></term>
753 <term><varname>ConditionNull=</varname></term>
755 <listitem><para>Before starting a unit
756 verify that the specified condition is
758 <varname>ConditionPathExists=</varname>
759 a file existence condition can be
760 checked before a unit is started. If
761 the specified absolute path name does
762 not exist, startup of a unit will not
763 actually happen, however the unit is
764 still useful for ordering purposes in
765 this case. The condition is checked at
766 the time the queued start job is to be
767 executed. If the absolute path name
769 <varname>ConditionPathExists=</varname>
770 is prefixed with an exclamation mark
771 (!), the test is negated, and the unit
772 is only started if the path does not
774 <varname>ConditionPathExistsGlob=</varname>
775 works in a similar way, but checks for
776 the existence of at least one file or
777 directory matching the specified
779 pattern. <varname>ConditionPathIsDirectory=</varname>
781 <varname>ConditionPathExists=</varname>
782 but verifies whether a certain path
784 directory. <varname>ConditionPathIsSymbolicLink=</varname>
786 <varname>ConditionPathExists=</varname>
787 but verifies whether a certain path
788 exists and is a symbolic
789 link. <varname>ConditionPathIsMountPoint=</varname>
791 <varname>ConditionPathExists=</varname>
792 but verifies whether a certain path
793 exists and is a mount
794 point. <varname>ConditionPathIsReadWrite=</varname>
796 <varname>ConditionPathExists=</varname>
797 but verifies whether the underlying
798 file system is read and writable
800 read-only). <varname>ConditionFileIsExecutable=</varname>
802 <varname>ConditionPathExists=</varname>
803 but verifies whether a certain path
804 exists, is a regular file and marked
806 <varname>ConditionDirectoryNotEmpty=</varname>
808 <varname>ConditionPathExists=</varname>
809 but verifies whether a certain path
810 exists and is a non-empty
812 <varname>ConditionKernelCommandLine=</varname>
813 may be used to check whether a
814 specific kernel command line option is
815 set (or if prefixed with the
816 exclamation mark unset). The argument
817 must either be a single word, or an
818 assignment (i.e. two words, separated
819 by the equality sign). In the former
820 case the kernel command line is
821 searched for the word appearing as is,
822 or as left hand side of an
823 assignment. In the latter case the
824 exact assignment is looked for with
825 right and left hand side
826 matching. <varname>ConditionVirtualization=</varname>
827 may be used to check whether the
828 system is executed in a virtualized
829 environment and optionally test
830 whether it is a specific
831 implementation. Takes either boolean
832 value to check if being executed in
833 any virtualized environment, or one of
834 <varname>vm</varname> and
835 <varname>container</varname> to test
836 against a specific type of
837 virtualization solution, or one of
838 <varname>qemu</varname>,
839 <varname>kvm</varname>,
840 <varname>vmware</varname>,
841 <varname>microsoft</varname>,
842 <varname>oracle</varname>,
843 <varname>xen</varname>,
844 <varname>bochs</varname>,
845 <varname>chroot</varname>,
846 <varname>openvz</varname>,
847 <varname>lxc</varname>,
848 <varname>lxc-libvirt</varname>,
849 <varname>systemd-nspawn</varname> to
850 test against a specific
851 implementation. If multiple
852 virtualization technologies are nested
853 only the innermost is considered. The
854 test may be negated by prepending an
856 <varname>ConditionSecurity=</varname>
857 may be used to check whether the given
858 security module is enabled on the
859 system. Currently the only recognized
860 value is <varname>selinux</varname>.
861 The test may be negated by prepending
863 mark. <varname>ConditionCapability=</varname>
864 may be used to check whether the given
865 capability exists in the capability
866 bounding set of the service manager
867 (i.e. this does not check whether
868 capability is actually available in
869 the permitted or effective sets, see
870 <citerefentry><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
871 for details). Pass a capability name
872 such as <literal>CAP_MKNOD</literal>,
873 possibly prefixed with an exclamation
874 mark to negate the check. Finally,
875 <varname>ConditionNull=</varname> may
876 be used to add a constant condition
877 check value to the unit. It takes a
878 boolean argument. If set to
879 <varname>false</varname> the condition
880 will always fail, otherwise
881 succeed. If multiple conditions are
882 specified the unit will be executed if
883 all of them apply (i.e. a logical AND
884 is applied). Condition checks can be
885 prefixed with a pipe symbol (|) in
886 which case a condition becomes a
887 triggering condition. If at least one
888 triggering condition is defined for a
889 unit then the unit will be executed if
890 at least one of the triggering
891 conditions apply and all of the
892 non-triggering conditions. If you
893 prefix an argument with the pipe
894 symbol and an exclamation mark the
895 pipe symbol must be passed first, the
896 exclamation second. Except for
897 <varname>ConditionPathIsSymbolicLink=</varname>,
898 all path checks follow
899 symlinks.</para></listitem>
903 <term><varname>SourcePath=</varname></term>
904 <listitem><para>A path to a
905 configuration file this unit has been
906 generated from. This is primarily
907 useful for implementation of generator
908 tools that convert configuration from
909 an external configuration file format
910 into native unit files. Thus
911 functionality should not be used in
912 normal units.</para></listitem>
916 <para>Unit file may include a [Install] section, which
917 carries installation information for the unit. This
918 section is not interpreted by
919 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
920 during runtime. It is used exclusively by the
921 <command>enable</command> and
922 <command>disable</command> commands of the
923 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
924 tool during installation of a unit:</para>
928 <term><varname>Alias=</varname></term>
930 <listitem><para>Additional names this
931 unit shall be installed under. The
932 names listed here must have the same
933 suffix (i.e. type) as the unit file
934 name. This option may be specified
935 more than once, in which case all
936 listed names are used. At installation
938 <command>systemctl enable</command>
939 will create symlinks from these names
940 to the unit file name.</para></listitem>
944 <term><varname>WantedBy=</varname></term>
945 <term><varname>RequiredBy=</varname></term>
947 <listitem><para>Installs a symlink in
948 the <filename>.wants/</filename>
949 resp. <filename>.requires/</filename>
950 subdirectory for a unit. This has the
951 effect that when the listed unit name
952 is activated the unit listing it is
954 too. <command>WantedBy=foo.service</command>
956 <filename>bar.service</filename> is
958 <command>Alias=foo.service.wants/bar.service</command>
959 in the same file.</para></listitem>
963 <term><varname>Also=</varname></term>
965 <listitem><para>Additional units to
966 install when this unit is
967 installed. If the user requests
968 installation of a unit with this
970 <command>systemctl enable</command>
971 will automatically install units
972 listed in this option as
973 well.</para></listitem>
980 <title>See Also</title>
982 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
983 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
984 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
985 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
986 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
987 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
988 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
989 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
990 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
991 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
992 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
993 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
994 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
995 <citerefentry><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>