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 General Public License as published by
12 the Free Software Foundation; either version 2 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 General Public License for more details.
20 You should have received a copy of the GNU 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 read as if its contents were listed in place of the
125 <option>.include</option> directive.</para>
127 <para>Along with a unit file
128 <filename>foo.service</filename> a directory
129 <filename>foo.service.wants/</filename> may exist. All
130 units symlinked from such a directory are implicitly
131 added as dependencies of type
132 <varname>Wanted=</varname> to the unit. This is useful
133 to hook units into the start-up of other units,
134 without having to modify their unit configuration
135 files. For details about the semantics of
136 <varname>Wanted=</varname> see below. The preferred
137 way to create symlinks in the
138 <filename>.wants/</filename> directory of a service is
139 with the <command>enable</command> command of the
140 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
141 tool which reads information from the [Install]
142 section of unit files. (See below.) A similar
143 functionality exists for <varname>Requires=</varname>
144 type dependencies as well, the directory suffix is
145 <filename>.requires/</filename> in this case.</para>
147 <para>Note that while systemd offers a flexible
148 dependency system between units it is recommended to
149 use this functionality only sparsely and instead rely
150 on techniques such as bus-based or socket-based
151 activation which makes dependencies implicit, which
152 both results in a simpler and more flexible
155 <para>Some unit names reflect paths existing in the
156 file system name space. Example: a device unit
157 <filename>dev-sda.device</filename> refers to a device
158 with the device node <filename>/dev/sda</filename> in
159 the file system namespace. If this applies a special
160 way to escape the path name is used, so that the
161 result is usable as part of a file name. Basically,
162 given a path, "/" is replaced by "-", and all
163 unprintable characters and the "-" are replaced by
164 C-style "\x20" escapes. The root directory "/" is
165 encoded as single dash, while otherwise the initial
166 and ending "/" is removed from all paths during
167 transformation. This escaping is reversible.</para>
169 <para>Optionally, units may be instantiated from a
170 template file at runtime. This allows creation of
171 multiple units from a single configuration file. If
172 systemd looks for a unit configuration file it will
173 first search for the literal unit name in the
174 filesystem. If that yields no success and the unit
175 name contains an @ character, systemd will look for a
176 unit template that shares the same name but with the
177 instance string (i.e. the part between the @ character
178 and the suffix) removed. Example: if a service
179 <filename>getty@tty3.service</filename> is requested
180 and no file by that name is found, systemd will look
181 for <filename>getty@.service</filename> and
182 instantiate a service from that configuration file if
183 it is found. To refer to the instance string from
184 within the configuration file you may use the special
185 <literal>%i</literal> specifier in many of the
186 configuration options. Other specifiers that may be
187 used are <literal>%n</literal>, <literal>%N</literal>,
188 <literal>%p</literal>, <literal>%P</literal>,
189 <literal>%I</literal>, <literal>%f</literal>,
190 <literal>%c</literal>, <literal>%r</literal>,
191 <literal>%R</literal> and <literal>%t</literal> for
192 the full unit name, the unescaped unit name, the
193 prefix name, the unescaped prefix name, the unescaped
194 instance name, the unescaped filename, the control
195 group path of the unit, the root control group path of
196 systemd, and the parent directory of the root control
197 cgroup path of systemd and the runtime socket dir,
198 respectively. The unescaped filename is either the
199 unescaped instance name (if set) with / prepended (if
200 necessary), or the prefix name similarly prepended
201 with /. The prefix name here refers to the string
202 before the @, i.e. "getty" in the example above, where
203 "tty3" is the instance name. The runtime socket
204 directory is either <filename>/run</filename> (for the
205 system manager) or <literal>$XDG_RUNTIME_DIR</literal>
206 (for user managers).</para>
208 <para>If a unit file is empty (i.e. has the file size
209 0) or is symlinked to <filename>/dev/null</filename>
210 its configuration will not be loaded and it appears
211 with a load state of <literal>masked</literal>, and
212 cannot be activated. Use this as an effective way to
213 fully disable a unit, making it impossible to start it
214 even manually.</para>
216 <para>The unit file format is covered by the
218 url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
219 Stability Promise</ulink>.</para>
223 <title>Options</title>
225 <para>Unit file may include a [Unit] section, which
226 carries generic information about the unit that is not
227 dependent on the type of unit:</para>
232 <term><varname>Description=</varname></term>
233 <listitem><para>A free-form string
234 describing the unit. This is intended
235 for use in UIs to show descriptive
236 information along with the unit
237 name.</para></listitem>
241 <term><varname>Requires=</varname></term>
243 <listitem><para>Configures requirement
244 dependencies on other units. If this
245 unit gets activated, the units listed
246 here will be activated as well. If one
247 of the other units gets deactivated or
248 its activation fails, this unit will
249 be deactivated. This option may be
250 specified more than once, in which
251 case requirement dependencies for all
252 listed names are created. Note that
253 requirement dependencies do not
254 influence the order in which services
255 are started or stopped. This has to be
256 configured independently with the
257 <varname>After=</varname> or
258 <varname>Before=</varname> options. If
260 <filename>foo.service</filename>
262 <filename>bar.service</filename> as
264 <varname>Requires=</varname> and no
265 ordering is configured with
266 <varname>After=</varname> or
267 <varname>Before=</varname>, then both
268 units will be started simultaneously
269 and without any delay between them if
270 <filename>foo.service</filename> is
271 activated. Often it is a better choice
272 to use <varname>Wants=</varname>
274 <varname>Requires=</varname> in order
275 to achieve a system that is more
276 robust when dealing with failing
277 services.</para></listitem>
281 <term><varname>RequiresOverridable=</varname></term>
283 <listitem><para>Similar to
284 <varname>Requires=</varname>.
285 Dependencies listed in
286 <varname>RequiresOverridable=</varname>
287 which cannot be fulfilled or fail to
288 start are ignored if the startup was
289 explicitly requested by the user. If
290 the start-up was pulled in indirectly
291 by some dependency or automatic
292 start-up of units that is not
293 requested by the user this dependency
294 must be fulfilled and otherwise the
295 transaction fails. Hence, this option
296 may be used to configure dependencies
297 that are normally honored unless the
298 user explicitly starts up the unit, in
299 which case whether they failed or not
300 is irrelevant.</para></listitem>
304 <term><varname>Requisite=</varname></term>
305 <term><varname>RequisiteOverridable=</varname></term>
307 <listitem><para>Similar to
308 <varname>Requires=</varname>
309 resp. <varname>RequiresOverridable=</varname>. However,
310 if a unit listed here is not started
311 already it will not be started and the
313 immediately.</para></listitem>
317 <term><varname>Wants=</varname></term>
319 <listitem><para>A weaker version of
320 <varname>Requires=</varname>. A unit
321 listed in this option will be started
322 if the configuring unit is. However,
323 if the listed unit fails to start up
324 or cannot be added to the transaction
325 this has no impact on the validity of
326 the transaction as a whole. This is
327 the recommended way to hook start-up
328 of one unit to the start-up of another
329 unit. Note that dependencies of this
330 type may also be configured outside of
331 the unit configuration file by
332 adding a symlink to a
333 <filename>.wants/</filename> directory
334 accompanying the unit file. For
335 details see above.</para></listitem>
339 <term><varname>BindTo=</varname></term>
341 <listitem><para>Configures requirement
342 dependencies, very similar in style to
343 <varname>Requires=</varname>, however
344 in addition to this behaviour it also
345 declares that this unit is stopped
346 when any of the units listed suddenly
347 disappears. Units can suddenly,
348 unexpectedly disappear if a service
349 terminates on its own choice, a device
350 is unplugged or a mount point
351 unmounted without involvement of
352 systemd.</para></listitem>
356 <term><varname>Conflicts=</varname></term>
358 <listitem><para>Configures negative
359 requirement dependencies. If a unit
361 <varname>Conflicts=</varname> setting
362 on another unit, starting the former
363 will stop the latter and vice
364 versa. Note that this setting is
365 independent of and orthogonal to the
366 <varname>After=</varname> and
367 <varname>Before=</varname> ordering
370 <para>If a unit A that conflicts with
371 a unit B is scheduled to be started at
372 the same time as B, the transaction
373 will either fail (in case both are
374 required part of the transaction) or
375 be modified to be fixed (in case one
376 or both jobs are not a required part
377 of the transaction). In the latter
378 case the job that is not the required
379 will be removed, or in case both are
380 not required the unit that conflicts
381 will be started and the unit that is
383 stopped.</para></listitem>
387 <term><varname>Before=</varname></term>
388 <term><varname>After=</varname></term>
390 <listitem><para>Configures ordering
391 dependencies between units. If a unit
392 <filename>foo.service</filename>
394 <option>Before=bar.service</option>
395 and both units are being started,
396 <filename>bar.service</filename>'s
397 start-up is delayed until
398 <filename>foo.service</filename> is
399 started up. Note that this setting is
400 independent of and orthogonal to the
401 requirement dependencies as configured
402 by <varname>Requires=</varname>. It is
403 a common pattern to include a unit
405 <varname>After=</varname> and
406 <varname>Requires=</varname> option in
407 which case the unit listed will be
408 started before the unit that is
409 configured with these options. This
410 option may be specified more than
411 once, in which case ordering
412 dependencies for all listed names are
413 created. <varname>After=</varname> is
415 <varname>Before=</varname>, i.e. while
416 <varname>After=</varname> ensures that
417 the configured unit is started after
418 the listed unit finished starting up,
419 <varname>Before=</varname> ensures the
420 opposite, i.e. that the configured
421 unit is fully started up before the
422 listed unit is started. Note that when
423 two units with an ordering dependency
424 between them are shut down, the
425 inverse of the start-up order is
426 applied. i.e. if a unit is configured
427 with <varname>After=</varname> on
428 another unit, the former is stopped
429 before the latter if both are shut
430 down. If one unit with an ordering
431 dependency on another unit is shut
432 down while the latter is started up,
433 the shut down is ordered before the
434 start-up regardless whether the
435 ordering dependency is actually of
436 type <varname>After=</varname> or
437 <varname>Before=</varname>. If two
438 units have no ordering dependencies
439 between them they are shut down
440 resp. started up simultaneously, and
442 place. </para></listitem>
446 <term><varname>OnFailure=</varname></term>
448 <listitem><para>Lists one or more
449 units that are activated when this
451 '<literal>failed</literal>'
452 state.</para></listitem>
456 <term><varname>OnFailureIsolate=</varname></term>
458 <listitem><para>Takes a boolean
459 argument. If <option>true</option> the
461 <varname>OnFailure=</varname> will be
462 enqueued in isolation mode, i.e. all
463 units that are not its dependency will
464 be stopped. If this is set only a
465 single unit may be listed in
466 <varname>OnFailure=</varname>. Defaults
468 <option>false</option>.</para></listitem>
472 <term><varname>IgnoreOnIsolate=</varname></term>
474 <listitem><para>Takes a boolean
475 argument. If <option>true</option>
476 this unit will not be stopped when
477 isolating another unit. Defaults to
478 <option>false</option>.</para></listitem>
482 <term><varname>IgnoreOnSnapshot=</varname></term>
484 <listitem><para>Takes a boolean
485 argument. If <option>true</option>
486 this unit will not be included in
487 snapshots. Defaults to
488 <option>true</option> for device and
489 snapshot units, <option>false</option>
490 for the others.</para></listitem>
494 <term><varname>StopWhenUnneeded=</varname></term>
496 <listitem><para>Takes a boolean
497 argument. If <option>true</option>
498 this unit will be stopped when it is
499 no longer used. Note that in order to
500 minimize the work to be executed,
501 systemd will not stop units by default
502 unless they are conflicting with other
503 units, or the user explicitly
504 requested their shut down. If this
505 option is set, a unit will be
506 automatically cleaned up if no other
507 active unit requires it. Defaults to
508 <option>false</option>.</para></listitem>
512 <term><varname>RefuseManualStart=</varname></term>
513 <term><varname>RefuseManualStop=</varname></term>
515 <listitem><para>Takes a boolean
516 argument. If <option>true</option>
517 this unit can only be activated
518 (resp. deactivated) indirectly. In
519 this case explicit start-up
520 (resp. termination) requested by the
521 user is denied, however if it is
522 started (resp. stopped) as a
523 dependency of another unit, start-up
524 (resp. termination) will succeed. This
525 is mostly a safety feature to ensure
526 that the user does not accidentally
527 activate units that are not intended
528 to be activated explicitly, and not
529 accidentally deactivate units that are
530 not intended to be deactivated.
531 These options default to
532 <option>false</option>.</para></listitem>
536 <term><varname>AllowIsolate=</varname></term>
538 <listitem><para>Takes a boolean
539 argument. If <option>true</option>
540 this unit may be used with the
541 <command>systemctl isolate</command>
542 command. Otherwise this will be
543 refused. It probably is a good idea to
544 leave this disabled except for target
545 units that shall be used similar to
546 runlevels in SysV init systems, just
547 as a precaution to avoid unusable
548 system states. This option defaults to
549 <option>false</option>.</para></listitem>
553 <term><varname>DefaultDependencies=</varname></term>
555 <listitem><para>Takes a boolean
556 argument. If <option>true</option>
557 (the default), a few default
558 dependencies will implicitly be
559 created for the unit. The actual
560 dependencies created depend on the
561 unit type. For example, for service
562 units, these dependencies ensure that
563 the service is started only after
564 basic system initialization is
565 completed and is properly terminated on
566 system shutdown. See the respective
567 man pages for details. Generally, only
568 services involved with early boot or
569 late shutdown should set this option
570 to <option>false</option>. It is
571 highly recommended to leave this
572 option enabled for the majority of
573 common units. If set to
574 <option>false</option> this option
575 does not disable all implicit
576 dependencies, just non-essential
577 ones.</para></listitem>
581 <term><varname>JobTimeoutSec=</varname></term>
583 <listitem><para>When clients are
584 waiting for a job of this unit to
585 complete, time out after the specified
586 time. If this time limit is reached
587 the job will be cancelled, the unit
588 however will not change state or even
589 enter the '<literal>failed</literal>'
590 mode. This value defaults to 0 (job
591 timeouts disabled), except for device
592 units. NB: this timeout is independent
593 from any unit-specific timeout (for
594 example, the timeout set with
595 <varname>Timeout=</varname> in service
596 units) as the job timeout has no
597 effect on the unit itself, only on the
598 job that might be pending for it. Or
599 in other words: unit-specific timeouts
600 are useful to abort unit state
601 changes, and revert them. The job
602 timeout set with this option however
603 is useful to abort only the job
604 waiting for the unit state to
605 change.</para></listitem>
609 <term><varname>ConditionPathExists=</varname></term>
610 <term><varname>ConditionPathExistsGlob=</varname></term>
611 <term><varname>ConditionPathIsDirectory=</varname></term>
612 <term><varname>ConditionDirectoryNotEmpty=</varname></term>
613 <term><varname>ConditionFileIsExecutable=</varname></term>
614 <term><varname>ConditionKernelCommandLine=</varname></term>
615 <term><varname>ConditionVirtualization=</varname></term>
616 <term><varname>ConditionSecurity=</varname></term>
617 <term><varname>ConditionNull=</varname></term>
619 <listitem><para>Before starting a unit
620 verify that the specified condition is
622 <varname>ConditionPathExists=</varname>
623 a file existence condition can be
624 checked before a unit is started. If
625 the specified absolute path name does
626 not exist startup of a unit will not
627 actually happen, however the unit is
628 still useful for ordering purposes in
629 this case. The condition is checked at
630 the time the queued start job is to be
631 executed. If the absolute path name
633 <varname>ConditionPathExists=</varname>
634 is prefixed with an exclamation mark
635 (!), the test is negated, and the unit
636 only started if the path does not
637 exist. <varname>ConditionPathExistsGlob=</varname>
638 work in a similar way, but checks for
639 the existance of at least one file or
640 directory matching the specified
642 pattern. <varname>ConditionPathIsDirectory=</varname>
644 <varname>ConditionPathExists=</varname>
645 but verifies whether a certain path
647 directory. <varname>ConditionFileIsExecutable=</varname>
649 <varname>ConditionPathExists=</varname>
650 but verifies whether a certain path
651 exists, is a regular file and marked
653 <varname>ConditionDirectoryNotEmpty=</varname>
655 <varname>ConditionPathExists=</varname>
656 but verifies whether a certain path
657 exists and is a non-empty
659 <varname>ConditionKernelCommandLine=</varname>
660 may be used to check whether a
661 specific kernel command line option is
662 set (or if prefixed with the
663 exclamation mark unset). The argument
664 must either be a single word, or an
665 assignment (i.e. two words, separated
666 by the equality sign). In the former
667 case the kernel command line is
668 searched for the word appearing as is,
669 or as left hand side of an
670 assignment. In the latter case the
671 exact assignment is looked for with
672 right and left hand side
673 matching. <varname>ConditionVirtualization=</varname>
674 may be used to check whether the
675 system is executed in a virtualized
676 environment and optionally test
677 whether it is a specific
678 implementation. Takes either boolean
679 value to check if being executed in
680 any virtual environment or one of the
681 <varname>qemu</varname>,
682 <varname>kvm</varname>,
683 <varname>vmware</varname>,
684 <varname>microsoft</varname>,
685 <varname>oracle</varname>,
686 <varname>xen</varname>,
687 <varname>pidns</varname>,
688 <varname>openvz</varname> to test
689 against a specific implementation. The
690 test may be negated by prepending an
692 <varname>ConditionSecurity=</varname>
693 may be used to check whether the given
694 security module is enabled on the
695 system. Currently the only recognized
696 value is <varname>selinux</varname>.
697 The test may be negated by prepending
698 an exclamation mark. Finally,
699 <varname>ConditionNull=</varname> may
700 be used to add a constant condition
701 check value to the unit. It takes a
702 boolean argument. If set to
703 <varname>false</varname> the condition
704 will always fail, otherwise
705 succeed. If multiple conditions are
706 specified the unit will be executed if
707 all of them apply (i.e. a logical AND
708 is applied). Condition checks can be
709 prefixed with a pipe symbol (|) in
710 which case a condition becomes a
711 triggering condition. If at least one
712 triggering condition is defined for a
713 unit then the unit will be executed if
714 at least one of the triggering
715 conditions apply and all of the
716 non-triggering conditions. If you
717 prefix an argument with the pipe
718 symbol and an exclamation mark the
719 pipe symbol must be passed first, the
720 exclamation second.</para></listitem>
724 <term><varname>Names=</varname></term>
726 <listitem><para>Additional names for
727 this unit. The names listed here must
728 have the same suffix (i.e. type) as
729 the unit file name. This option may be
730 specified more than once, in which
731 case all listed names are used. Note
732 that this option is different from the
733 <varname>Alias=</varname> option from
734 the [Install] section mentioned
735 below. See below for details. Note
736 that in almost all cases this option
737 is not what you want. A symlink alias
738 in the file system is generally
739 preferable since it can be used as
740 lookup key. If a unit with a symlinked
741 alias name is not loaded and needs to
742 be it is easily found via the
743 symlink. However, if a unit with an
744 alias name configured with this
745 setting is not loaded it will not be
746 discovered. This settings' only use is
747 in conjunction with service
753 <para>Unit file may include a [Install] section, which
754 carries installation information for the unit. This
755 section is not interpreted by
756 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
757 during runtime. It is used exclusively by the
758 <command>enable</command> and
759 <command>disable</command> commands of the
760 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
761 tool during installation of a unit:</para>
765 <term><varname>Alias=</varname></term>
767 <listitem><para>Additional names this
768 unit shall be installed under. The
769 names listed here must have the same
770 suffix (i.e. type) as the unit file
771 name. This option may be specified
772 more than once, in which case all
773 listed names are used. At installation
775 <command>systemctl enable</command>
776 will create symlinks from these names
777 to the unit file name. Note that this
778 is different from the
779 <varname>Names=</varname> option from
780 the [Unit] section mentioned above:
782 <varname>Names=</varname> apply
783 unconditionally if the unit is
784 loaded. The names from
785 <varname>Alias=</varname> apply only
786 if the unit has actually been
788 <command>systemctl enable</command>
789 command. Also, if systemd searches for a
790 unit, it will discover symlinked alias
791 names as configured with
792 <varname>Alias=</varname>, but not
793 names configured with
794 <varname>Names=</varname> only. It is
795 a common pattern to list a name in
796 both options. In this case, a unit
797 will be active under all names if
798 installed, but also if not installed
799 but requested explicitly under its
800 main name.</para></listitem>
804 <term><varname>WantedBy=</varname></term>
806 <listitem><para>Installs a symlink in
807 the <filename>.wants/</filename>
808 subdirectory for a unit. This has the
809 effect that when the listed unit name
810 is activated the unit listing it is
812 too. <command>WantedBy=foo.service</command>
814 <filename>bar.service</filename> is
816 <command>Alias=foo.service.wants/bar.service</command>
817 in the same file.</para></listitem>
821 <term><varname>Also=</varname></term>
823 <listitem><para>Additional units to
824 install when this unit is
825 installed. If the user requests
826 installation of a unit with this
828 <command>systemctl enable</command>
829 will automatically install units
830 listed in this option as
831 well.</para></listitem>
838 <title>See Also</title>
840 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
841 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
842 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
843 <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
844 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
845 <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
846 <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
847 <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
848 <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
849 <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
850 <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
851 <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
852 <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>
~ianmdlvl / elogind.git / blob