"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
<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
<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 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
- 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>
<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
<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>
<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 acheived by <literal>STOPPING=1</literal> (or termination). (see
+ <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
+ </para></listitem>
</varlistentry>
<varlistentry>
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
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
<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>
+ <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
projects / thirdparty / systemd.git / blobdiff