<filename>...</filename>
</literallayout></para>
- <para><literallayout><filename>$HOME/.config/systemd/user/*</filename>
+ <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>/usr/lib/systemd/user/*</filename>
<filename>...</filename>
</literallayout></para>
<para>Unit files may contain additional options on top
of those listed here. If systemd encounters an unknown
option, it will write a warning log message but
- continue loading the unit. If an option is prefixed
- with <option>X-</option>, it is ignored completely by
- systemd. Applications may use this to include
- additional information in the unit files.</para>
+ continue loading the unit. If an option or section name
+ is prefixed with <option>X-</option>, it is ignored
+ completely by systemd. Options within an ignored
+ section do not need the prefix. Applications may use
+ this to include additional information in the unit
+ files.</para>
<para>Boolean arguments used in unit files can be
written in various formats. For positive settings the
<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
settings to a unit, without having to modify their
unit files. Make sure that the file that is included
has the appropriate section headers before any
- directive.</para>
-
- <para>If a line starts with <option>.include</option>
- followed by a filename, the specified file will be
- parsed at this point. Make sure that the file that is
- included has the appropriate section headers before
- any directives.</para>
+ directive. Note that for instanced units this logic
+ will first look for the instance
+ <literal>.d/</literal> subdirectory and read its
+ <literal>.conf</literal> files, followed by the
+ template <literal>.d/</literal> subdirectory and reads
+ its <literal>.conf</literal> files.</para>
<para>Note that while systemd offers a flexible
dependency system between units it is recommended to
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
+ C-style "\x2d" 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>
multiple units from a single configuration file. If
systemd looks for a unit configuration file, it will
first search for the literal unit name in the
- filesystem. If that yields no success and the unit
+ file system. If that yields no success and the unit
name contains an <literal>@</literal> character, systemd will look for a
unit template that shares the same name but with the
instance string (i.e. the part between the <literal>@</literal> character
(<option>--user</option>) and the variable
<varname>$SYSTEMD_UNIT_PATH</varname> is set, this
contents of this variable overrides the unit load
- path.
- </para>
+ path. If <varname>$SYSTEMD_UNIT_PATH</varname> ends
+ with an empty component (<literal>:</literal>), the
+ usual unit load path will be appended to the contents
+ of the variable.</para>
<table>
<title>
</row>
</thead>
<tbody>
+ <row>
+ <entry><filename>$XDG_CONFIG_HOME/systemd/user</filename></entry>
+ <entry>User configuration (only used when $XDG_CONFIG_HOME is set)</entry>
+ </row>
<row>
<entry><filename>$HOME/.config/systemd/user</filename></entry>
- <entry>User configuration</entry>
+ <entry>User configuration (only used when $XDG_CONFIG_HOME is not set)</entry>
</row>
<row>
<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>
</row>
+ <row>
+ <entry><filename>$XDG_DATA_HOME/systemd/user</filename></entry>
+ <entry>Units of packages that have been installed in the home directory (only used when $XDG_DATA_HOME is set)</entry>
+ </row>
+ <row>
+ <entry><filename>$HOME/.local/share/systemd/user</filename></entry>
+ <entry>Units of packages that have been installed in the home directory (only used when $XDG_DATA_HOME is not set)</entry>
+ </row>
<row>
<entry><filename>/usr/lib/systemd/user</filename></entry>
- <entry>Units of installed packages</entry>
+ <entry>Units of packages that have been installed system-wide</entry>
</row>
</tbody>
</tgroup>
</refsect1>
<refsect1>
- <title>Options</title>
+ <title>[Unit] Section Options</title>
<para>Unit file may include a [Unit] section, which
carries generic information about the unit that is not
<literal>man:</literal>. For more
information about the syntax of these
URIs, see
- <citerefentry><refentrytitle>uri</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
+ <citerefentry project='man-pages'><refentrytitle>uri</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
URIs should be listed in order of
relevance, starting with the most
relevant. It is a good idea to first
of units. When systemd stops or restarts
the units listed here, the action is
propagated to this unit.
- Note that this is a one way dependency —
+ Note that this is a one-way dependency —
changes to this unit do not affect the
listed units.
</para></listitem>
<varlistentry>
<term><varname>RequiresMountsFor=</varname></term>
- <listitem><para>Takes a space-separated
- list of absolute paths. Automatically
- adds dependencies of type
- <varname>Requires=</varname> and
- <varname>After=</varname> for all
+ <listitem><para>Takes a
+ space-separated list of absolute
+ paths. Automatically adds dependencies
+ of type <varname>Requires=</varname>
+ and <varname>After=</varname> for all
mount units required to access the
- specified path.</para></listitem>
+ specified path.</para>
+
+ <para>Mount points marked with
+ <option>noauto</option> are not
+ mounted automatically and will be
+ ignored for the purposes of this
+ option. If such a mount should be a
+ requirement for this unit,
+ direct dependencies on the mount
+ units may be added
+ (<varname>Requires=</varname> and
+ <varname>After=</varname> or
+ some other combination).
+ </para></listitem>
</varlistentry>
<varlistentry>
</varlistentry>
<varlistentry>
+ <term><varname>ConditionArchitecture=</varname></term>
+ <term><varname>ConditionVirtualization=</varname></term>
+ <term><varname>ConditionHost=</varname></term>
+ <term><varname>ConditionKernelCommandLine=</varname></term>
+ <term><varname>ConditionSecurity=</varname></term>
+ <term><varname>ConditionCapability=</varname></term>
+ <term><varname>ConditionACPower=</varname></term>
+ <term><varname>ConditionNeedsUpdate=</varname></term>
+ <term><varname>ConditionFirstBoot=</varname></term>
<term><varname>ConditionPathExists=</varname></term>
<term><varname>ConditionPathExistsGlob=</varname></term>
<term><varname>ConditionPathIsDirectory=</varname></term>
<term><varname>ConditionDirectoryNotEmpty=</varname></term>
<term><varname>ConditionFileNotEmpty=</varname></term>
<term><varname>ConditionFileIsExecutable=</varname></term>
- <term><varname>ConditionKernelCommandLine=</varname></term>
- <term><varname>ConditionVirtualization=</varname></term>
- <term><varname>ConditionSecurity=</varname></term>
- <term><varname>ConditionCapability=</varname></term>
- <term><varname>ConditionHost=</varname></term>
- <term><varname>ConditionACPower=</varname></term>
<term><varname>ConditionNull=</varname></term>
<listitem><para>Before starting a unit
queued start job is to be
executed.</para>
+ <para><varname>ConditionArchitecture=</varname>
+ may be used to check whether the
+ system is running on a specific
+ architecture. Takes one of
+ <varname>x86</varname>,
+ <varname>x86-64</varname>,
+ <varname>ppc</varname>,
+ <varname>ppc-le</varname>,
+ <varname>ppc64</varname>,
+ <varname>ppc64-le</varname>,
+ <varname>ia64</varname>,
+ <varname>parisc</varname>,
+ <varname>parisc64</varname>,
+ <varname>s390</varname>,
+ <varname>s390x</varname>,
+ <varname>sparc</varname>,
+ <varname>sparc64</varname>,
+ <varname>mips</varname>,
+ <varname>mips-le</varname>,
+ <varname>mips64</varname>,
+ <varname>mips64-le</varname>,
+ <varname>alpha</varname>,
+ <varname>arm</varname>,
+ <varname>arm-be</varname>,
+ <varname>arm64</varname>,
+ <varname>arm64-be</varname>,
+ <varname>sh</varname>,
+ <varname>sh64</varname>,
+ <varname>m86k</varname>,
+ <varname>tilegx</varname>,
+ <varname>cris</varname> to test
+ against a specific architecture. The
+ architecture is determined from the
+ information returned by
+ <citerefentry><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+ and is thus subject to
+ <citerefentry><refentrytitle>personality</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Note
+ that a <varname>Personality=</varname>
+ setting in the same unit file has no
+ effect on this condition. A special
+ architecture name
+ <varname>native</varname> is mapped to
+ the architecture the system manager
+ itself is compiled for. The test may
+ be negated by prepending an
+ exclamation mark.</para>
+
+ <para><varname>ConditionVirtualization=</varname>
+ may be used to check whether the
+ system is executed in a virtualized
+ environment and optionally test
+ whether it is a specific
+ implementation. Takes either boolean
+ value to check if being executed in
+ any virtualized environment, or one of
+ <varname>vm</varname> and
+ <varname>container</varname> to test
+ against a generic type of
+ virtualization solution, or one of
+ <varname>qemu</varname>,
+ <varname>kvm</varname>,
+ <varname>zvm</varname>,
+ <varname>vmware</varname>,
+ <varname>microsoft</varname>,
+ <varname>oracle</varname>,
+ <varname>xen</varname>,
+ <varname>bochs</varname>,
+ <varname>uml</varname>,
+ <varname>openvz</varname>,
+ <varname>lxc</varname>,
+ <varname>lxc-libvirt</varname>,
+ <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
+ hostname or machine ID of the
+ host. This either takes a hostname
+ string (optionally with shell style
+ globs) which is tested against the
+ locally set hostname as returned by
+ <citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+ or a machine ID formatted as string
+ (see
+ <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+ The test may be negated by prepending
+ an exclamation mark.</para>
+
+ <para><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, separated
+ <literal>=</literal>). 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.</para>
+
+ <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>,
+ <varname>apparmor</varname>,
+ <varname>ima</varname> and
+ <varname>smack</varname>.
+ The test may be negated by prepending
+ an exclamation
+ mark.</para>
+
+ <para><varname>ConditionCapability=</varname>
+ may be used to check whether the given
+ capability exists in the capability
+ bounding set of the service manager
+ (i.e. this does not check whether
+ capability is actually available in
+ the permitted or effective sets, see
+ <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+ for details). Pass a capability name
+ such as <literal>CAP_MKNOD</literal>,
+ possibly prefixed with an exclamation
+ mark to negate the check.</para>
+
+ <para><varname>ConditionACPower=</varname>
+ may be used to check whether the
+ system has AC power, or is exclusively
+ battery powered at the time of
+ activation of the unit. This takes a
+ boolean argument. If set to
+ <varname>true</varname>, the condition
+ will hold only if at least one AC
+ connector of the system is connected
+ to a power source, or if no AC
+ connectors are known. Conversely, if
+ set to <varname>false</varname>, the
+ condition will hold only if there is
+ at least one AC connector known and
+ all AC connectors are disconnected
+ from a power source.</para>
+
+ <para><varname>ConditionNeedsUpdate=</varname>
+ takes one of <filename>/var</filename>
+ or <filename>/etc</filename> as
+ argument, possibly prefixed with a
+ <literal>!</literal> (for inverting
+ the condition). This condition may be
+ used to conditionalize units on
+ whether the specified directory
+ requires an update because
+ <filename>/usr</filename>'s
+ modification time is newer than the
+ stamp file
+ <filename>.updated</filename> in the
+ specified directory. This is useful to
+ implement offline updates of the
+ vendor operating system resources in
+ <filename>/usr</filename> that require
+ updating of <filename>/etc</filename>
+ or <filename>/var</filename> on the
+ next following boot. Units making use
+ of this condition should order
+ themselves before
+ <citerefentry><refentrytitle>systemd-update-done.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+ to make sure they run before the stamp
+ files's modification time gets reset
+ indicating a completed update.</para>
+
+ <para><varname>ConditionFirstBoot=</varname>
+ takes a boolean argument. This
+ condition may be used to
+ conditionalize units on whether the
+ system is booting up with an
+ unpopulated <filename>/etc</filename>
+ directory. This may be used to
+ populate <filename>/etc</filename> on
+ the first boot after factory reset, or
+ when a new system instances boots up
+ for the first time.</para>
+
<para>With
<varname>ConditionPathExists=</varname>
a file existence condition is
exists, is a regular file and marked
executable.</para>
- <para>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, separated
- <literal>=</literal>). 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.</para>
-
- <para><varname>ConditionVirtualization=</varname>
- may be used to check whether the
- system is executed in a virtualized
- environment and optionally test
- whether it is a specific
- implementation. Takes either boolean
- value to check if being executed in
- any virtualized environment, or one of
- <varname>vm</varname> and
- <varname>container</varname> to test
- against a generic type of
- virtualization solution, or one of
- <varname>qemu</varname>,
- <varname>kvm</varname>,
- <varname>vmware</varname>,
- <varname>microsoft</varname>,
- <varname>oracle</varname>,
- <varname>xen</varname>,
- <varname>bochs</varname>,
- <varname>chroot</varname>,
- <varname>uml</varname>,
- <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>
-
- <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>,
- <varname>apparmor</varname>,
- <varname>ima</varname> and
- <varname>smack</varname>.
- The test may be negated by prepending
- an exclamation
- mark.</para>
-
- <para><varname>ConditionCapability=</varname>
- may be used to check whether the given
- capability exists in the capability
- bounding set of the service manager
- (i.e. this does not check whether
- capability is actually available in
- the permitted or effective sets, see
- <citerefentry><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
- for details). Pass a capability name
- such as <literal>CAP_MKNOD</literal>,
- possibly prefixed with an exclamation
- mark to negate the check.</para>
-
- <para><varname>ConditionHost=</varname>
- may be used to match against the
- hostname or machine ID of the
- host. This either takes a hostname
- string (optionally with shell style
- globs) which is tested against the
- locally set hostname as returned by
- <citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
- or a machine ID formatted as string
- (see
- <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
- The test may be negated by prepending
- an exclamation mark.</para>
-
- <para><varname>ConditionACPower=</varname>
- may be used to check whether the
- system has AC power, or is exclusively
- battery powered at the time of
- activation of the unit. This takes a
- boolean argument. If set to
- <varname>true</varname>, the condition
- will hold only if at least one AC
- connector of the system is connected
- to a power source, or if no AC
- connectors are known. Conversely, if
- set to <varname>false</varname>, the
- condition will hold only if there is
- at least one AC connector known and
- all AC connectors are disconnected
- from a power source.</para>
-
<para>Finally,
<varname>ConditionNull=</varname> may
be used to add a constant condition
useful for implementation of generator
tools that convert configuration from
an external configuration file format
- into native unit files. Thus
+ into native unit files. This
functionality should not be used in
normal units.</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
+ </refsect1>
+
+ <refsect1>
+ <title>[Install] Section Options</title>
+
+ <para>Unit file may include an
+ <literal>[Install]</literal> 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
<varlistentry>
<term><varname>Alias=</varname></term>
- <listitem><para>A space-seperated list
+ <listitem><para>A space-separated list
of additional names this unit shall be
installed under. The names listed here
must have the same suffix (i.e. type)
of unit names may be
given.</para></listitem>
</varlistentry>
+
+ <varlistentry>
+ <term><varname>DefaultInstance=</varname></term>
+
+ <listitem><para>In template unit files,
+ this specifies for which instance the
+ unit shall be enabled if the template
+ is enabled without any explicitly set
+ instance. This option has no effect in
+ non-template unit files. The specified
+ string must be usable as instance
+ identifier.</para></listitem>
+ </varlistentry>
</variablelist>
<para>The following specifiers are interpreted in the
<title>See Also</title>
<para>
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<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>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd-verify</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>
</para>
~ianmdlvl / elogind.git / blobdiff