<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>/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
(<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><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
<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>
<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>
<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>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-be</varname>,
<varname>sh</varname>,
<varname>sh64</varname>,
- <varname>m86k</varname> to test
+ <varname>m86k</varname>,
+ <varname>tilegx</varname>,
+ <varname>cris</varname> to test
against a specific architecture. The
architecture is determined from the
information returned by
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>chroot</varname>,
<varname>uml</varname>,
<varname>openvz</varname>,
<varname>lxc</varname>,
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
+ assignment. In the latter case, the
exact assignment is looked for with
right and left hand side
matching.</para>
(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>
+ <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
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
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>
+ </refsect1>
+
+ <refsect1>
+ <title>[Install] Section Options</title>
+
<para>Unit file may include a [Install] section, which
carries installation information for the unit. This
section is not interpreted by
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
<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>