+
+ <listitem><para>Configures requirement
+ dependencies on other units. If this
+ unit gets activated, the units listed
+ here will be activated as well. If one
+ of the other units gets deactivated or
+ its activation fails, this unit will
+ be deactivated. This option may be
+ specified more than once, in which
+ case requirement dependencies for all
+ listed names are created. Note that
+ requirement dependencies do not
+ influence the order in which services
+ are started or stopped. This has to be
+ configured independently with the
+ <varname>After=</varname> or
+ <varname>Before=</varname> options. If
+ a unit
+ <filename>foo.service</filename>
+ requires a unit
+ <filename>bar.service</filename> as
+ configured with
+ <varname>Requires=</varname> and no
+ ordering is configured with
+ <varname>After=</varname> or
+ <varname>Before=</varname>, then both
+ units will be started simultaneously
+ and without any delay between them if
+ <filename>foo.service</filename> is
+ activated. Often it is a better choice
+ to use <varname>Wants=</varname>
+ instead of
+ <varname>Requires=</varname> in order
+ to achieve a system that is more
+ robust when dealing with failing
+ services.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>RequiresOverridable=</varname></term>
+
+ <listitem><para>Similar to
+ <varname>Requires=</varname>.
+ Dependencies listed in
+ <varname>RequiresOverridable=</varname>
+ which cannot be fulfilled or fail to
+ start are ignored if the startup was
+ explicitly requested by the user. If
+ the start-up was pulled in indirectly
+ by some dependency or automatic
+ start-up of units that is not
+ requested by the user this dependency
+ must be fulfilled and otherwise the
+ transaction fails. Hence, this option
+ may be used to configure dependencies
+ that are normally honored unless the
+ user explicitly starts up the unit, in
+ which case whether they failed or not
+ is irrelevant.</para></listitem>
+
+ </varlistentry>
+ <varlistentry>
+ <term><varname>Requisite=</varname></term>
+ <term><varname>RequisiteOverridable=</varname></term>
+
+ <listitem><para>Similar to
+ <varname>Requires=</varname>
+ resp. <varname>RequiresOverridable=</varname>. However,
+ if a unit listed here is not started
+ already it will not be started and the
+ transaction fails
+ immediately.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>Wants=</varname></term>
+
+ <listitem><para>A weaker version of
+ <varname>Requires=</varname>. A unit
+ listed in this option will be started
+ if the configuring unit is. However,
+ if the listed unit fails to start up
+ or cannot be added to the transaction
+ this has no impact on the validity of
+ the transaction as a whole. This is
+ the recommended way to hook start-up
+ of one unit to the start-up of another
+ unit. Note that dependencies of this
+ type may also be configured outside of
+ the unit configuration file by
+ adding a symlink to a
+ <filename>.wants/</filename> directory
+ accompanying the unit file. For
+ details see above.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>BindTo=</varname></term>
+
+ <listitem><para>Configures requirement
+ dependencies, very similar in style to
+ <varname>Requires=</varname>, however
+ in addition to this behaviour it also
+ declares that this unit is stopped
+ when any of the units listed suddenly
+ disappears. Units can suddenly,
+ unexpectedly disappear if a service
+ terminates on its own choice, a device
+ is unplugged or a mount point
+ unmounted with involvement of
+ systemd.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>Conflicts=</varname></term>
+
+ <listitem><para>Configures negative
+ requirement dependencies. If a unit
+ has a
+ <varname>Conflicts=</varname> setting
+ on another unit, starting the former
+ will stop the latter and vice
+ versa. Note that this setting is
+ independent of and orthogonal to the
+ <varname>After=</varname> and
+ <varname>Before=</varname> ordering
+ dependencies.</para>
+
+ <para>If a unit A that conflicts with
+ a unit B is scheduled to be started at
+ the same time as B, the transaction
+ will either fail (in case both are
+ required part of the transaction) or
+ be modified to be fixed (in case one
+ or both jobs are not a required part
+ of the transaction). In the latter
+ case the job that is not the required
+ will be removed, or in case both are
+ not required the unit that conflicts
+ will be started and the unit that is
+ conflicted is
+ stopped.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>Before=</varname></term>
+ <term><varname>After=</varname></term>
+
+ <listitem><para>Configures ordering
+ dependencies between units. If a unit
+ <filename>foo.service</filename>
+ contains a setting
+ <option>Before=bar.service</option>
+ and both units are being started,
+ <filename>bar.service</filename>'s
+ start-up is delayed until
+ <filename>foo.service</filename> is
+ started up. Note that this setting is
+ independent of and orthogonal to the
+ requirement dependencies as configured
+ by <varname>Requires=</varname>. It is
+ a common pattern to include a unit
+ name in both the
+ <varname>After=</varname> and
+ <varname>Requires=</varname> option in
+ which case the unit listed will be
+ started before the unit that is
+ configured with these options. This
+ option may be specified more than
+ once, in which case ordering
+ dependencies for all listed names are
+ created. <varname>After=</varname> is
+ the inverse of
+ <varname>Before=</varname>, i.e. while
+ <varname>After=</varname> ensures that
+ the configured unit is started after
+ the listed unit finished starting up,
+ <varname>Before=</varname> ensures the
+ opposite, i.e. that the configured
+ unit is fully started up before the
+ listed unit is started. Note that when
+ two units with an ordering dependency
+ between them are shut down, the
+ inverse of the start-up order is
+ applied. i.e. if a unit is configured
+ with <varname>After=</varname> on
+ another unit, the former is stopped
+ before the latter if both are shut
+ down. If one unit with an ordering
+ dependency on another unit is shut
+ down while the latter is started up,
+ the shut down is ordered before the
+ start-up regardless whether the
+ ordering dependency is actually of
+ type <varname>After=</varname> or
+ <varname>Before=</varname>. If two
+ units have no ordering dependencies
+ between them they are shut down
+ resp. started up simultaneously, and
+ no ordering takes
+ place. </para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>OnFailure=</varname></term>
+
+ <listitem><para>Lists one or more
+ units that are activated when this
+ unit enters the
+ '<literal>failed</literal>'
+ state.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>StopWhenUnneeded=</varname></term>
+
+ <listitem><para>Takes a boolean
+ argument. If <option>true</option>
+ this unit will be stopped when it is
+ no longer used. Note that in order to
+ minimize the work to be executed,
+ systemd will not stop units by default
+ unless they are conflicting with other
+ units, or the user explicitly
+ requested their shut down. If this
+ option is set, a unit will be
+ automatically cleaned up if no other
+ active unit requires it. Defaults to
+ <option>false</option>.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>RefuseManualStart=</varname></term>
+ <term><varname>RefuseManualStop=</varname></term>
+
+ <listitem><para>Takes a boolean
+ argument. If <option>true</option>
+ this unit can only be activated
+ (resp. deactivated) indirectly. In
+ this case explicit start-up
+ (resp. termination) requested by the
+ user is denied, however if it is
+ started (resp. stopped) as a
+ dependency of another unit, start-up
+ (resp. termination) will succeed. This
+ is mostly a safety feature to ensure
+ that the user does not accidentally
+ activate units that are not intended
+ to be activated explicitly, and not
+ accidentally deactivate units that are
+ not intended to be deactivated.
+ These options default to
+ <option>false</option>.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>AllowIsolate=</varname></term>
+
+ <listitem><para>Takes a boolean
+ argument. If <option>true</option>
+ this unit may be used with the
+ <command>systemctl isolate</command>
+ command. Otherwise this will be
+ refused. It probably is a good idea to
+ leave this disabled except for target
+ units that shall be used similar to
+ runlevels in SysV init systems, just
+ as a precaution to avoid unusable
+ system states. This option defaults to
+ <option>false</option>.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>DefaultDependencies=</varname></term>
+
+ <listitem><para>Takes a boolean
+ argument. If <option>true</option>
+ (the default), a few default
+ dependencies will implicitly be
+ created for the unit. The actual
+ dependencies created depend on the
+ unit type. For example, for service
+ units, these dependencies ensure that
+ the service is started only after
+ basic system initialization is
+ completed and is properly terminated on
+ system shutdown. See the respective
+ man pages for details. Generally, only
+ services involved with early boot or
+ late shutdown should set this option
+ to <option>false</option>. It is
+ highly recommended to leave this
+ option enabled for the majority of
+ common units. If set to
+ <option>false</option> this option
+ does not disable all implicit
+ dependencies, just non-essential
+ ones.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>JobTimeoutSec=</varname></term>
+
+ <listitem><para>When clients are
+ waiting for a job of this unit to
+ complete, time out after the specified
+ time. If this time limit is reached
+ the job will be cancelled, the unit
+ however will not change state or even
+ enter the '<literal>failed</literal>'
+ mode. This value defaults to 0 (job
+ timeouts disabled), except for device
+ units. NB: this timeout is independent
+ from any unit-specific timeout (for
+ example, the timeout set with
+ <varname>Timeout=</varname> in service
+ units) as the job timeout has no
+ effect on the unit itself, only on the
+ job that might be pending for it. Or
+ in other words: unit-specific timeouts
+ are useful to abort unit state
+ changes, and revert them. The job
+ timeout set with this option however
+ is useful to abort only the job
+ waiting for the unit state to
+ change.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>ConditionPathExists=</varname></term>
+ <term><varname>ConditionKernelCommandLine=</varname></term>
+ <term><varname>ConditionNull=</varname></term>
+
+ <listitem><para>Before starting a unit
+ verify that the specified condition is
+ true. With
+ <varname>ConditionPathExists=</varname>
+ a file existance condition can be
+ checked before a unit is started. If
+ the specified absolute path name does
+ not exist startup of a unit will not
+ actually happen, however the unit is
+ still useful for ordering purposes in
+ this case. The condition is checked at
+ the time the queued start job is to be
+ executed. If the absolute path name
+ passed to
+ <varname>ConditionPathExists=</varname>
+ is prefixed with an exclamation mark
+ (!), the test is negated, and the unit
+ only started if the path does not
+ exist. Similarly
+ <varname>ConditionKernelCommandLine=</varname>
+ may be used to check whether a
+ specific kernel command line option is
+ set (or if prefixed with the
+ exclamation mark unset). The argument
+ must either be a single word, or an
+ assignment (i.e. two words, seperated
+ by the equality sign). In the former
+ case the kernel command line is
+ searched for the word appearing as is,
+ or as left hand side of an
+ assignment. In the latter case the
+ exact assignment is looked for with
+ right and left hand side
+ matching. Finally,
+ <varname>ConditionNull=</varname> may
+ be used to add a constant condition
+ check value to the unit. It takes a
+ boolean argument. If set to
+ <varname>false</varname> the condition
+ will always fail, otherwise
+ succeed. If multiple conditions are
+ specified the unit will be executed
+ iff at least one of them applies
+ (i.e. a logical OR is
+ applied).</para></listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>Unit file may include a [Install] section, which
+ carries installation information for the unit. This
+ section is not interpreted by
+ <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ during runtime. It is used exclusively by the
+ <command>enable</command> and
+ <command>disable</command> commands of the
+ <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ tool during installation of a unit:</para>
+
+ <variablelist>
+ <varlistentry>
+ <term><varname>Alias=</varname></term>
+
+ <listitem><para>Additional names this
+ unit shall be installed under. The
+ names listed here must have the same
+ suffix (i.e. type) as the unit file
+ name. This option may be specified
+ more than once, in which case all
+ listed names are used. At installation
+ time,
+ <command>systemctl enable</command>
+ will create symlinks from these names
+ to the unit file name. Note that this
+ is different from the
+ <varname>Names=</varname> option from
+ the [Unit] section mentioned above:
+ The names from
+ <varname>Names=</varname> apply
+ unconditionally if the unit is
+ loaded. The names from
+ <varname>Alias=</varname> apply only
+ if the unit has actually been
+ installed with the
+ <command>systemctl enable</command>
+ command. Also, if systemd searches for a
+ unit, it will discover symlinked alias
+ names as configured with
+ <varname>Alias=</varname>, but not
+ names configured with
+ <varname>Names=</varname> only. It is
+ a common pattern to list a name in
+ both options. In this case, a unit
+ will be active under all names if
+ installed, but also if not installed
+ but requested explicitly under its
+ main name.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>WantedBy=</varname></term>
+
+ <listitem><para>Installs a symlink in
+ the <filename>.wants/</filename>
+ subdirectory for a unit. This has the
+ effect that when the listed unit name
+ is activated the unit listing it is
+ activated
+ too. <command>WantedBy=foo.service</command>
+ in a service
+ <filename>bar.service</filename> is
+ mostly equivalent to
+ <command>Alias=foo.service.wants/bar.service</command>
+ in the same file.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>Also=</varname></term>
+
+ <listitem><para>Additional units to
+ install when this unit is
+ installed. If the user requests
+ installation of a unit with this
+ option configured,
+ <command>systemctl enable</command>
+ will automatically install units
+ listed in this option as
+ well.</para></listitem>