]>
<!--
+ SPDX-License-Identifier: LGPL-2.1+
+
This file is part of systemd.
Copyright 2010 Lennart Poettering
modify unit files. Each drop-in file must have appropriate section headers. Note that for
instantiated 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 the <literal>.conf</literal> files there. Also note that
- settings from the <literal>[Install]</literal> section are not honored in drop-in unit files,
- and have no effect.</para>
+ <literal>.d/</literal> subdirectory and the <literal>.conf</literal> files there.</para>
<para>In addition to <filename>/etc/systemd/system</filename>, the drop-in <literal>.d</literal>
directories for system services can be placed in <filename>/usr/lib/systemd/system</filename> or
<!-- Note that we do not document .include here, as we consider it mostly obsolete, and want
people to use .d/ drop-ins instead. -->
- <para>Some unit names reflect paths existing in the file system
- namespace. Example: a device unit
- <filename>dev-sda.device</filename> refers to a device with the
- device node <filename noindex='true'>/dev/sda</filename> in 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
- 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>Note that while systemd offers a flexible dependency system
+ between units it is recommended to use this functionality only
+ sparingly and instead rely on techniques such as bus-based or
+ socket-based activation which make dependencies implicit,
+ resulting in a both simpler and more flexible system.</para>
<para>Optionally, units may be instantiated from a
template file at runtime. This allows creation of
<para>The unit file format is covered by the
<ulink
- url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
+ url="https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
Stability Promise</ulink>.</para>
</refsect1>
<refsect1>
- <title>Automatic Dependencies</title>
+ <title>String Escaping for Inclusion in Unit Names</title>
+
+ <para>Sometimes it is useful to convert arbitrary strings into unit names. To facilitate this, a method of string
+ escaping is used, in order to map strings containing arbitrary byte values (except NUL) into valid unit names and
+ their restricted character set. A common special case are unit names that reflect paths to objects in the file
+ system hierarchy. Example: a device unit <filename>dev-sda.device</filename> refers to a device with the device
+ node <filename noindex='true'>/dev/sda</filename> in the file system.</para>
+
+ <para>The escaping algorithm operates as follows: given a string, any <literal>/</literal> character is replaced by
+ <literal>-</literal>, and all other characters which are not ASCII alphanumerics or <literal>_</literal> are
+ replaced by C-style <literal>\x2d</literal> escapes. In addition, <literal>.</literal> is replaced with such a
+ C-style escape when it would appear as the first character in the escaped string.</para>
+
+ <para>When the input qualifies as absolute file system path, this algorithm is extended slightly: the path to the
+ root directory <literal>/</literal> is encoded as single dash <literal>-</literal>. In addition, any leading,
+ trailing or duplicate <literal>/</literal> characters are removed from the string before transformation. Example:
+ <filename>/foo//bar/baz/</filename> becomes <literal>foo-bar-baz</literal>.</para>
+
+ <para>This escaping is fully reversible, as long as it is known whether the escaped string was a path (the
+ unescaping results are different for paths and non-path strings). The
+ <citerefentry><refentrytitle>systemd-escape</refentrytitle><manvolnum>1</manvolnum></citerefentry> command may be
+ used to apply and reverse escaping on arbitrary strings. Use <command>systemd-escape --path</command> to escape
+ path strings, and <command>systemd-escape</command> without <option>--path</option> otherwise.</para>
+ </refsect1>
- <para>Note that while systemd offers a flexible dependency system
- between units it is recommended to use this functionality only
- sparingly and instead rely on techniques such as bus-based or
- socket-based activation which make dependencies implicit,
- resulting in a both simpler and more flexible system.</para>
+ <refsect1>
+ <title>Implicit Dependencies</title>
+
+ <para>A number of unit dependencies are implicitly established,
+ depending on unit type and unit configuration. These implicit
+ dependencies can make unit configuration file cleaner. For the
+ implicit dependencies in each unit type, please refer to
+ section "Implicit Dependencies" in respective man pages.</para>
+
+ <para>For example, service units with <varname>Type=dbus</varname>
+ automatically acquire dependencies of type <varname>Requires=</varname>
+ and <varname>After=</varname> on <filename>dbus.socket</filename>. See
+ <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for details.</para>
+ </refsect1>
- <para>A number of unit dependencies are automatically established,
- depending on unit configuration. On top of that, for units with
- <varname>DefaultDependencies=yes</varname> (the default) a couple
- of additional dependencies are added. The precise effect of
- <varname>DefaultDependencies=yes</varname> depends on the unit
- type (see below).</para>
-
- <para>If <varname>DefaultDependencies=yes</varname> is set, units
- that are referenced by other units of type
- <filename>.target</filename> via a <varname>Wants=</varname> or
- <varname>Requires=</varname> dependency might automatically gain
- an <varname>Before=</varname> dependency too. See
+ <refsect1>
+ <title>Default Dependencies</title>
+
+ <para>Default dependencies are similar to implicit dependencies,
+ but can be turned on and off by setting
+ <varname>DefaultDependencies=</varname> to <varname>yes</varname>
+ (the default) and <varname>no</varname>, while implicit dependencies
+ are always in effect. See section "Default Dependencies" in respective
+ man pages for the effect of enabling
+ <varname>DefaultDependencies=</varname> in each unit types.</para>
+
+ <para>For example, target units will complement all configured
+ dependencies of type <varname>Wants=</varname> or
+ <varname>Requires=</varname> with dependencies of type
+ <varname>After=</varname> unless <varname>DefaultDependencies=no</varname>
+ is set in the specified units. See
<citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- for details.</para>
+ for details. Note that this behavior can be turned off by setting
+ <varname>DefaultDependencies=no</varname>.</para>
</refsect1>
<refsect1>
</para>
</refsect1>
+ <refsect1>
+ <title>Unit Garbage Collection</title>
+
+ <para>The system and service manager loads a unit's configuration automatically when a unit is referenced for the
+ first time. It will automatically unload the unit configuration and state again when the unit is not needed anymore
+ ("garbage collection"). A unit may be referenced through a number of different mechanisms:</para>
+
+ <orderedlist>
+ <listitem><para>Another loaded unit references it with a dependency such as <varname>After=</varname>,
+ <varname>Wants=</varname>, …</para></listitem>
+
+ <listitem><para>The unit is currently starting, running, reloading or stopping.</para></listitem>
+
+ <listitem><para>The unit is currently in the <constant>failed</constant> state. (But see below.)</para></listitem>
+
+ <listitem><para>A job for the unit is pending.</para></listitem>
+
+ <listitem><para>The unit is pinned by an active IPC client program.</para></listitem>
+
+ <listitem><para>The unit is a special "perpetual" unit that is always active and loaded. Examples for perpetual
+ units are the root mount unit <filename>-.mount</filename> or the scope unit <filename>init.scope</filename> that
+ the service manager itself lives in.</para></listitem>
+
+ <listitem><para>The unit has running processes associated with it.</para></listitem>
+ </orderedlist>
+
+ <para>The garbage collection logic may be altered with the <varname>CollectMode=</varname> option, which allows
+ configuration whether automatic unloading of units that are in <constant>failed</constant> state is permissible,
+ see below.</para>
+
+ <para>Note that when a unit's configuration and state is unloaded, all execution results, such as exit codes, exit
+ signals, resource consumption and other statistics are lost, except for what is stored in the log subsystem.</para>
+
+ <para>Use <command>systemctl daemon-reload</command> or an equivalent command to reload unit configuration while
+ the unit is already loaded. In this case all configuration settings are flushed out and replaced with the new
+ configuration (which however might not be in effect immediately), however all runtime state is
+ saved/restored.</para>
+ </refsect1>
+
<refsect1>
<title>[Unit] Section Options</title>
<term><varname>Requires=</varname></term>
<listitem><para>Configures requirement dependencies on other units. If this unit gets activated, the units
- listed here will be activated as well. If one of the other units gets deactivated or its activation fails, this
- unit will be deactivated. This option may be specified more than once or multiple space-separated units may be
+ listed here will be activated as well. If one of the other units fails to activate, and an ordering dependency
+ <varname>After=</varname> on the failing unit is set, this
+ unit will not be started. This option may be specified more than once or multiple space-separated units may be
specified in one option in which case requirement dependencies for all listed names will be created. Note that
requirement dependencies do not influence the order in which services are started or stopped. This has to be
configured independently with the <varname>After=</varname> or <varname>Before=</varname> options. If a unit
<para>Note that this dependency type does not imply that the other unit always has to be in active state when
this unit is running. Specifically: failing condition checks (such as <varname>ConditionPathExists=</varname>,
- <varname>ConditionPathExists=</varname>, … — see below) do not cause the start job of a unit with a
+ <varname>ConditionPathIsSymbolicLink=</varname>, … — see below) do not cause the start job of a unit with a
<varname>Requires=</varname> dependency on it to fail. Also, some unit types may deactivate on their own (for
example, a service process may decide to exit cleanly, or a device may be unplugged by the user), which is not
propagated to units having a <varname>Requires=</varname> dependency. Use the <varname>BindsTo=</varname>
<term><varname>Before=</varname></term>
<term><varname>After=</varname></term>
- <listitem><para>A space-separated list of unit names. Configures ordering dependencies between units. If a
- unit <filename>foo.service</filename> contains a setting <option>Before=bar.service</option> and both units are
- being started, <filename>bar.service</filename>'s start-up is delayed until <filename>foo.service</filename> is
- started up. Note that this setting is independent of and orthogonal to the requirement dependencies as
- configured by <varname>Requires=</varname>, <varname>Wants=</varname> or <varname>BindsTo=</varname>. It is a
- common pattern to include a unit name in both the <varname>After=</varname> and <varname>Requires=</varname>
- option, in which case the unit listed will be started before the unit that is configured with these
- options. This option may be specified more than once, in which case ordering dependencies for all listed names
- are created. <varname>After=</varname> is the inverse of <varname>Before=</varname>, i.e. while
- <varname>After=</varname> ensures that the configured unit is started after the listed unit finished starting
- up, <varname>Before=</varname> ensures the opposite, i.e. that the configured unit is fully started up before
- the listed unit is started. Note that when two units with an ordering dependency between them are shut down,
- the inverse of the start-up order is applied. i.e. if a unit is configured with <varname>After=</varname> on
- another unit, the former is stopped before the latter if both are shut down. Given two units with any ordering
- dependency between them, if one unit is shut down and the other is started up, the shutdown is ordered before
- the start-up. It doesn't matter if the ordering dependency is <varname>After=</varname> or
- <varname>Before=</varname>, in this case. It also doesn't matter which of the two is shut down, as long as one
- is shut down and the other is started up. The shutdown is ordered before the start-up in all cases. If two
- units have no ordering dependencies between them, they are shut down or started up simultaneously, and no
- ordering takes place. </para></listitem>
+ <listitem><para>These two settings expect a space-separated list of unit names. They configure ordering
+ dependencies between units. If a unit <filename>foo.service</filename> contains a setting
+ <option>Before=bar.service</option> and both units are being started, <filename>bar.service</filename>'s
+ start-up is delayed until <filename>foo.service</filename> has finished starting up. Note that this setting is
+ independent of and orthogonal to the requirement dependencies as configured by <varname>Requires=</varname>,
+ <varname>Wants=</varname> or <varname>BindsTo=</varname>. It is a common pattern to include a unit name in both
+ the <varname>After=</varname> and <varname>Requires=</varname> options, in which case the unit listed will be
+ started before the unit that is configured with these options. This option may be specified more than once, in
+ which case ordering dependencies for all listed names are created. <varname>After=</varname> is the inverse of
+ <varname>Before=</varname>, i.e. while <varname>After=</varname> ensures that the configured unit is started
+ after the listed unit finished starting up, <varname>Before=</varname> ensures the opposite, that the
+ configured unit is fully started up before the listed unit is started. Note that when two units with an
+ ordering dependency between them are shut down, the inverse of the start-up order is applied. i.e. if a unit is
+ configured with <varname>After=</varname> on another unit, the former is stopped before the latter if both are
+ shut down. Given two units with any ordering dependency between them, if one unit is shut down and the other is
+ started up, the shutdown is ordered before the start-up. It doesn't matter if the ordering dependency is
+ <varname>After=</varname> or <varname>Before=</varname>, in this case. It also doesn't matter which of the two
+ is shut down, as long as one is shut down and the other is started up. The shutdown is ordered before the
+ start-up in all cases. If two units have no ordering dependencies between them, they are shut down or started
+ up simultaneously, and no ordering takes place. It depends on the unit type when precisely a unit has finished
+ starting up. Most importantly, for service units start-up is considered completed for the purpose of
+ <varname>Before=</varname>/<varname>After=</varname> when all its configured start-up commands have been
+ invoked and they either failed or reported start-up success.</para></listitem>
</varlistentry>
<varlistentry>
<varlistentry>
<term><varname>IgnoreOnIsolate=</varname></term>
- <listitem><para>Takes a boolean argument. If
- <option>true</option>, this unit will not be stopped when
- isolating another unit. Defaults to
- <option>false</option>.</para></listitem>
+ <listitem><para>Takes a boolean argument. If <option>true</option>, this unit
+ will not be stopped when isolating another unit. Defaults to
+ <option>false</option> for service, target, socket, busname, timer, and path
+ units, and <option>true</option> for slice, scope, device, swap, mount, and
+ automount units.</para></listitem>
</varlistentry>
<varlistentry>
ones.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>CollectMode=</varname></term>
+
+ <listitem><para>Tweaks the "garbage collection" algorithm for this unit. Takes one of <option>inactive</option>
+ or <option>inactive-or-failed</option>. If set to <option>inactive</option> the unit will be unloaded if it is
+ in the <constant>inactive</constant> state and is not referenced by clients, jobs or other units — however it
+ is not unloaded if it is in the <constant>failed</constant> state. In <option>failed</option> mode, failed
+ units are not unloaded until the user invoked <command>systemctl reset-failed</command> on them to reset the
+ <constant>failed</constant> state, or an equivalent command. This behaviour is altered if this option is set to
+ <option>inactive-or-failed</option>: in this case the unit is unloaded even if the unit is in a
+ <constant>failed</constant> state, and thus an explicitly resetting of the <constant>failed</constant> state is
+ not necessary. Note that if this mode is used unit results (such as exit codes, exit signals, consumed
+ resources, …) are flushed out immediately after the unit completed, except for what is stored in the logging
+ subsystem. Defaults to <option>inactive</option>.</para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>JobTimeoutSec=</varname></term>
+ <term><varname>JobRunningTimeoutSec=</varname></term>
<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 <literal>infinity</literal> (job timeouts disabled),
- except for device units. NB: this timeout is independent from any unit-specific timeout (for example, the
- timeout set with <varname>TimeoutStartSec=</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 in other words: unit-specific timeouts are useful
- to abort unit state changes, and revert them. The job timeout set with this option however is useful to abort
- only the job waiting for the unit state to 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
+ <listitem><para>When a job for this unit is queued, a time-out <varname>JobTimeoutSec=</varname> may be
+ configured. Similarly, <varname>JobRunningTimeoutSec=</varname> starts counting when the queued job is actually
+ started. If either 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 <literal>infinity</literal> (job timeouts
+ disabled), except for device units (<varname>JobRunningTimeoutSec=</varname> defaults to
+ <varname>DefaultTimeoutStartSec=</varname>). NB: this timeout is independent from any unit-specific timeout
+ (for example, the timeout set with <varname>TimeoutStartSec=</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 in other words: unit-specific
+ timeouts are useful to abort unit state changes, and revert them. The job timeout set with this option however
+ is useful to abort only the job waiting for the unit state to 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 <varname>StartLimitAction=</varname>. 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>StartLimitIntervalSec=</varname></term>
- <term><varname>StartLimitBurst=</varname></term>
-
- <listitem><para>Configure unit start rate limiting. By default, units which are started more than 5 times
- within 10 seconds are not permitted to start any more times until the 10 second interval ends. With these two
- options, this rate limiting may be modified. Use <varname>StartLimitIntervalSec=</varname> to configure the
- checking interval (defaults to <varname>DefaultStartLimitIntervalSec=</varname> in manager configuration file,
- set to 0 to disable any kind of rate limiting). Use <varname>StartLimitBurst=</varname> to configure how many
- starts per interval are allowed (defaults to <varname>DefaultStartLimitBurst=</varname> in manager
- configuration file). These configuration options are particularly useful in conjunction with the service
- setting <varname>Restart=</varname> (see
+ <term><varname>StartLimitIntervalSec=<replaceable>interval</replaceable></varname></term>
+ <term><varname>StartLimitBurst=<replaceable>burst</replaceable></varname></term>
+
+ <listitem><para>Configure unit start rate limiting. Units which are started more than
+ <replaceable>burst</replaceable> times within an <replaceable>interval</replaceable> time interval are not
+ permitted to start any more. Use <varname>StartLimitIntervalSec=</varname> to configure the checking interval
+ (defaults to <varname>DefaultStartLimitIntervalSec=</varname> in manager configuration file, set it to 0 to
+ disable any kind of rate limiting). Use <varname>StartLimitBurst=</varname> to configure how many starts per
+ interval are allowed (defaults to <varname>DefaultStartLimitBurst=</varname> in manager configuration
+ file). These configuration options are particularly useful in conjunction with the service setting
+ <varname>Restart=</varname> (see
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>); however,
they apply to all kinds of starts (including manual), not just those triggered by the
<varname>Restart=</varname> logic. Note that units which are configured for <varname>Restart=</varname> and
which reach the start limit are not attempted to be restarted anymore; however, they may still be restarted
- manually at a later point, from which point on, the restart logic is again activated. Note that
- <command>systemctl reset-failed</command> will cause the restart rate counter for a service to be flushed,
- which is useful if the administrator wants to manually start a unit and the start limit interferes with
- that. Note that this rate-limiting is enforced after any unit condition checks are executed, and hence unit
- activations with failing conditions are not counted by this rate limiting. Slice, target, device and scope
- units do not enforce this setting, as they are unit types whose activation may either never fail, or may
- succeed only a single time.</para></listitem>
+ manually at a later point, after the <replaceable>interval</replaceable> has passed. From this point on, the
+ restart logic is activated again. Note that <command>systemctl reset-failed</command> will cause the restart
+ rate counter for a service to be flushed, which is useful if the administrator wants to manually start a unit
+ and the start limit interferes with that. Note that this rate-limiting is enforced after any unit condition
+ checks are executed, and hence unit activations with failing conditions do not count towards this rate
+ limit. This setting does not apply to slice, target, device, and scope units, since they are unit types whose
+ activation may either never fail, or may succeed only a single time.</para>
+
+ <para>When a unit is unloaded due to the garbage collection logic (see above) its rate limit counters are
+ flushed out too. This means that configuring start rate limiting for a unit that is not referenced continously
+ has no effect.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>ConditionDirectoryNotEmpty=</varname></term>
<term><varname>ConditionFileNotEmpty=</varname></term>
<term><varname>ConditionFileIsExecutable=</varname></term>
+ <term><varname>ConditionUser=</varname></term>
+ <term><varname>ConditionGroup=</varname></term>
<!-- We do not document ConditionNull=
here, as it is not particularly
<varname>arm64-be</varname>,
<varname>sh</varname>,
<varname>sh64</varname>,
- <varname>m86k</varname>,
+ <varname>m68k</varname>,
<varname>tilegx</varname>,
- <varname>cris</varname> to test
+ <varname>cris</varname>,
+ <varname>arc</varname>,
+ <varname>arc-be</varname> to test
against a specific architecture. The architecture is
determined from the information returned by
<citerefentry project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
system. Currently, the recognized values are
<varname>selinux</varname>,
<varname>apparmor</varname>,
+ <varname>tomoyo</varname>,
<varname>ima</varname>,
<varname>smack</varname> and
<varname>audit</varname>. The test may be negated by
to make sure they run before the stamp file'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><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 (specifically: an <filename>/etc</filename> with no <filename>/etc/machine-id</filename>). This may
+ be used to populate <filename>/etc</filename> on the first boot after factory reset, or when a new system
+ instance boots up for the first time.</para>
<para>With <varname>ConditionPathExists=</varname> a file
existence condition is checked before a unit is started. If
whether a certain path exists, is a regular file and marked
executable.</para>
+ <para><varname>ConditionUser=</varname> takes a numeric
+ <literal>UID</literal>, a UNIX user name, or the special value
+ <literal>@system</literal>. This condition may be used to check
+ whether the service manager is running as the given user. The
+ special value <literal>@system</literal> can be used to check
+ if the user id is within the system user range. This option is not
+ useful for system services, as the system manager exclusively
+ runs as the root user, and thus the test result is constant.</para>
+
+ <para><varname>ConditionGroup=</varname> is similar
+ to <varname>ConditionUser=</varname> but verifies that the
+ service manager's real or effective group, or any of its
+ auxiliary groups match the specified group or GID. This setting
+ does not have a special value <literal>@system</literal>.</para>
+
<para>If multiple conditions are specified, the unit will be
executed if all of them apply (i.e. a logical AND is applied).
Condition checks can be prefixed with a pipe symbol (|) in
<term><varname>AssertDirectoryNotEmpty=</varname></term>
<term><varname>AssertFileNotEmpty=</varname></term>
<term><varname>AssertFileIsExecutable=</varname></term>
+ <term><varname>AssertUser=</varname></term>
+ <term><varname>AssertGroup=</varname></term>
<listitem><para>Similar to the <varname>ConditionArchitecture=</varname>,
<varname>ConditionVirtualization=</varname>, …, condition settings described above, these settings add
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> during runtime; it is
used by the <command>enable</command> and <command>disable</command> commands of the
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> tool during
- installation of a unit. Note that settings in the <literal>[Install]</literal> section may not appear in
- <filename>.d/*.conf</filename> unit file drop-ins (see above).</para>
+ installation of a unit.</para>
<variablelist class='unit-directives'>
<varlistentry>
<term><varname>Alias=</varname></term>
<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) as the unit file name. This option may be specified more than once,
+ here must have the same suffix (i.e. type) as the unit filename. This option may be specified more than once,
in which case all listed names are used. At installation time, <command>systemctl enable</command> will create
symlinks from these names to the unit filename. Note that not all unit types support such alias names, and this
setting is not supported for them. Specifically, mount, slice, swap, and automount units do not support
<row>
<entry><literal>%N</literal></entry>
<entry>Unescaped full unit name</entry>
- <entry>Same as <literal>%n</literal>, but with escaping undone</entry>
+ <entry>Same as <literal>%n</literal>, but with escaping undone. This undoes the escaping used when generating unit names from arbitrary strings (see above). </entry>
</row>
<row>
<entry><literal>%p</literal></entry>
<row>
<entry><literal>%f</literal></entry>
<entry>Unescaped filename</entry>
- <entry>This is either the unescaped instance name (if applicable) with <filename>/</filename> prepended (if applicable), or the unescaped prefix name prepended with <filename>/</filename>.</entry>
+ <entry>This is either the unescaped instance name (if applicable) with <filename>/</filename> prepended (if applicable), or the unescaped prefix name prepended with <filename>/</filename>. This implements unescaping according to the rules for escaping absolute file system paths discussed above.</entry>
</row>
<row>
<entry><literal>%t</literal></entry>
- <entry>Runtime directory</entry>
+ <entry>Runtime directory root</entry>
<entry>This is either <filename>/run</filename> (for the system manager) or the path <literal>$XDG_RUNTIME_DIR</literal> resolves to (for user managers).</entry>
</row>
<row>
+ <entry><literal>%S</literal></entry>
+ <entry>State directory root </entry>
+ <entry>This is either <filename>/var/lib</filename> (for the system manager) or the path <literal>$XDG_CONFIG_HOME</literal> resolves to (for user managers).</entry>
+ </row>
+ <row>
+ <entry><literal>%C</literal></entry>
+ <entry>Cache directory root </entry>
+ <entry>This is either <filename>/var/cache</filename> (for the system manager) or the path <literal>$XDG_CACHE_HOME</literal> resolves to (for user managers).</entry>
+ </row>
+ <row>
+ <entry><literal>%L</literal></entry>
+ <entry>Logs directory root </entry>
+ <entry>This is either <filename>/var/log</filename> (for the system manager) or the path <literal>$XDG_CONFIG_HOME</literal> resolves to with <filename>/log</filename> appended (for user managers).</entry>
+ </row>
+ <row>
<entry><literal>%u</literal></entry>
<entry>User name</entry>
<entry>This is the name of the user running the service manager instance. In case of the system manager this resolves to <literal>root</literal>.</entry>
ordered appropriately (<varname>After=</varname>). Thirdly, in
order to harden the service a bit more, the administrator would
like to set the <varname>PrivateTmp=</varname> setting (see
- <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for details). And lastly, the administrator would like to reset
the niceness of the service to its default value of 0.</para>
projects / thirdparty / systemd.git / blobdiff