services.</para></listitem>
</varlistentry>
-
<varlistentry>
<term><varname>RequiresOverridable=</varname></term>
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 without involvement of
+ systemd.</para></listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>Conflicts=</varname></term>
state.</para></listitem>
</varlistentry>
- <varlistentry>
- <term><varname>StopRetroactively=</varname></term>
-
- <listitem><para>Takes a boolean
- argument. If <option>true</option> and
- a unit this unit requires stops
- without this being requested by the
- user, this unit will be stopped as
- well. (e.g. if a service exits or
- crashes on its own behalf, units this
- flag is set for that require it will
- be stopped.) Note that normally if a
- unit stops without a user request,
- units depending on it will not be
- terminated. Only if the user requested
- shutdown of a unit, all units
- depending on that unit will be shut
- down as well and at the same
- time. Defaults to
- <option>false</option>.</para></listitem>
- </varlistentry>
-
<varlistentry>
<term><varname>StopWhenUnneeded=</varname></term>
ones.</para></listitem>
</varlistentry>
- <varlistentry>
- <term><varname>IgnoreDependencyFailure=</varname></term>
-
- <listitem><para>Takes a boolean
- argument. If <option>true</option> and
- a requirement dependency of this unit
- fails to start up this unit will be
- started nonetheless, ignoring that
- failure. If <option>false</option>
- (the default) and a dependency unit
- fails the unit will immediately fail
- too and the job is removed.</para></listitem>
- </varlistentry>
-
<varlistentry>
<term><varname>JobTimeoutSec=</varname></term>
<varlistentry>
<term><varname>ConditionPathExists=</varname></term>
+ <term><varname>ConditionDirectoryNotEmpty=</varname></term>
<term><varname>ConditionKernelCommandLine=</varname></term>
+ <term><varname>ConditionNull=</varname></term>
<listitem><para>Before starting a unit
verify that the specified condition is
is prefixed with an exclamation mark
(!), the test is negated, and the unit
only started if the path does not
- exist. Similarly
+ exist. <varname>ConditionDirectoryNotEmpty=</varname>
+ is similar to
+ <varname>ConditionPathExists=</varname>
+ but verifies whether a certain path is
+ exists and is a non-empty
+ directory. 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
+ assignment (i.e. two words, separated
by the equality sign). In the former
- case the kernel command line is search
- 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. If multiple conditions
- are specified the unit will be
- executed iff at least one of them
- apply (i.e. a logical OR is
+ 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
+ if at least one of them applies
+ (i.e. a logical OR is
applied).</para></listitem>
</varlistentry>
</variablelist>