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 appropiate 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>
265 <para>If a unit file is empty (i.e. has the file size
266 0) or is symlinked to <filename>/dev/null</filename>
267 its configuration will not be loaded and it appears
268 with a load state of <literal>masked</literal>, and
269 cannot be activated. Use this as an effective way to
270 fully disable a unit, making it impossible to start it
271 even manually.</para>
273 <para>The unit file format is covered by the
275 url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
276 Stability Promise</ulink>.</para>
280 <title>Options</title>
282 <para>Unit file may include a [Unit] section, which
283 carries generic information about the unit that is not
284 dependent on the type of unit:</para>
289 <term><varname>Description=</varname></term>
290 <listitem><para>A free-form string
291 describing the unit. This is intended
292 for use in UIs to show descriptive
293 information along with the unit
294 name.</para></listitem>
298 <term><varname>Requires=</varname></term>
300 <listitem><para>Configures requirement
301 dependencies on other units. If this
302 unit gets activated, the units listed
303 here will be activated as well. If one
304 of the other units gets deactivated or
305 its activation fails, this unit will
306 be deactivated. This option may be
307 specified more than once, in which
308 case requirement dependencies for all
309 listed names are created. Note that
310 requirement dependencies do not
311 influence the order in which services
312 are started or stopped. This has to be
313 configured independently with the
314 <varname>After=</varname> or
315 <varname>Before=</varname> options. If
317 <filename>foo.service</filename>
319 <filename>bar.service</filename> as
321 <varname>Requires=</varname> and no
322 ordering is configured with
323 <varname>After=</varname> or
324 <varname>Before=</varname>, then both
325 units will be started simultaneously
326 and without any delay between them if
327 <filename>foo.service</filename> is
328 activated. Often it is a better choice
329 to use <varname>Wants=</varname>
331 <varname>Requires=</varname> in order
332 to achieve a system that is more
333 robust when dealing with failing
334 services.</para></listitem>
338 <term><varname>RequiresOverridable=</varname></term>
340 <listitem><para>Similar to
341 <varname>Requires=</varname>.
342 Dependencies listed in
343 <varname>RequiresOverridable=</varname>
344 which cannot be fulfilled or fail to
345 start are ignored if the startup was
346 explicitly requested by the user. If
347 the start-up was pulled in indirectly
348 by some dependency or automatic
349 start-up of units that is not
350 requested by the user this dependency
351 must be fulfilled and otherwise the
352 transaction fails. Hence, this option
353 may be used to configure dependencies
354 that are normally honored unless the
355 user explicitly starts up the unit, in
356 which case whether they failed or not
357 is irrelevant.</para></listitem>
361 <term><varname>Requisite=</varname></term>
362 <term><varname>RequisiteOverridable=</varname></term>
364 <listitem><para>Similar to
365 <varname>Requires=</varname>
366 resp. <varname>RequiresOverridable=</varname>. However,
367 if a unit listed here is not started
368 already it will not be started and the
370 immediately.</para></listitem>
374 <term><varname>Wants=</varname></term>
376 <listitem><para>A weaker version of
377 <varname>Requires=</varname>. A unit
378 listed in this option will be started
379 if the configuring unit is. However,
380 if the listed unit fails to start up
381 or cannot be added to the transaction
382 this has no impact on the validity of
383 the transaction as a whole. This is
384 the recommended way to hook start-up
385 of one unit to the start-up of another
386 unit. Note that dependencies of this
387 type may also be configured outside of
388 the unit configuration file by
389 adding a symlink to a
390 <filename>.wants/</filename> directory
391 accompanying the unit file. For
392 details see above.</para></listitem>
396 <term><varname>BindTo=</varname></term>
398 <listitem><para>Configures requirement
399 dependencies, very similar in style to
400 <varname>Requires=</varname>, however
401 in addition to this behaviour it also
402 declares that this unit is stopped
403 when any of the units listed suddenly
404 disappears. Units can suddenly,
405 unexpectedly disappear if a service
406 terminates on its own choice, a device
407 is unplugged or a mount point
408 unmounted without involvement of
409 systemd.</para></listitem>
413 <term><varname>Conflicts=</varname></term>
415 <listitem><para>Configures negative
416 requirement dependencies. If a unit
418 <varname>Conflicts=</varname> setting
419 on another unit, starting the former
420 will stop the latter and vice
421 versa. Note that this setting is
422 independent of and orthogonal to the
423 <varname>After=</varname> and
424 <varname>Before=</varname> ordering
427 <para>If a unit A that conflicts with
428 a unit B is scheduled to be started at
429 the same time as B, the transaction
430 will either fail (in case both are
431 required part of the transaction) or
432 be modified to be fixed (in case one
433 or both jobs are not a required part
434 of the transaction). In the latter
435 case the job that is not the required
436 will be removed, or in case both are
437 not required the unit that conflicts
438 will be started and the unit that is
440 stopped.</para></listitem>
444 <term><varname>Before=</varname></term>
445 <term><varname>After=</varname></term>
447 <listitem><para>Configures ordering
448 dependencies between units. If a unit
449 <filename>foo.service</filename>
451 <option>Before=bar.service</option>
452 and both units are being started,
453 <filename>bar.service</filename>'s
454 start-up is delayed until
455 <filename>foo.service</filename> is
456 started up. Note that this setting is
457 independent of and orthogonal to the
458 requirement dependencies as configured
459 by <varname>Requires=</varname>. It is
460 a common pattern to include a unit
462 <varname>After=</varname> and
463 <varname>Requires=</varname> option in
464 which case the unit listed will be
465 started before the unit that is
466 configured with these options. This
467 option may be specified more than
468 once, in which case ordering
469 dependencies for all listed names are
470 created. <varname>After=</varname> is
472 <varname>Before=</varname>, i.e. while
473 <varname>After=</varname> ensures that
474 the configured unit is started after
475 the listed unit finished starting up,
476 <varname>Before=</varname> ensures the
477 opposite, i.e. that the configured
478 unit is fully started up before the
479 listed unit is started. Note that when
480 two units with an ordering dependency
481 between them are shut down, the
482 inverse of the start-up order is
483 applied. i.e. if a unit is configured
484 with <varname>After=</varname> on
485 another unit, the former is stopped
486 before the latter if both are shut
487 down. If one unit with an ordering
488 dependency on another unit is shut
489 down while the latter is started up,
490 the shut down is ordered before the
491 start-up regardless whether the
492 ordering dependency is actually of
493 type <varname>After=</varname> or
494 <varname>Before=</varname>. If two
495 units have no ordering dependencies
496 between them they are shut down
497 resp. started up simultaneously, and
499 place. </para></listitem>
503 <term><varname>OnFailure=</varname></term>
505 <listitem><para>Lists one or more
506 units that are activated when this
508 '<literal>failed</literal>'
509 state.</para></listitem>
513 <term><varname>PropagateReloadTo=</varname></term>
514 <term><varname>PropagateReloadFrom=</varname></term>
516 <listitem><para>Lists one or more
517 units where reload requests on the
518 unit will be propagated to/on the
519 other unit will be propagated
520 from. Issuing a reload request on a
521 unit will automatically also enqueue a
522 reload request on all units that the
523 reload request shall be propagated to
525 settings.</para></listitem>
529 <term><varname>OnFailureIsolate=</varname></term>
531 <listitem><para>Takes a boolean
532 argument. If <option>true</option> the
534 <varname>OnFailure=</varname> will be
535 enqueued in isolation mode, i.e. all
536 units that are not its dependency will
537 be stopped. If this is set only a
538 single unit may be listed in
539 <varname>OnFailure=</varname>. Defaults
541 <option>false</option>.</para></listitem>
545 <term><varname>IgnoreOnIsolate=</varname></term>
547 <listitem><para>Takes a boolean
548 argument. If <option>true</option>
549 this unit will not be stopped when
550 isolating another unit. Defaults to
551 <option>false</option>.</para></listitem>
555 <term><varname>IgnoreOnSnapshot=</varname></term>
557 <listitem><para>Takes a boolean
558 argument. If <option>true</option>
559 this unit will not be included in
560 snapshots. Defaults to
561 <option>true</option> for device and
562 snapshot units, <option>false</option>
563 for the others.</para></listitem>
567 <term><varname>StopWhenUnneeded=</varname></term>
569 <listitem><para>Takes a boolean
570 argument. If <option>true</option>
571 this unit will be stopped when it is
572 no longer used. Note that in order to
573 minimize the work to be executed,
574 systemd will not stop units by default
575 unless they are conflicting with other
576 units, or the user explicitly
577 requested their shut down. If this
578 option is set, a unit will be
579 automatically cleaned up if no other
580 active unit requires it. Defaults to
581 <option>false</option>.</para></listitem>
585 <term><varname>RefuseManualStart=</varname></term>
586 <term><varname>RefuseManualStop=</varname></term>
588 <listitem><para>Takes a boolean
589 argument. If <option>true</option>
590 this unit can only be activated
591 (resp. deactivated) indirectly. In
592 this case explicit start-up
593 (resp. termination) requested by the
594 user is denied, however if it is
595 started (resp. stopped) as a
596 dependency of another unit, start-up
597 (resp. termination) will succeed. This
598 is mostly a safety feature to ensure
599 that the user does not accidentally
600 activate units that are not intended
601 to be activated explicitly, and not
602 accidentally deactivate units that are
603 not intended to be deactivated.
604 These options default to
605 <option>false</option>.</para></listitem>
609 <term><varname>AllowIsolate=</varname></term>
611 <listitem><para>Takes a boolean
612 argument. If <option>true</option>
613 this unit may be used with the
614 <command>systemctl isolate</command>
615 command. Otherwise this will be
616 refused. It probably is a good idea to
617 leave this disabled except for target
618 units that shall be used similar to
619 runlevels in SysV init systems, just
620 as a precaution to avoid unusable
621 system states. This option defaults to
622 <option>false</option>.</para></listitem>
626 <term><varname>DefaultDependencies=</varname></term>
628 <listitem><para>Takes a boolean
629 argument. If <option>true</option>
630 (the default), a few default
631 dependencies will implicitly be
632 created for the unit. The actual
633 dependencies created depend on the
634 unit type. For example, for service
635 units, these dependencies ensure that
636 the service is started only after
637 basic system initialization is
638 completed and is properly terminated on
639 system shutdown. See the respective
640 man pages for details. Generally, only
641 services involved with early boot or
642 late shutdown should set this option
643 to <option>false</option>. It is
644 highly recommended to leave this
645 option enabled for the majority of
646 common units. If set to
647 <option>false</option> this option
648 does not disable all implicit
649 dependencies, just non-essential
650 ones.</para></listitem>
654 <term><varname>JobTimeoutSec=</varname></term>
656 <listitem><para>When clients are
657 waiting for a job of this unit to
658 complete, time out after the specified
659 time. If this time limit is reached
660 the job will be cancelled, the unit
661 however will not change state or even
662 enter the '<literal>failed</literal>'
663 mode. This value defaults to 0 (job
664 timeouts disabled), except for device
665 units. NB: this timeout is independent
666 from any unit-specific timeout (for
667 example, the timeout set with
668 <varname>Timeout=</varname> in service
669 units) as the job timeout has no
670 effect on the unit itself, only on the
671 job that might be pending for it. Or
672 in other words: unit-specific timeouts
673 are useful to abort unit state
674 changes, and revert them. The job
675 timeout set with this option however
676 is useful to abort only the job
677 waiting for the unit state to
678 change.</para></listitem>
682 <term><varname>ConditionPathExists=</varname></term>
683 <term><varname>ConditionPathExistsGlob=</varname></term>
684 <term><varname>ConditionPathIsDirectory=</varname></term>
685 <term><varname>ConditionPathIsSymbolicLink=</varname></term>
686 <term><varname>ConditionPathIsMountPoint=</varname></term>
687 <term><varname>ConditionPathIsReadWrite=</varname></term>
688 <term><varname>ConditionDirectoryNotEmpty=</varname></term>
689 <term><varname>ConditionFileIsExecutable=</varname></term>
690 <term><varname>ConditionKernelCommandLine=</varname></term>
691 <term><varname>ConditionVirtualization=</varname></term>
692 <term><varname>ConditionSecurity=</varname></term>
693 <term><varname>ConditionCapability=</varname></term>
694 <term><varname>ConditionNull=</varname></term>
696 <listitem><para>Before starting a unit
697 verify that the specified condition is
699 <varname>ConditionPathExists=</varname>
700 a file existence condition can be
701 checked before a unit is started. If
702 the specified absolute path name does
703 not exist, startup of a unit will not
704 actually happen, however the unit is
705 still useful for ordering purposes in
706 this case. The condition is checked at
707 the time the queued start job is to be
708 executed. If the absolute path name
710 <varname>ConditionPathExists=</varname>
711 is prefixed with an exclamation mark
712 (!), the test is negated, and the unit
713 is only started if the path does not
715 <varname>ConditionPathExistsGlob=</varname>
716 works in a similar way, but checks for
717 the existence of at least one file or
718 directory matching the specified
720 pattern. <varname>ConditionPathIsDirectory=</varname>
722 <varname>ConditionPathExists=</varname>
723 but verifies whether a certain path
725 directory. <varname>ConditionPathIsSymbolicLink=</varname>
727 <varname>ConditionPathExists=</varname>
728 but verifies whether a certain path
729 exists and is a symbolic
730 link. <varname>ConditionPathIsMountPoint=</varname>
732 <varname>ConditionPathExists=</varname>
733 but verifies whether a certain path
734 exists and is a mount
735 point. <varname>ConditionPathIsReadWrite=</varname>
737 <varname>ConditionPathExists=</varname>
738 but verifies whether the underlying
739 file system is read and writable
741 read-only). <varname>ConditionFileIsExecutable=</varname>
743 <varname>ConditionPathExists=</varname>
744 but verifies whether a certain path
745 exists, is a regular file and marked
747 <varname>ConditionDirectoryNotEmpty=</varname>
749 <varname>ConditionPathExists=</varname>
750 but verifies whether a certain path
751 exists and is a non-empty
753 <varname>ConditionKernelCommandLine=</varname>
754 may be used to check whether a
755 specific kernel command line option is
756 set (or if prefixed with the
757 exclamation mark unset). The argument
758 must either be a single word, or an
759 assignment (i.e. two words, separated
760 by the equality sign). In the former
761 case the kernel command line is
762 searched for the word appearing as is,
763 or as left hand side of an
764 assignment. In the latter case the
765 exact assignment is looked for with
766 right and left hand side
767 matching. <varname>ConditionVirtualization=</varname>
768 may be used to check whether the
769 system is executed in a virtualized
770 environment and optionally test
771 whether it is a specific
772 implementation. Takes either boolean
773 value to check if being executed in
774 any virtualized environment, or one of
775 <varname>vm</varname> and
776 <varname>container</varname> to test
777 against a specific type of
778 virtualization solution, or one of
779 <varname>qemu</varname>,
780 <varname>kvm</varname>,
781 <varname>vmware</varname>,
782 <varname>microsoft</varname>,
783 <varname>oracle</varname>,
784 <varname>xen</varname>,
785 <varname>bochs</varname>,
786 <varname>chroot</varname>,
787 <varname>openvz</varname>,
788 <varname>lxc</varname>,
789 <varname>lxc-libvirt</varname>,
790 <varname>systemd-nspawn</varname> to
791 test against a specific
792 implementation. If multiple
793 virtualization technologies are nested
794 only the innermost is considered. The
795 test may be negated by prepending an
797 <varname>ConditionSecurity=</varname>
798 may be used to check whether the given
799 security module is enabled on the
800 system. Currently the only recognized
801 value is <varname>selinux</varname>.
802 The test may be negated by prepending
804 mark. <varname>ConditionCapability=</varname>
805 may be used to check whether the given
806 capability exists in the capability
807 bounding set of the service manager
808 (i.e. this does not check whether
809 capability is actually available in
810 the permitted or effective sets, see
811 <citerefentry><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
812 for details). Pass a capability name
813 such as <literal>CAP_MKNOD</literal>,
814 possibly prefixed with an exclamation
815 mark to negate the check. Finally,
816 <varname>ConditionNull=</varname> may
817 be used to add a constant condition
818 check value to the unit. It takes a
819 boolean argument. If set to
820 <varname>false</varname> the condition
821 will always fail, otherwise
822 succeed. If multiple conditions are
823 specified the unit will be executed if
824 all of them apply (i.e. a logical AND
825 is applied). Condition checks can be
826 prefixed with a pipe symbol (|) in
827 which case a condition becomes a
828 triggering condition. If at least one
829 triggering condition is defined for a
830 unit then the unit will be executed if
831 at least one of the triggering
832 conditions apply and all of the
833 non-triggering conditions. If you
834 prefix an argument with the pipe
835 symbol and an exclamation mark the
836 pipe symbol must be passed first, the
837 exclamation second. Except for
838 <varname>ConditionPathIsSymbolicLink=</varname>,
839 all path checks follow
840 symlinks.</para></listitem>
844 <term><varname>Names=</varname></term>
846 <listitem><para>Additional names for
847 this unit. The names listed here must
848 have the same suffix (i.e. type) as
849 the unit file name. This option may be
850 specified more than once, in which
851 case all listed names are used. Note
852 that this option is different from the
853 <varname>Alias=</varname> option from
854 the [Install] section mentioned
855 below. See below for details. Note
856 that in almost all cases this option
857 is not what you want. A symlink alias
858 in the file system is generally
859 preferable since it can be used as
860 lookup key. If a unit with a symlinked
861 alias name is not loaded and needs to
862 be it is easily found via the
863 symlink. However, if a unit with an
864 alias name configured with this
865 setting is not loaded it will not be
866 discovered. This settings' only use is
867 in conjunction with service
873 <para>Unit file may include a [Install] section, which
874 carries installation information for the unit. This
875 section is not interpreted by
876 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
877 during runtime. It is used exclusively by the
878 <command>enable</command> and
879 <command>disable</command> commands of the
880 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
881 tool during installation of a unit:</para>
885 <term><varname>Alias=</varname></term>
887 <listitem><para>Additional names this
888 unit shall be installed under. The
889 names listed here must have the same
890 suffix (i.e. type) as the unit file
891 name. This option may be specified
892 more than once, in which case all
893 listed names are used. At installation
895 <command>systemctl enable</command>
896 will create symlinks from these names
897 to the unit file name. Note that this
898 is different from the
899 <varname>Names=</varname> option from
900 the [Unit] section mentioned above:
902 <varname>Names=</varname> apply
903 unconditionally if the unit is
904 loaded. The names from
905 <varname>Alias=</varname> apply only
906 if the unit has actually been
908 <command>systemctl enable</command>
909 command. Also, if systemd searches for a
910 unit, it will discover symlinked alias
911 names as configured with
912 <varname>Alias=</varname>, but not
913 names configured with
914 <varname>Names=</varname> only. It is
915 a common pattern to list a name in
916 both options. In this case, a unit
917 will be active under all names if
918 installed, but also if not installed
919 but requested explicitly under its
920 main name.</para></listitem>
924 <term><varname>WantedBy=</varname></term>
926 <listitem><para>Installs a symlink in
927 the <filename>.wants/</filename>
928 subdirectory for a unit. This has the
929 effect that when the listed unit name
930 is activated the unit listing it is
932 too. <command>WantedBy=foo.service</command>
934 <filename>bar.service</filename> is
936 <command>Alias=foo.service.wants/bar.service</command>
937 in the same file.</para></listitem>
941 <term><varname>Also=</varname></term>
943 <listitem><para>Additional units to
944 install when this unit is
945 installed. If the user requests
946 installation of a unit with this
948 <command>systemctl enable</command>
949 will automatically install units
950 listed in this option as
951 well.</para></listitem>
958 <title>See Also</title>
960 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
961 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
962 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
963 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
964 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
965 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
966 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
967 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
968 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
969 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
970 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
971 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
972 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
973 <citerefentry><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>