-<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<?xml version='1.0'?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!--
- This file is part of systemd.
-
- Copyright 2010 Lennart Poettering
-
- systemd is free software; you can redistribute it and/or modify it
- under the terms of the GNU Lesser General Public License as published by
- the Free Software Foundation; either version 2.1 of the License, or
- (at your option) any later version.
-
- systemd is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
-
- You should have received a copy of the GNU Lesser General Public License
- along with systemd; If not, see <http://www.gnu.org/licenses/>.
+ SPDX-License-Identifier: LGPL-2.1+
-->
<refentry id="systemd.service">
<refentryinfo>
<title>systemd.service</title>
<productname>systemd</productname>
-
- <authorgroup>
- <author>
- <contrib>Developer</contrib>
- <firstname>Lennart</firstname>
- <surname>Poettering</surname>
- <email>lennart@poettering.net</email>
- </author>
- </authorgroup>
</refentryinfo>
<refmeta>
<title>Description</title>
<para>A unit configuration file whose name ends in
- <filename>.service</filename> encodes information about a process
+ <literal>.service</literal> encodes information about a process
controlled and supervised by systemd.</para>
<para>This man page lists the configuration options specific to
This is useful for compatibility with SysV. Note that this
compatibility is quite comprehensive but not 100%. For details
about the incompatibilities, see the <ulink
- url="http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities
+ url="https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities
with SysV</ulink> document.</para>
</refsect1>
+ <refsect1>
+ <title>Service Templates</title>
+
+ <para>It is possible for <command>systemd</command> services to take a single argument via the
+ <literal><replaceable>service</replaceable>@<replaceable>argument</replaceable>.service</literal>
+ syntax. Such services are called "instantiated" services, while the unit definition without the
+ <replaceable>argument</replaceable> parameter is called a "template". An example could be a
+ <filename>dhcpcd@.service</filename> service template which takes a network interface as a
+ parameter to form an instantiated service. Within the service file, this parameter or "instance
+ name" can be accessed with %-specifiers. See
+ <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for details.</para>
+ </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>
-
- <para>Additional implicit dependencies may be added as result of
- execution and resource control parameters as documented in
- <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- and
- <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+ <refsect2>
+ <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.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ and
+ <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+ </refsect2>
+
+ <refsect2>
+ <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>
+ </refsect2>
</refsect1>
<refsect1>
process it supervises. A number of options that may be used in
this section are shared with other unit types. These options are
documented in
- <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
and
- <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+ <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
The options specific to the <literal>[Service]</literal> section
of service units are the following:</para>
process has to exit before systemd starts follow-up units.
<varname>RemainAfterExit=</varname> is particularly useful for
this type of service. This is the implied default if neither
- <varname>Type=</varname> or <varname>ExecStart=</varname> are
+ <varname>Type=</varname> nor <varname>ExecStart=</varname> are
specified.</para>
<para>Behavior of <option>dbus</option> is similar to
<varname>PrivateNetwork=</varname><option>yes</option>.</para>
<para>Behavior of <option>idle</option> is very similar to <option>simple</option>; however, actual execution
- of the service binary is delayed until all active jobs are dispatched. This may be used to avoid interleaving
+ of the service program is delayed until all active jobs are dispatched. This may be used to avoid interleaving
of output of shell services with the status output on the console. Note that this type is useful only to
improve console output, it is not useful as a general unit ordering tool, and the effect of this service type
- is subject to a 5s time-out, after which the service binary is invoked anyway.</para>
+ is subject to a 5s time-out, after which the service program is invoked anyway.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>PIDFile=</varname></term>
- <listitem><para>Takes an absolute file name 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
- main process of the daemon after start-up of the service.
- systemd will not write to the file configured here, although
- it will remove the file after the service has shut down if it
- still exists.
- </para>
- </listitem>
+ <listitem><para>Takes an absolute path referring to the PID file of the service. Usage of this option is
+ recommended for services where <varname>Type=</varname> is set to <option>forking</option>. The service manager
+ will read the PID of the main process of the service from this file after start-up of the service. The service
+ manager will not write to the file configured here, although it will remove the file after the service has shut
+ down if it still exists. The PID file does not need to be owned by a privileged user, but if it is owned by an
+ unprivileged user additional safety restrictions are enforced: the file may not be a symlink to a file owned by
+ a different user (neither directly nor indirectly), and the PID file must refer to a process already belonging
+ to the service.</para></listitem>
</varlistentry>
<varlistentry>
providing multiple command lines in the same directive, or alternatively, this directive may be specified more
than once with the same effect. If the empty string is assigned to this option, the list of commands to start
is reset, prior assignments of this option will have no effect. If no <varname>ExecStart=</varname> is
- specified, then the service must have <varname>RemainAfterExit=yes</varname> set.</para>
+ specified, then the service must have <varname>RemainAfterExit=yes</varname> and at least one
+ <varname>ExecStop=</varname> line set. (Services lacking both <varname>ExecStart=</varname> and
+ <varname>ExecStop=</varname> are not valid.)</para>
+
+ <para>For each of the specified commands, the first argument must be either an absolute path to an executable
+ or a simple file name without any slashes. Optionally, this filename may be prefixed with a number of special
+ characters:</para>
+
+ <table>
+ <title>Special executable prefixes</title>
- <para>For each of the specified commands, the first argument must be an absolute path to an
- executable. Optionally, if this file name is prefixed with <literal>@</literal>, the second token will be
- passed as <literal>argv[0]</literal> to the executed process, followed by the further arguments specified. If
- the absolute filename is prefixed with <literal>-</literal>, an exit code of the command normally considered a
- failure (i.e. non-zero exit status or abnormal exit due to signal) is ignored and considered success. If the
- absolute path is prefixed with <literal>+</literal> then it is executed with full
- privileges. <literal>@</literal>, <literal>-</literal>, and <literal>+</literal> may be used together and they
- can appear in any order.</para>
+ <tgroup cols='2'>
+ <colspec colname='prefix'/>
+ <colspec colname='meaning'/>
+
+ <thead>
+ <row>
+ <entry>Prefix</entry>
+ <entry>Effect</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><literal>@</literal></entry>
+ <entry>If the executable path is prefixed with <literal>@</literal>, the second specified token will be passed as <literal>argv[0]</literal> to the executed process (instead of the actual filename), followed by the further arguments specified.</entry>
+ </row>
+
+ <row>
+ <entry><literal>-</literal></entry>
+ <entry>If the executable path is prefixed with <literal>-</literal>, an exit code of the command normally considered a failure (i.e. non-zero exit status or abnormal exit due to signal) is recorded, but has no further effect and is considered equivalent to success.</entry>
+ </row>
+
+ <row>
+ <entry><literal>+</literal></entry>
+ <entry>If the executable path is prefixed with <literal>+</literal> then the process is executed with full privileges. In this mode privilege restrictions configured with <varname>User=</varname>, <varname>Group=</varname>, <varname>CapabilityBoundingSet=</varname> or the various file system namespacing options (such as <varname>PrivateDevices=</varname>, <varname>PrivateTmp=</varname>) are not applied to the invoked command line (but still affect any other <varname>ExecStart=</varname>, <varname>ExecStop=</varname>, … lines).</entry>
+ </row>
+
+ <row>
+ <entry><literal>!</literal></entry>
+
+ <entry>Similar to the <literal>+</literal> character discussed above this permits invoking command lines with elevated privileges. However, unlike <literal>+</literal> the <literal>!</literal> character exclusively alters the effect of <varname>User=</varname>, <varname>Group=</varname> and <varname>SupplementaryGroups=</varname>, i.e. only the stanzas that affect user and group credentials. Note that this setting may be combined with <varname>DynamicUser=</varname>, in which case a dynamic user/group pair is allocated before the command is invoked, but credential changing is left to the executed process itself.</entry>
+ </row>
+
+ <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>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para><literal>@</literal>, <literal>-</literal>, and one of
+ <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>,
+ <varname>ExecStop=</varname> and <varname>ExecStopPost=</varname>.</para>
<para>If more than one command is specified, the commands are
invoked sequentially in the order they appear in the unit
all <varname>ExecStartPre=</varname> commands that were not prefixed
with a <literal>-</literal> exit successfully.</para>
- <para><varname>ExecStartPost=</varname> commands are only run after
- the service has started successfully, as determined by <varname>Type=</varname>
- (i.e. the process has been started for <varname>Type=simple</varname>
- or <varname>Type=idle</varname>, the process exits successfully for
- <varname>Type=oneshot</varname>, the initial process exits successfully
- for <varname>Type=forking</varname>, <literal>READY=1</literal> is sent
- for <varname>Type=notify</varname>, or the <varname>BusName=</varname>
- has been taken for <varname>Type=dbus</varname>).</para>
+ <para><varname>ExecStartPost=</varname> commands are only run after the commands specified in
+ <varname>ExecStart=</varname> have been invoked successfully, as determined by <varname>Type=</varname>
+ (i.e. the process has been started for <varname>Type=simple</varname> or <varname>Type=idle</varname>, the last
+ <varname>ExecStart=</varname> process exited successfully for <varname>Type=oneshot</varname>, the initial
+ process exited successfully for <varname>Type=forking</varname>, <literal>READY=1</literal> is sent for
+ <varname>Type=notify</varname>, or the <varname>BusName=</varname> has been taken for
+ <varname>Type=dbus</varname>).</para>
<para>Note that <varname>ExecStartPre=</varname> may not be
used to start long-running processes. All processes forked
multiple command lines, following the same scheme as described
for <varname>ExecStart=</varname> above. Use of this setting
is optional. After the commands configured in this option are
- run, all processes remaining for a service are terminated
+ run, it is implied that the service is stopped, and any processes
+ remaining for it are terminated
according to the <varname>KillMode=</varname> setting (see
<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
If this option is not specified, the process is terminated by
variable substitution is supported (including
<varname>$MAINPID</varname>, see above).</para>
- <para>Note that it is usually not sufficient to specify a
- command for this setting that only asks the service to
- terminate (for example, by queuing some form of termination
- signal for it), but does not wait for it to do so. Since the
- remaining processes of the services are killed using
- <constant>SIGKILL</constant> immediately after the command
- exited, this would not result in a clean stop. The specified
- command should hence be a synchronous operation, not an
- asynchronous one.</para>
+ <para>Note that it is usually not sufficient to specify a command for this setting that only asks the service
+ to terminate (for example, by queuing some form of termination signal for it), but does not wait for it to do
+ so. Since the remaining processes of the services are killed according to <varname>KillMode=</varname> and
+ <varname>KillSignal=</varname> as described above immediately after the command exited, this may not result in
+ a clean stop. The specified command should hence be a synchronous operation, not an asynchronous one.</para>
<para>Note that the commands specified in <varname>ExecStop=</varname> are only executed when the service
started successfully first. They are not invoked if the service was never started at all, or in case its
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
<varname>Type=oneshot</varname> is used, in which case the
timeout is disabled by default (see
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+ </para>
+
+ <para>If a service of <varname>Type=notify</varname> sends <literal>EXTEND_TIMEOUT_USEC=…</literal>, this may cause
+ the start time to be extended beyond <varname>TimeoutStartSec=</varname>. The first receipt of this message
+ must occur before <varname>TimeoutStartSec=</varname> is exceeded, and once the start time has exended beyond
+ <varname>TimeoutStartSec=</varname>, the service manager will allow the service to continue to start, provided
+ the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified until the service
+ startup status is finished by <literal>READY=1</literal>. (see
+ <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>TimeoutStopSec=</varname></term>
- <listitem><para>Configures the time to wait for stop. If a
- service is asked to stop, but does not terminate in the
- specified time, it will be terminated forcibly via
- <constant>SIGTERM</constant>, and after another timeout of
- equal duration with <constant>SIGKILL</constant> (see
- <varname>KillMode=</varname> in
+ <listitem><para>This option serves two purposes. First, it configures the time to wait for each
+ <constant>ExecStop=</constant> command. If any of them times out, subsequent <constant>ExecStop=</constant> commands
+ are skipped and the service will be terminated by <constant>SIGTERM</constant>. If no <constant>ExecStop=</constant>
+ commands are specified, the service gets the <constant>SIGTERM</constant> immediately. Second, it configures the time
+ to wait for the service itself to stop. If it doesn't terminate in the specified time, it will be forcibly terminated
+ by <constant>SIGKILL</constant> (see <varname>KillMode=</varname> in
<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
Takes a unit-less value in seconds, or a time span value such
as "5min 20s". Pass <literal>infinity</literal> to disable the
<varname>DefaultTimeoutStopSec=</varname> from the manager
configuration file (see
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+ </para>
+
+ <para>If a service of <varname>Type=notify</varname> sends <literal>EXTEND_TIMEOUT_USEC=…</literal>, this may cause
+ the stop time to be extended beyond <varname>TimeoutStopSec=</varname>. The first receipt of this message
+ must occur before <varname>TimeoutStopSec=</varname> is exceeded, and once the stop time has exended beyond
+ <varname>TimeoutStopSec=</varname>, the service manager will allow the service to continue to stop, provided
+ the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified, or terminates itself
+ (see <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
</para></listitem>
</varlistentry>
active for longer than the specified time it is terminated and put into a failure state. Note that this setting
does not have any effect on <varname>Type=oneshot</varname> services, as they terminate immediately after
activation completed. Pass <literal>infinity</literal> (the default) to configure no runtime
- limit.</para></listitem>
+ limit.</para>
+
+ <para>If a service of <varname>Type=notify</varname> sends <literal>EXTEND_TIMEOUT_USEC=…</literal>, this may cause
+ the runtime to be extended beyond <varname>RuntimeMaxSec=</varname>. The first receipt of this message
+ must occur before <varname>RuntimeMaxSec=</varname> is exceeded, and once the runtime has exended beyond
+ <varname>RuntimeMaxSec=</varname>, the service manager will allow the service to continue to run, provided
+ the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified until the service
+ shutdown is achieved by <literal>STOPPING=1</literal> (or termination). (see
+ <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
+ </para></listitem>
</varlistentry>
<varlistentry>
<para>As exceptions to the setting above, the service will not
be restarted if the exit code or signal is specified in
- <varname>RestartPreventExitStatus=</varname> (see below).
- Also, the services will always be restarted if the exit code
- or signal is specified in
+ <varname>RestartPreventExitStatus=</varname> (see below) or
+ the service is stopped with <command>systemctl stop</command>
+ or an equivalent operation. Also, the services will always be
+ restarted if the exit code or signal is specified in
<varname>RestartForceExitStatus=</varname> (see below).</para>
<para>Note that service restart is subject to unit start rate
limiting configured with <varname>StartLimitIntervalSec=</varname>
and <varname>StartLimitBurst=</varname>, see
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- for details.</para>
+ for details. A restarted service enters the failed state only
+ after the start limits are reached.</para>
<para>Setting this to <option>on-failure</option> is the
recommended choice for long-running services, in order to
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
<varlistentry>
<term><varname>NonBlocking=</varname></term>
- <listitem><para>Set the <constant>O_NONBLOCK</constant> flag
- for all file descriptors passed via socket-based activation.
- If true, all file descriptors >= 3 (i.e. all except stdin,
- stdout, and stderr) will have the
- <constant>O_NONBLOCK</constant> flag set and hence are in
- non-blocking mode. This option is only useful in conjunction
- with a socket unit, as described in
- <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
- Defaults to false.</para></listitem>
+ <listitem><para>Set the <constant>O_NONBLOCK</constant> flag for all file descriptors passed via socket-based
+ activation. If true, all file descriptors >= 3 (i.e. all except stdin, stdout, stderr), excluding those passed
+ in via the file descriptor storage logic (see <varname>FileDescriptorStoreMax=</varname> for details), will
+ have the <constant>O_NONBLOCK</constant> flag set and hence are in non-blocking mode. This option is only
+ useful in conjunction with a socket unit, as described in
+ <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> and has no
+ effect on file descriptors which were previously saved in the file-descriptor store for example. Defaults to
+ false.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>NotifyAccess=</varname></term>
- <listitem><para>Controls access to the service status
- notification socket, as accessible via the
- <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
- call. Takes one of <option>none</option> (the default),
- <option>main</option>, <option>exec</option> or
- <option>all</option>. If <option>none</option>, no daemon status
- updates are accepted from the service processes, all status
- update messages are ignored. If <option>main</option>, only
- service updates sent from the main process of the service are
- accepted. If <option>exec</option>, only service updates sent
- from any of the control processes originating from one of the
- <varname>Exec*=</varname> commands are accepted. If
- <option>all</option>, all services updates from all members of
- the service's control group are accepted. This option should
- be set to open access to the notification socket when using
- <varname>Type=notify</varname> or
- <varname>WatchdogSec=</varname> (see above). If those options
- are used but <varname>NotifyAccess=</varname> is not
- configured, it will be implicitly set to
- <option>main</option>.</para></listitem>
+ <listitem><para>Controls access to the service status notification socket, as accessible via the
+ <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> call. Takes one
+ of <option>none</option> (the default), <option>main</option>, <option>exec</option> or
+ <option>all</option>. If <option>none</option>, no daemon status updates are accepted from the service
+ processes, all status update messages are ignored. If <option>main</option>, only service updates sent from the
+ main process of the service are accepted. If <option>exec</option>, only service updates sent from any of the
+ main or control processes originating from one of the <varname>Exec*=</varname> commands are accepted. If
+ <option>all</option>, all services updates from all members of the service's control group are accepted. This
+ option should be set to open access to the notification socket when using <varname>Type=notify</varname> or
+ <varname>WatchdogSec=</varname> (see above). If those options are used but <varname>NotifyAccess=</varname> is
+ not configured, it will be implicitly set to <option>main</option>.</para>
+
+ <para>Note that <function>sd_notify()</function> notifications may be attributed to units correctly only if
+ either the sending process is still around at the time PID 1 processes the message, or if the sending process
+ is explicitly runtime-tracked by the service manager. The latter is the case if the service manager originally
+ forked off the process, i.e. on all processes that match <option>main</option> or
+ <option>exec</option>. Conversely, if an auxiliary process of the unit sends an
+ <function>sd_notify()</function> message and immediately exits, the service manager might not be able to
+ properly attribute the message to the unit, and thus will ignore it, even if
+ <varname>NotifyAccess=</varname><option>all</option> is set for it.</para></listitem>
</varlistentry>
<varlistentry>
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
+ <listitem><para>Configure how many file descriptors may be stored in the service manager for the service using
<citerefentry><refentrytitle>sd_pid_notify_with_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>'s
- <literal>FDSTORE=1</literal> messages. This is useful for
- implementing service restart schemes where the state is
- serialized to <filename>/run</filename> and the file
- descriptors passed to the service manager, to allow restarts
- without losing state. Defaults to 0, i.e. no file descriptors
- may be stored in the service manager. All file
- descriptors passed to the service manager from a specific
- service are passed back to the service's main process on the
- next service restart. Any file descriptors passed to the
- service manager are automatically closed when POLLHUP or
- POLLERR is seen on them, or when the service is fully stopped
- and no job is queued or being executed for it.</para></listitem>
+ <literal>FDSTORE=1</literal> messages. This is useful for implementing services that can restart after an
+ explicit request or a crash without losing state. Any open sockets and other file descriptors which should not
+ be closed during the restart may be stored this way. Application state can either be serialized to a file in
+ <filename>/run</filename>, or better, stored in a
+ <citerefentry><refentrytitle>memfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry> memory file
+ descriptor. Defaults to 0, i.e. no file descriptors may be stored in the service manager. All file descriptors
+ passed to the service manager from a specific service are passed back to the service's main process on the next
+ service restart. Any file descriptors passed to the service manager are automatically closed when
+ <constant>POLLHUP</constant> or <constant>POLLERR</constant> is seen on them, or when the service is fully
+ stopped and no job is queued or being executed for it. If this option is used, <varname>NotifyAccess=</varname>
+ (see above) should be set to open access to the notification socket provided by systemd. If
+ <varname>NotifyAccess=</varname> is not set, it will be implicitly set to
+ <option>main</option>.</para></listitem>
</varlistentry>
<varlistentry>
as <literal>\;</literal>.</para>
<para>Each command line is split on whitespace, with the first item being the command to
- execute, and the subsequent items being the arguments. Double quotes ("...") and single quotes
- ('...') may be used, in which case everything until the next matching quote becomes part of the
- same argument. Quotes themselves are removed. C-style escapes are also supported. The table
- below contains the list of known escape patterns. Only escape patterns which match the syntax in
- the table are allowed; other patterns may be added in the future and unknown patterns will
- result in a warning. In particular, any backslashes should be doubled. Finally, a trailing
- backslash (<literal>\</literal>) may be used to merge lines.</para>
-
- <para>This syntax is intended to be very similar to shell syntax,
- but only the meta-characters and expansions described in the
- following paragraphs are understood. Specifically, redirection
- using
+ execute, and the subsequent items being the arguments. Double quotes ("…") and single quotes
+ ('…') may be used to wrap a whole item (the opening quote may appear only at the beginning or
+ after whitespace that is not quoted, and the closing quote must be followed by whitespace or the
+ end of line), in which case everything until the next matching quote becomes part of the same
+ argument. Quotes themselves are removed. C-style escapes are also supported. The table below
+ contains the list of known escape patterns. Only escape patterns which match the syntax in the
+ table are allowed; other patterns may be added in the future and unknown patterns will result in
+ a warning. In particular, any backslashes should be doubled. Finally, a trailing backslash
+ (<literal>\</literal>) may be used to merge lines.</para>
+
+ <para>This syntax is inspired by shell syntax, but only the meta-characters and expansions
+ described in the following paragraphs are understood, and the expansion of variables is
+ different. Specifically, redirection using
<literal><</literal>,
<literal><<</literal>,
<literal>></literal>, and
<literal>&</literal>, and <emphasis>other elements of shell
syntax are not supported</emphasis>.</para>
- <para>The command to execute must be an absolute path name. It may
- contain spaces, but control characters are not allowed.</para>
+ <para>The command to execute may contain spaces, but control characters are not allowed.</para>
- <para>The command line accepts <literal>%</literal> specifiers as
- described in
- <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
- Note that the first argument of the command line (i.e. the program
- to execute) may not include specifiers.</para>
+ <para>The command line accepts <literal>%</literal> specifiers as described in
+ <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
<para>Basic environment variable substitution is supported. Use
<literal>${FOO}</literal> as part of a word, or as a word of its
For this type of expansion, quotes are respected when splitting
into words, and afterwards removed.</para>
+ <para>If the command is not a full (absolute) path, it will be resolved to a full path using a
+ fixed search path determinted at compilation time. Searched directories include
+ <filename>/usr/local/bin/</filename>, <filename>/usr/bin/</filename>, <filename>/bin/</filename>
+ on systems using split <filename>/usr/bin/</filename> and <filename>/bin/</filename>
+ directories, and their <filename>sbin/</filename> counterparts on systems using split
+ <filename>bin/</filename> and <filename>sbin/</filename>. It is thus safe to use just the
+ executable name in case of executables located in any of the "standard" directories, and an
+ absolute path must be used in other cases. Using an absolute path is recommended to avoid
+ ambiguity. Hint: this search path may be queried using
+ <command>systemd-path search-binaries-default</command>.</para>
+
<para>Example:</para>
<programlisting>Environment="ONE=one" 'TWO=two two'
-ExecStart=/bin/echo $ONE $TWO ${TWO}</programlisting>
+ExecStart=echo $ONE $TWO ${TWO}</programlisting>
<para>This will execute <command>/bin/echo</command> with four
arguments: <literal>one</literal>, <literal>two</literal>,
<programlisting>Environment=ONE='one' "TWO='two two' too" THREE=
ExecStart=/bin/echo ${ONE} ${TWO} ${THREE}
ExecStart=/bin/echo $ONE $TWO $THREE</programlisting>
- <para>This results in <filename>echo</filename> being
+ <para>This results in <filename>/bin/echo</filename> being
called twice, the first time with arguments
<literal>'one'</literal>,
<literal>'two two' too</literal>, <literal></literal>,
<para>Note that shell command lines are not directly supported. If
shell command lines are to be used, they need to be passed
explicitly to a shell implementation of some kind. Example:</para>
- <programlisting>ExecStart=/bin/sh -c 'dmesg | tac'</programlisting>
+ <programlisting>ExecStart=sh -c 'dmesg | tac'</programlisting>
<para>Example:</para>
- <programlisting>ExecStart=/bin/echo one ; /bin/echo "two two"</programlisting>
+ <programlisting>ExecStart=echo one ; echo "two two"</programlisting>
- <para>This will execute <command>/bin/echo</command> two times,
+ <para>This will execute <command>echo</command> two times,
each time with one argument: <literal>one</literal> and
<literal>two two</literal>, respectively. Because two commands are
specified, <varname>Type=oneshot</varname> must be used.</para>
<para>Example:</para>
- <programlisting>ExecStart=/bin/echo / >/dev/null & \; \
-/bin/ls</programlisting>
+ <programlisting>ExecStart=echo / >/dev/null & \; \
+ls</programlisting>
- <para>This will execute <command>/bin/echo</command>
+ <para>This will execute <command>echo</command>
with five arguments: <literal>/</literal>,
<literal>>/dev/null</literal>,
<literal>&</literal>, <literal>;</literal>, and
- <literal>/bin/ls</literal>.</para>
+ <literal>ls</literal>.</para>
<table>
<title>C escapes supported in command lines and environment variables</title>
projects / thirdparty / systemd.git / blobdiff