"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!--
+ SPDX-License-Identifier: LGPL-2.1+
+
This file is part of systemd.
Copyright 2010 Lennart Poettering
</refsect1>
<refsect1>
- <title>Automatic Dependencies</title>
-
- <para>Services with <varname>Type=dbus</varname> set automatically
- acquire dependencies of type <varname>Requires=</varname> and
- <varname>After=</varname> on
- <filename>dbus.socket</filename>.</para>
-
- <para>Socket activated services are automatically ordered after
- their activating <filename>.socket</filename> units via an
- automatic <varname>After=</varname> dependency.
- Services also pull in all <filename>.socket</filename> units
- listed in <varname>Sockets=</varname> via automatic
- <varname>Wants=</varname> and <varname>After=</varname> dependencies.</para>
-
- <para>Unless <varname>DefaultDependencies=</varname> in the <literal>[Unit]</literal> is set to
- <option>false</option>, service units will implicitly have dependencies of type <varname>Requires=</varname> and
- <varname>After=</varname> on <filename>sysinit.target</filename>, a dependency of type <varname>After=</varname> on
- <filename>basic.target</filename> as well as dependencies of type <varname>Conflicts=</varname> and
- <varname>Before=</varname> on <filename>shutdown.target</filename>. These ensure that normal service units pull in
- basic system initialization, and are terminated cleanly prior to system shutdown. Only services involved with early
- boot or late system shutdown should disable this option.</para>
-
- <para>Instanced service units (i.e. service units with an <literal>@</literal> in their name) are assigned by
- default a per-template slice unit (see
- <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>), named after the
- template unit, containing all instances of the specific template. This slice is normally stopped at shutdown,
- together with all template instances. If that is not desired, set <varname>DefaultDependencies=no</varname> in the
- template unit, and either define your own per-template slice unit file that also sets
- <varname>DefaultDependencies=no</varname>, or set <varname>Slice=system.slice</varname> (or another suitable slice)
- in the template unit. Also see
- <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+ <title>Implicit Dependencies</title>
+
+ <para>The following dependencies are implicitly added:</para>
+
+ <itemizedlist>
+ <listitem><para>Services with <varname>Type=dbus</varname> set automatically
+ acquire dependencies of type <varname>Requires=</varname> and
+ <varname>After=</varname> on
+ <filename>dbus.socket</filename>.</para></listitem>
+
+ <listitem><para>Socket activated services are automatically ordered after
+ their activating <filename>.socket</filename> units via an
+ automatic <varname>After=</varname> dependency.
+ Services also pull in all <filename>.socket</filename> units
+ listed in <varname>Sockets=</varname> via automatic
+ <varname>Wants=</varname> and <varname>After=</varname> dependencies.</para></listitem>
+ </itemizedlist>
<para>Additional implicit dependencies may be added as result of
execution and resource control parameters as documented in
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
</refsect1>
+ <refsect1>
+ <title>Default Dependencies</title>
+
+ <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
+ <itemizedlist>
+ <listitem><para>Service units will have dependencies of type <varname>Requires=</varname> and
+ <varname>After=</varname> on <filename>sysinit.target</filename>, a dependency of type <varname>After=</varname> on
+ <filename>basic.target</filename> as well as dependencies of type <varname>Conflicts=</varname> and
+ <varname>Before=</varname> on <filename>shutdown.target</filename>. These ensure that normal service units pull in
+ basic system initialization, and are terminated cleanly prior to system shutdown. Only services involved with early
+ boot or late system shutdown should disable this option.</para></listitem>
+
+ <listitem><para>Instanced service units (i.e. service units with an <literal>@</literal> in their name) are assigned by
+ default a per-template slice unit (see
+ <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>), named after the
+ template unit, containing all instances of the specific template. This slice is normally stopped at shutdown,
+ together with all template instances. If that is not desired, set <varname>DefaultDependencies=no</varname> in the
+ template unit, and either define your own per-template slice unit file that also sets
+ <varname>DefaultDependencies=no</varname>, or set <varname>Slice=system.slice</varname> (or another suitable slice)
+ in the template unit. Also see
+ <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+ </para></listitem>
+ </itemizedlist>
+ </refsect1>
+
<refsect1>
<title>Options</title>
<varlistentry>
<term><varname>PIDFile=</varname></term>
- <listitem><para>Takes an absolute file name pointing to the
+ <listitem><para>Takes an absolute filename pointing to the
PID file of this daemon. Use of this option is recommended for
services where <varname>Type=</varname> is set to
<option>forking</option>. systemd will read the PID of the
<varname>ExecStop=</varname> are not valid.)</para>
<para>For each of the specified commands, the first argument must be an absolute path to an
- executable. Optionally, this file name may be prefixed with a number of special characters:</para>
+ executable. Optionally, this filename may be prefixed with a number of special characters:</para>
<table>
<title>Special executable prefixes</title>
<row>
<entry><literal>!!</literal></entry>
- <entry>This prefix is very similar to <literal>!!</literal>, however it only has an effect on systems lacking support for ambient process capabilities, i.e. without support for <varname>AmbientCapabilities=</varname>. It's intended to be used for unit files that take benefit of ambient capabilities to run processes with minimal privileges wherever possible while remaining compatible with systems that lack ambient capabilities support. Note that when <literal>!!</literal> is used, and a system lacking ambient capability support is detected any configured <varname>SystemCallFilter=</varname> and <varname>CapabilityBoundingSet=</varname> stanzas are implicitly modified, in order to permit spawned processes to drop credentials and capabilities themselves, even if this is configured to not be allowed. Moreover, if this prefix is used and a system lacking ambient capability support is detected <varname>AmbientCapabilities=</varname> will be skipped and not be applied. On systems supporting ambient capabilities, <literal>!!</literal> has no effect and is redundant.</entry>
+ <entry>This prefix is very similar to <literal>!</literal>, however it only has an effect on systems lacking support for ambient process capabilities, i.e. without support for <varname>AmbientCapabilities=</varname>. It's intended to be used for unit files that take benefit of ambient capabilities to run processes with minimal privileges wherever possible while remaining compatible with systems that lack ambient capabilities support. Note that when <literal>!!</literal> is used, and a system lacking ambient capability support is detected any configured <varname>SystemCallFilter=</varname> and <varname>CapabilityBoundingSet=</varname> stanzas are implicitly modified, in order to permit spawned processes to drop credentials and capabilities themselves, even if this is configured to not be allowed. Moreover, if this prefix is used and a system lacking ambient capability support is detected <varname>AmbientCapabilities=</varname> will be skipped and not be applied. On systems supporting ambient capabilities, <literal>!!</literal> has no effect and is redundant.</entry>
</row>
</tbody>
</tgroup>
<literal>+</literal>/<literal>!</literal>/<literal>!!</literal> may be used together and they can appear in any
order. However, only one of <literal>+</literal>, <literal>!</literal>, <literal>!!</literal> may be used at a
time. Note that these prefixes are also supported for the other command line settings,
- i.e. <varname>ExecStartPre=</varname>, <varname>ExecStartPost=</varname>, <varname>ExecReload</varname>,
+ i.e. <varname>ExecStartPre=</varname>, <varname>ExecStartPost=</varname>, <varname>ExecReload=</varname>,
<varname>ExecStop=</varname> and <varname>ExecStopPost=</varname>.</para>
<para>If more than one command is specified, the commands are
start-up failed, for example because any of the commands specified in <varname>ExecStart=</varname>,
<varname>ExecStartPre=</varname> or <varname>ExecStartPost=</varname> failed (and weren't prefixed with
<literal>-</literal>, see above) or timed out. Use <varname>ExecStopPost=</varname> to invoke commands when a
- service failed to start up correctly and is shut down again.</para>
+ service failed to start up correctly and is shut down again. Also note that, service restart requests are
+ implemented as stop operations followed by start operations. This means that <varname>ExecStop=</varname> and
+ <varname>ExecStopPost=</varname> are executed during a service restart operation.</para>
<para>It is recommended to use this setting for commands that communicate with the service requesting clean
termination. When the commands specified with this option are executed it should be assumed that the service is
considered clean service terminations.
</para>
- <para>Note that if a process has a signal handler installed
- and exits by calling
- <citerefentry><refentrytitle>_exit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
- in response to a signal, the information about the signal is
- lost. Programs should instead perform cleanup and kill
- themselves with the same signal instead. See
- <ulink url="http://www.cons.org/cracauer/sigint.html">Proper
- handling of SIGINT/SIGQUIT — How to be a proper
- program</ulink>.</para>
-
<para>This option may appear more than once, in which case the
list of successful exit statuses is merged. If the empty
string is assigned to this option, the list is reset, all
effect.</para></listitem>
</varlistentry>
- <varlistentry>
- <term><varname>FailureAction=</varname></term>
- <listitem><para>Configure the action to take when the service enters a failed state. Takes the same values as
- the unit setting <varname>StartLimitAction=</varname> and executes the same actions (see
- <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>). Defaults to
- <option>none</option>. </para></listitem>
- </varlistentry>
-
<varlistentry>
<term><varname>FileDescriptorStoreMax=</varname></term>
<listitem><para>Configure how many file descriptors may be stored in the service manager for the service using
projects / thirdparty / systemd.git / blobdiff