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>systemd unit configuration files</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>
275 <para>If a unit file is empty (i.e. has the file size
276 0) or is symlinked to <filename>/dev/null</filename>
277 its configuration will not be loaded and it appears
278 with a load state of <literal>masked</literal>, and
279 cannot be activated. Use this as an effective way to
280 fully disable a unit, making it impossible to start it
281 even manually.</para>
283 <para>The unit file format is covered by the
285 url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
286 Stability Promise</ulink>.</para>
290 <title>Options</title>
292 <para>Unit file may include a [Unit] section, which
293 carries generic information about the unit that is not
294 dependent on the type of unit:</para>
299 <term><varname>Description=</varname></term>
300 <listitem><para>A free-form string
301 describing the unit. This is intended
302 for use in UIs to show descriptive
303 information along with the unit
304 name.</para></listitem>
308 <term><varname>Documentation=</varname></term>
309 <listitem><para>A space separated list
310 of URIs referencing documentation for
312 configuration. Accepted are only URIs
314 <literal>http://</literal>,
315 <literal>https://</literal>,
316 <literal>file:</literal>,
317 <literal>info:</literal>,
318 <literal>man:</literal>. For more
319 information about the syntax of these
321 <citerefentry><refentrytitle>uri</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
325 <term><varname>Requires=</varname></term>
327 <listitem><para>Configures requirement
328 dependencies on other units. If this
329 unit gets activated, the units listed
330 here will be activated as well. If one
331 of the other units gets deactivated or
332 its activation fails, this unit will
333 be deactivated. This option may be
334 specified more than once, in which
335 case requirement dependencies for all
336 listed names are created. Note that
337 requirement dependencies do not
338 influence the order in which services
339 are started or stopped. This has to be
340 configured independently with the
341 <varname>After=</varname> or
342 <varname>Before=</varname> options. If
344 <filename>foo.service</filename>
346 <filename>bar.service</filename> as
348 <varname>Requires=</varname> and no
349 ordering is configured with
350 <varname>After=</varname> or
351 <varname>Before=</varname>, then both
352 units will be started simultaneously
353 and without any delay between them if
354 <filename>foo.service</filename> is
355 activated. Often it is a better choice
356 to use <varname>Wants=</varname>
358 <varname>Requires=</varname> in order
359 to achieve a system that is more
360 robust when dealing with failing
361 services.</para></listitem>
365 <term><varname>RequiresOverridable=</varname></term>
367 <listitem><para>Similar to
368 <varname>Requires=</varname>.
369 Dependencies listed in
370 <varname>RequiresOverridable=</varname>
371 which cannot be fulfilled or fail to
372 start are ignored if the startup was
373 explicitly requested by the user. If
374 the start-up was pulled in indirectly
375 by some dependency or automatic
376 start-up of units that is not
377 requested by the user this dependency
378 must be fulfilled and otherwise the
379 transaction fails. Hence, this option
380 may be used to configure dependencies
381 that are normally honored unless the
382 user explicitly starts up the unit, in
383 which case whether they failed or not
384 is irrelevant.</para></listitem>
388 <term><varname>Requisite=</varname></term>
389 <term><varname>RequisiteOverridable=</varname></term>
391 <listitem><para>Similar to
392 <varname>Requires=</varname>
393 resp. <varname>RequiresOverridable=</varname>. However,
394 if a unit listed here is not started
395 already it will not be started and the
397 immediately.</para></listitem>
401 <term><varname>Wants=</varname></term>
403 <listitem><para>A weaker version of
404 <varname>Requires=</varname>. A unit
405 listed in this option will be started
406 if the configuring unit is. However,
407 if the listed unit fails to start up
408 or cannot be added to the transaction
409 this has no impact on the validity of
410 the transaction as a whole. This is
411 the recommended way to hook start-up
412 of one unit to the start-up of another
413 unit. Note that dependencies of this
414 type may also be configured outside of
415 the unit configuration file by
416 adding a symlink to a
417 <filename>.wants/</filename> directory
418 accompanying the unit file. For
419 details see above.</para></listitem>
423 <term><varname>BindsTo=</varname></term>
425 <listitem><para>Configures requirement
426 dependencies, very similar in style to
427 <varname>Requires=</varname>, however
428 in addition to this behaviour it also
429 declares that this unit is stopped
430 when any of the units listed suddenly
431 disappears. Units can suddenly,
432 unexpectedly disappear if a service
433 terminates on its own choice, a device
434 is unplugged or a mount point
435 unmounted without involvement of
436 systemd.</para></listitem>
440 <term><varname>Conflicts=</varname></term>
442 <listitem><para>Configures negative
443 requirement dependencies. If a unit
445 <varname>Conflicts=</varname> setting
446 on another unit, starting the former
447 will stop the latter and vice
448 versa. Note that this setting is
449 independent of and orthogonal to the
450 <varname>After=</varname> and
451 <varname>Before=</varname> ordering
454 <para>If a unit A that conflicts with
455 a unit B is scheduled to be started at
456 the same time as B, the transaction
457 will either fail (in case both are
458 required part of the transaction) or
459 be modified to be fixed (in case one
460 or both jobs are not a required part
461 of the transaction). In the latter
462 case the job that is not the required
463 will be removed, or in case both are
464 not required the unit that conflicts
465 will be started and the unit that is
467 stopped.</para></listitem>
471 <term><varname>Before=</varname></term>
472 <term><varname>After=</varname></term>
474 <listitem><para>Configures ordering
475 dependencies between units. If a unit
476 <filename>foo.service</filename>
478 <option>Before=bar.service</option>
479 and both units are being started,
480 <filename>bar.service</filename>'s
481 start-up is delayed until
482 <filename>foo.service</filename> is
483 started up. Note that this setting is
484 independent of and orthogonal to the
485 requirement dependencies as configured
486 by <varname>Requires=</varname>. It is
487 a common pattern to include a unit
489 <varname>After=</varname> and
490 <varname>Requires=</varname> option in
491 which case the unit listed will be
492 started before the unit that is
493 configured with these options. This
494 option may be specified more than
495 once, in which case ordering
496 dependencies for all listed names are
497 created. <varname>After=</varname> is
499 <varname>Before=</varname>, i.e. while
500 <varname>After=</varname> ensures that
501 the configured unit is started after
502 the listed unit finished starting up,
503 <varname>Before=</varname> ensures the
504 opposite, i.e. that the configured
505 unit is fully started up before the
506 listed unit is started. Note that when
507 two units with an ordering dependency
508 between them are shut down, the
509 inverse of the start-up order is
510 applied. i.e. if a unit is configured
511 with <varname>After=</varname> on
512 another unit, the former is stopped
513 before the latter if both are shut
514 down. If one unit with an ordering
515 dependency on another unit is shut
516 down while the latter is started up,
517 the shut down is ordered before the
518 start-up regardless whether the
519 ordering dependency is actually of
520 type <varname>After=</varname> or
521 <varname>Before=</varname>. If two
522 units have no ordering dependencies
523 between them they are shut down
524 resp. started up simultaneously, and
526 place. </para></listitem>
530 <term><varname>OnFailure=</varname></term>
532 <listitem><para>Lists one or more
533 units that are activated when this
535 '<literal>failed</literal>'
536 state.</para></listitem>
540 <term><varname>PropagatesReloadTo=</varname></term>
541 <term><varname>ReloadPropagatedFrom=</varname></term>
543 <listitem><para>Lists one or more
544 units where reload requests on the
545 unit will be propagated to/on the
546 other unit will be propagated
547 from. Issuing a reload request on a
548 unit will automatically also enqueue a
549 reload request on all units that the
550 reload request shall be propagated to
552 settings.</para></listitem>
556 <term><varname>RequiresMountsFor=</varname></term>
558 <listitem><para>Takes a space
559 separated list of paths. Automatically
560 adds dependencies of type
561 <varname>Requires=</varname> and
562 <varname>After=</varname> for all
563 mount units required to access the
564 specified path.</para></listitem>
568 <term><varname>OnFailureIsolate=</varname></term>
570 <listitem><para>Takes a boolean
571 argument. If <option>true</option> the
573 <varname>OnFailure=</varname> will be
574 enqueued in isolation mode, i.e. all
575 units that are not its dependency will
576 be stopped. If this is set only a
577 single unit may be listed in
578 <varname>OnFailure=</varname>. Defaults
580 <option>false</option>.</para></listitem>
584 <term><varname>IgnoreOnIsolate=</varname></term>
586 <listitem><para>Takes a boolean
587 argument. If <option>true</option>
588 this unit will not be stopped when
589 isolating another unit. Defaults to
590 <option>false</option>.</para></listitem>
594 <term><varname>IgnoreOnSnapshot=</varname></term>
596 <listitem><para>Takes a boolean
597 argument. If <option>true</option>
598 this unit will not be included in
599 snapshots. Defaults to
600 <option>true</option> for device and
601 snapshot units, <option>false</option>
602 for the others.</para></listitem>
606 <term><varname>StopWhenUnneeded=</varname></term>
608 <listitem><para>Takes a boolean
609 argument. If <option>true</option>
610 this unit will be stopped when it is
611 no longer used. Note that in order to
612 minimize the work to be executed,
613 systemd will not stop units by default
614 unless they are conflicting with other
615 units, or the user explicitly
616 requested their shut down. If this
617 option is set, a unit will be
618 automatically cleaned up if no other
619 active unit requires it. Defaults to
620 <option>false</option>.</para></listitem>
624 <term><varname>RefuseManualStart=</varname></term>
625 <term><varname>RefuseManualStop=</varname></term>
627 <listitem><para>Takes a boolean
628 argument. If <option>true</option>
629 this unit can only be activated
630 (resp. deactivated) indirectly. In
631 this case explicit start-up
632 (resp. termination) requested by the
633 user is denied, however if it is
634 started (resp. stopped) as a
635 dependency of another unit, start-up
636 (resp. termination) will succeed. This
637 is mostly a safety feature to ensure
638 that the user does not accidentally
639 activate units that are not intended
640 to be activated explicitly, and not
641 accidentally deactivate units that are
642 not intended to be deactivated.
643 These options default to
644 <option>false</option>.</para></listitem>
648 <term><varname>AllowIsolate=</varname></term>
650 <listitem><para>Takes a boolean
651 argument. If <option>true</option>
652 this unit may be used with the
653 <command>systemctl isolate</command>
654 command. Otherwise this will be
655 refused. It probably is a good idea to
656 leave this disabled except for target
657 units that shall be used similar to
658 runlevels in SysV init systems, just
659 as a precaution to avoid unusable
660 system states. This option defaults to
661 <option>false</option>.</para></listitem>
665 <term><varname>DefaultDependencies=</varname></term>
667 <listitem><para>Takes a boolean
668 argument. If <option>true</option>
669 (the default), a few default
670 dependencies will implicitly be
671 created for the unit. The actual
672 dependencies created depend on the
673 unit type. For example, for service
674 units, these dependencies ensure that
675 the service is started only after
676 basic system initialization is
677 completed and is properly terminated on
678 system shutdown. See the respective
679 man pages for details. Generally, only
680 services involved with early boot or
681 late shutdown should set this option
682 to <option>false</option>. It is
683 highly recommended to leave this
684 option enabled for the majority of
685 common units. If set to
686 <option>false</option> this option
687 does not disable all implicit
688 dependencies, just non-essential
689 ones.</para></listitem>
693 <term><varname>JobTimeoutSec=</varname></term>
695 <listitem><para>When clients are
696 waiting for a job of this unit to
697 complete, time out after the specified
698 time. If this time limit is reached
699 the job will be cancelled, the unit
700 however will not change state or even
701 enter the '<literal>failed</literal>'
702 mode. This value defaults to 0 (job
703 timeouts disabled), except for device
704 units. NB: this timeout is independent
705 from any unit-specific timeout (for
706 example, the timeout set with
707 <varname>Timeout=</varname> in service
708 units) as the job timeout has no
709 effect on the unit itself, only on the
710 job that might be pending for it. Or
711 in other words: unit-specific timeouts
712 are useful to abort unit state
713 changes, and revert them. The job
714 timeout set with this option however
715 is useful to abort only the job
716 waiting for the unit state to
717 change.</para></listitem>
721 <term><varname>ConditionPathExists=</varname></term>
722 <term><varname>ConditionPathExistsGlob=</varname></term>
723 <term><varname>ConditionPathIsDirectory=</varname></term>
724 <term><varname>ConditionPathIsSymbolicLink=</varname></term>
725 <term><varname>ConditionPathIsMountPoint=</varname></term>
726 <term><varname>ConditionPathIsReadWrite=</varname></term>
727 <term><varname>ConditionDirectoryNotEmpty=</varname></term>
728 <term><varname>ConditionFileIsExecutable=</varname></term>
729 <term><varname>ConditionKernelCommandLine=</varname></term>
730 <term><varname>ConditionVirtualization=</varname></term>
731 <term><varname>ConditionSecurity=</varname></term>
732 <term><varname>ConditionCapability=</varname></term>
733 <term><varname>ConditionNull=</varname></term>
735 <listitem><para>Before starting a unit
736 verify that the specified condition is
738 <varname>ConditionPathExists=</varname>
739 a file existence condition can be
740 checked before a unit is started. If
741 the specified absolute path name does
742 not exist, startup of a unit will not
743 actually happen, however the unit is
744 still useful for ordering purposes in
745 this case. The condition is checked at
746 the time the queued start job is to be
747 executed. If the absolute path name
749 <varname>ConditionPathExists=</varname>
750 is prefixed with an exclamation mark
751 (!), the test is negated, and the unit
752 is only started if the path does not
754 <varname>ConditionPathExistsGlob=</varname>
755 works in a similar way, but checks for
756 the existence of at least one file or
757 directory matching the specified
759 pattern. <varname>ConditionPathIsDirectory=</varname>
761 <varname>ConditionPathExists=</varname>
762 but verifies whether a certain path
764 directory. <varname>ConditionPathIsSymbolicLink=</varname>
766 <varname>ConditionPathExists=</varname>
767 but verifies whether a certain path
768 exists and is a symbolic
769 link. <varname>ConditionPathIsMountPoint=</varname>
771 <varname>ConditionPathExists=</varname>
772 but verifies whether a certain path
773 exists and is a mount
774 point. <varname>ConditionPathIsReadWrite=</varname>
776 <varname>ConditionPathExists=</varname>
777 but verifies whether the underlying
778 file system is read and writable
780 read-only). <varname>ConditionFileIsExecutable=</varname>
782 <varname>ConditionPathExists=</varname>
783 but verifies whether a certain path
784 exists, is a regular file and marked
786 <varname>ConditionDirectoryNotEmpty=</varname>
788 <varname>ConditionPathExists=</varname>
789 but verifies whether a certain path
790 exists and is a non-empty
792 <varname>ConditionKernelCommandLine=</varname>
793 may be used to check whether a
794 specific kernel command line option is
795 set (or if prefixed with the
796 exclamation mark unset). The argument
797 must either be a single word, or an
798 assignment (i.e. two words, separated
799 by the equality sign). In the former
800 case the kernel command line is
801 searched for the word appearing as is,
802 or as left hand side of an
803 assignment. In the latter case the
804 exact assignment is looked for with
805 right and left hand side
806 matching. <varname>ConditionVirtualization=</varname>
807 may be used to check whether the
808 system is executed in a virtualized
809 environment and optionally test
810 whether it is a specific
811 implementation. Takes either boolean
812 value to check if being executed in
813 any virtualized environment, or one of
814 <varname>vm</varname> and
815 <varname>container</varname> to test
816 against a specific type of
817 virtualization solution, or one of
818 <varname>qemu</varname>,
819 <varname>kvm</varname>,
820 <varname>vmware</varname>,
821 <varname>microsoft</varname>,
822 <varname>oracle</varname>,
823 <varname>xen</varname>,
824 <varname>bochs</varname>,
825 <varname>chroot</varname>,
826 <varname>openvz</varname>,
827 <varname>lxc</varname>,
828 <varname>lxc-libvirt</varname>,
829 <varname>systemd-nspawn</varname> to
830 test against a specific
831 implementation. If multiple
832 virtualization technologies are nested
833 only the innermost is considered. The
834 test may be negated by prepending an
836 <varname>ConditionSecurity=</varname>
837 may be used to check whether the given
838 security module is enabled on the
839 system. Currently the only recognized
840 value is <varname>selinux</varname>.
841 The test may be negated by prepending
843 mark. <varname>ConditionCapability=</varname>
844 may be used to check whether the given
845 capability exists in the capability
846 bounding set of the service manager
847 (i.e. this does not check whether
848 capability is actually available in
849 the permitted or effective sets, see
850 <citerefentry><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
851 for details). Pass a capability name
852 such as <literal>CAP_MKNOD</literal>,
853 possibly prefixed with an exclamation
854 mark to negate the check. Finally,
855 <varname>ConditionNull=</varname> may
856 be used to add a constant condition
857 check value to the unit. It takes a
858 boolean argument. If set to
859 <varname>false</varname> the condition
860 will always fail, otherwise
861 succeed. If multiple conditions are
862 specified the unit will be executed if
863 all of them apply (i.e. a logical AND
864 is applied). Condition checks can be
865 prefixed with a pipe symbol (|) in
866 which case a condition becomes a
867 triggering condition. If at least one
868 triggering condition is defined for a
869 unit then the unit will be executed if
870 at least one of the triggering
871 conditions apply and all of the
872 non-triggering conditions. If you
873 prefix an argument with the pipe
874 symbol and an exclamation mark the
875 pipe symbol must be passed first, the
876 exclamation second. Except for
877 <varname>ConditionPathIsSymbolicLink=</varname>,
878 all path checks follow
879 symlinks.</para></listitem>
883 <term><varname>SourcePath=</varname></term>
884 <listitem><para>A path to a
885 configuration file this unit has been
886 generated from. This is primarily
887 useful for implementation of generator
888 tools that convert configuration from
889 an external configuration file format
890 into native unit files. Thus
891 functionality should not be used in
892 normal units.</para></listitem>
896 <para>Unit file may include a [Install] section, which
897 carries installation information for the unit. This
898 section is not interpreted by
899 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
900 during runtime. It is used exclusively by the
901 <command>enable</command> and
902 <command>disable</command> commands of the
903 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
904 tool during installation of a unit:</para>
908 <term><varname>Alias=</varname></term>
910 <listitem><para>Additional names this
911 unit shall be installed under. The
912 names listed here must have the same
913 suffix (i.e. type) as the unit file
914 name. This option may be specified
915 more than once, in which case all
916 listed names are used. At installation
918 <command>systemctl enable</command>
919 will create symlinks from these names
920 to the unit file name.</para></listitem>
924 <term><varname>WantedBy=</varname></term>
925 <term><varname>RequiredBy=</varname></term>
927 <listitem><para>Installs a symlink in
928 the <filename>.wants/</filename>
929 resp. <filename>.requires/</filename>
930 subdirectory for a unit. This has the
931 effect that when the listed unit name
932 is activated the unit listing it is
934 too. <command>WantedBy=foo.service</command>
936 <filename>bar.service</filename> is
938 <command>Alias=foo.service.wants/bar.service</command>
939 in the same file.</para></listitem>
943 <term><varname>Also=</varname></term>
945 <listitem><para>Additional units to
946 install when this unit is
947 installed. If the user requests
948 installation of a unit with this
950 <command>systemctl enable</command>
951 will automatically install units
952 listed in this option as
953 well.</para></listitem>
960 <title>See Also</title>
962 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
963 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
964 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
965 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
966 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
967 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
968 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
969 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
970 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
971 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
972 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
973 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
974 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
975 <citerefentry><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>