<filename>foo.service.wants/</filename> may exist. All
unit files symlinked from such a directory are
implicitly added as dependencies of type
- <varname>Wanted=</varname> to the unit. This is useful
+ <varname>Wants=</varname> to the unit. This is useful
to hook units into the start-up of other units,
without having to modify their unit files. For details
- about the semantics of <varname>Wanted=</varname>, see
+ about the semantics of <varname>Wants=</varname>, see
below. The preferred way to create symlinks in the
<filename>.wants/</filename> directory of a unit file
is with the <command>enable</command> command of the
<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
+ <term><varname>JobTimeoutAction=</varname></term>
+ <term><varname>JobTimeoutRebootArgument=</varname></term>
+
+ <listitem><para>When a job for this
+ unit is queued a time-out may be
+ configured. 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
+ <varname>StartTimeoutSec=</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
timeout set with this option however
is useful to abort only the job
waiting for the unit state to
- change.</para></listitem>
+ change.</para>
+
+ <para><varname>JobTimeoutAction=</varname>
+ optionally configures an additional
+ action to take when the time-out is
+ hit. It takes the same values as the
+ per-service
+ <varname>StartLimitAction=</varname>
+ setting, see
+ <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for details. Defaults to
+ <option>none</option>. <varname>JobTimeoutRebootArgument=</varname>
+ configures an optional reboot string
+ to pass to the
+ <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+ system call.</para></listitem>
</varlistentry>
<varlistentry>
<varname>openvz</varname>,
<varname>lxc</varname>,
<varname>lxc-libvirt</varname>,
- <varname>systemd-nspawn</varname> to
- test against a specific
- implementation. If multiple
- virtualization technologies are nested,
- only the innermost is considered. The
- test may be negated by prepending an
- exclamation mark.</para>
+ <varname>systemd-nspawn</varname>,
+ <varname>docker</varname> to test
+ against a specific implementation. See
+ <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ for a full list of known
+ virtualization technologies and their
+ identifiers. If multiple
+ virtualization technologies are
+ nested, only the innermost is
+ considered. The test may be negated by
+ prepending an exclamation mark.</para>
<para><varname>ConditionHost=</varname>
may be used to match against the