<refnamediv>
<refname>systemd.unit</refname>
- <refpurpose>systemd unit configuration files</refpurpose>
+ <refpurpose>Unit configuration</refpurpose>
</refnamediv>
<refsynopsisdiv>
<entry>Runtime socket dir</entry>
<entry>This is either /run (for the system manager) or $XDG_RUNTIME_DIR (for user managers).</entry>
</row>
+ <row>
+ <entry><literal>%u</literal></entry>
+ <entry>User name</entry>
+ <entry>This is the name of the configured user of the unit, or (if none is set) the user running the systemd instance.</entry>
+ </row>
+ <row>
+ <entry><literal>%h</literal></entry>
+ <entry>User home directory</entry>
+ <entry>This is the home directory of the configured user of the unit, or (if none is set) the user running the systemd instance.</entry>
+ </row>
+ <row>
+ <entry><literal>%s</literal></entry>
+ <entry>User shell</entry>
+ <entry>This is the shell of the configured user of the unit, or (if none is set) the user running the systemd instance.</entry>
+ </row>
</tbody>
</tgroup>
</table>
name.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>Documentation=</varname></term>
+ <listitem><para>A space separated list
+ of URIs referencing documentation for
+ this unit or its
+ configuration. Accepted are only URIs
+ of the types
+ <literal>http://</literal>,
+ <literal>https://</literal>,
+ <literal>file:</literal>,
+ <literal>info:</literal>,
+ <literal>man:</literal>. For more
+ information about the syntax of these
+ URIs see
+ <citerefentry><refentrytitle>uri</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>Requires=</varname></term>
<varname>Requires=</varname> in order
to achieve a system that is more
robust when dealing with failing
- services.</para></listitem>
+ services.</para>
+
+ <para>Note that dependencies of this
+ type may also be configured outside of
+ the unit configuration file by
+ adding a symlink to a
+ <filename>.requires/</filename> directory
+ accompanying the unit file. For
+ details see above.</para></listitem>
</varlistentry>
<varlistentry>
the transaction as a whole. This is
the recommended way to hook start-up
of one unit to the start-up of another
- unit. Note that dependencies of this
+ unit.</para>
+
+ <para>Note that dependencies of this
type may also be configured outside of
the unit configuration file by
adding a symlink to a
</varlistentry>
<varlistentry>
- <term><varname>BindTo=</varname></term>
+ <term><varname>BindsTo=</varname></term>
<listitem><para>Configures requirement
dependencies, very similar in style to
systemd.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>PartOf=</varname></term>
+
+ <listitem><para>Configures dependencies
+ similar to <varname>Requires=</varname>,
+ but limited to stopping and restarting
+ 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 -
+ changes to this unit do not affect the
+ listed units.
+ </para></listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>Conflicts=</varname></term>
</varlistentry>
<varlistentry>
- <term><varname>PropagateReloadTo=</varname></term>
- <term><varname>PropagateReloadFrom=</varname></term>
+ <term><varname>PropagatesReloadTo=</varname></term>
+ <term><varname>ReloadPropagatedFrom=</varname></term>
<listitem><para>Lists one or more
units where reload requests on the
</varlistentry>
<varlistentry>
- <term><varname>Names=</varname></term>
-
- <listitem><para>Additional names for
- this unit. The names listed here must
- have the same suffix (i.e. type) as
- the unit file name. This option may be
- specified more than once, in which
- case all listed names are used. Note
- that this option is different from the
- <varname>Alias=</varname> option from
- the [Install] section mentioned
- below. See below for details. Note
- that in almost all cases this option
- is not what you want. A symlink alias
- in the file system is generally
- preferable since it can be used as
- lookup key. If a unit with a symlinked
- alias name is not loaded and needs to
- be it is easily found via the
- symlink. However, if a unit with an
- alias name configured with this
- setting is not loaded it will not be
- discovered. This settings' only use is
- in conjunction with service
- instances.</para>
- </listitem>
+ <term><varname>SourcePath=</varname></term>
+ <listitem><para>A path to a
+ configuration file this unit has been
+ generated from. This is primarily
+ useful for implementation of generator
+ tools that convert configuration from
+ an external configuration file format
+ into native unit files. Thus
+ functionality should not be used in
+ normal units.</para></listitem>
</varlistentry>
</variablelist>
time,
<command>systemctl enable</command>
will create symlinks from these names
- to the unit file name. Note that this
- is different from the
- <varname>Names=</varname> option from
- the [Unit] section mentioned above:
- The names from
- <varname>Names=</varname> apply
- unconditionally if the unit is
- loaded. The names from
- <varname>Alias=</varname> apply only
- if the unit has actually been
- installed with the
- <command>systemctl enable</command>
- command. Also, if systemd searches for a
- unit, it will discover symlinked alias
- names as configured with
- <varname>Alias=</varname>, but not
- names configured with
- <varname>Names=</varname> only. It is
- a common pattern to list a name in
- both options. In this case, a unit
- will be active under all names if
- installed, but also if not installed
- but requested explicitly under its
- main name.</para></listitem>
+ to the unit file name.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>WantedBy=</varname></term>
+ <term><varname>RequiredBy=</varname></term>
<listitem><para>Installs a symlink in
the <filename>.wants/</filename>
+ resp. <filename>.requires/</filename>
subdirectory for a unit. This has the
effect that when the listed unit name
is activated the unit listing it is