<para><literallayout><filename>$XDG_CONFIG_HOME/systemd/user/*</filename>
<filename>$HOME/.config/systemd/user/*</filename>
<filename>/etc/systemd/user/*</filename>
+<filename>$XDG_RUNTIME_DIR/systemd/user/*</filename>
<filename>/run/systemd/user/*</filename>
<filename>$XDG_DATA_HOME/systemd/user/*</filename>
<filename>$HOME/.local/share/systemd/user/*</filename>
<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
template <literal>.d/</literal> subdirectory and reads
its <literal>.conf</literal> files.</para>
+ <!-- Note that we do not document .include here, as we
+ consider it mostly obsolete, and want people to
+ use .d/ drop-ins instead. -->
+
<para>Note that while systemd offers a flexible
dependency system between units it is recommended to
use this functionality only sparingly and instead rely
the file system namespace. If this applies, a special
way to escape the path name is used, so that the
result is usable as part of a filename. Basically,
- given a path, "/" is replaced by "-", and all
- unprintable characters and the "-" are replaced by
- C-style "\x20" escapes. The root directory "/" is
- encoded as single dash, while otherwise the initial
- and ending "/" is removed from all paths during
- transformation. This escaping is reversible.</para>
+ given a path, "/" is replaced by "-" and all other
+ characters which are not ASCII alphanumerics are
+ replaced by C-style "\x2d" escapes (except that "_"
+ is never replaced and "." is only replaced when it
+ would be the first character in the escaped path).
+ The root directory "/" is encoded as single dash,
+ while otherwise the initial and ending "/" are removed
+ from all paths during transformation. This escaping
+ is reversible. Properly escaped paths can be generated
+ using the <citerefentry><refentrytitle>systemd-escape</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ command.</para>
<para>Optionally, units may be instantiated from a
template file at runtime. This allows creation of
<entry><filename>/etc/systemd/user</filename></entry>
<entry>Local configuration</entry>
</row>
+ <row>
+ <entry><filename>$XDG_RUNTIME_DIR/systemd/user</filename></entry>
+ <entry>Runtime units (only used when $XDG_RUNTIME_DIR is set)</entry>
+ </row>
<row>
<entry><filename>/run/systemd/user</filename></entry>
<entry>Runtime units</entry>
<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>
<term><varname>ConditionDirectoryNotEmpty=</varname></term>
<term><varname>ConditionFileNotEmpty=</varname></term>
<term><varname>ConditionFileIsExecutable=</varname></term>
- <term><varname>ConditionNull=</varname></term>
+
+ <!-- We don't document ConditionNull=
+ here as it is not particularly
+ useful and probably just
+ confusing. -->
<listitem><para>Before starting a unit
verify that the specified condition is
<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
<para><varname>ConditionSecurity=</varname>
may be used to check whether the given
security module is enabled on the
- system. Currently the recognized values
- values are <varname>selinux</varname>,
+ system. Currently the recognized
+ values values are
+ <varname>selinux</varname>,
<varname>apparmor</varname>,
- <varname>ima</varname> and
- <varname>smack</varname>.
- The test may be negated by prepending
- an exclamation
- mark.</para>
+ <varname>ima</varname>,
+ <varname>smack</varname> and
+ <varname>audit</varname>. The test may
+ be negated by prepending an
+ exclamation mark.</para>
<para><varname>ConditionCapability=</varname>
may be used to check whether the given
exists, is a regular file and marked
executable.</para>
- <para>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.</para>
-
<para>If multiple conditions are
specified, the unit will be executed if
all of them apply (i.e. a logical AND
have no effect.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>AssertArchitecture=</varname></term>
+ <term><varname>AssertVirtualization=</varname></term>
+ <term><varname>AssertHost=</varname></term>
+ <term><varname>AssertKernelCommandLine=</varname></term>
+ <term><varname>AssertSecurity=</varname></term>
+ <term><varname>AssertCapability=</varname></term>
+ <term><varname>AssertACPower=</varname></term>
+ <term><varname>AssertNeedsUpdate=</varname></term>
+ <term><varname>AssertFirstBoot=</varname></term>
+ <term><varname>AssertPathExists=</varname></term>
+ <term><varname>AssertPathExistsGlob=</varname></term>
+ <term><varname>AssertPathIsDirectory=</varname></term>
+ <term><varname>AssertPathIsSymbolicLink=</varname></term>
+ <term><varname>AssertPathIsMountPoint=</varname></term>
+ <term><varname>AssertPathIsReadWrite=</varname></term>
+ <term><varname>AssertDirectoryNotEmpty=</varname></term>
+ <term><varname>AssertFileNotEmpty=</varname></term>
+ <term><varname>AssertFileIsExecutable=</varname></term>
+
+ <listitem><para>Similar to the
+ <varname>ConditionArchitecture=</varname>,
+ <varname>ConditionVirtualization=</varname>,
+ ... condition settings described above
+ these settings add assertion checks to
+ the start-up of the unit. However,
+ unlike the conditions settings any
+ assertion setting that is not met
+ results in failure of the start
+ job it was triggered by.</para></listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>SourcePath=</varname></term>
<listitem><para>A path to a
</tbody>
</tgroup>
</table>
+
+ <para>Please note that specifiers
+ <literal>%U</literal>, <literal>%h</literal>,
+ <literal>%s</literal> are mostly useless when systemd
+ is running in system mode. PID 1 cannot query the
+ user account database for information, so the
+ specifiers only work as shortcuts for things which are
+ already specified in a different way in the unit
+ file. They are fully functional when systemd is
+ running in <option>--user</option> mode.</para>
</refsect1>
<refsect1>
<citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd-verify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
<citerefentry><refentrytitle>uname</refentrytitle><manvolnum>1</manvolnum></citerefentry>
~ianmdlvl / elogind.git / blobdiff