<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for the common options of all unit configuration files. The common
configuration items are configured in the generic
- <literal>[Unit]</literal> and <literal>[Install]</literal>
+ [Unit] and [Install]
sections. The service specific configuration options are
- configured in the <literal>[Service]</literal> section.</para>
+ configured in the [Service] section.</para>
<para>Additional options are listed in
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<refsect1>
<title>Options</title>
- <para>Service files must include a <literal>[Service]</literal>
+ <para>Service files must include a [Service]
section, which carries information about the service and the
process it supervises. A number of options that may be used in
this section are shared with other unit types. These options are
<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
and
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
- The options specific to the <literal>[Service]</literal> section
+ The options specific to the [Service] section
of service units are the following:</para>
<variablelist class='unit-directives'>
this notification message has been sent. If this option is used, <varname>NotifyAccess=</varname> (see
below) should be set to open access to the notification socket provided by systemd. If
<varname>NotifyAccess=</varname> is missing or set to <option>none</option>, it will be forcibly set to
- <option>main</option></para></listitem>.
+ <option>main</option>.</para></listitem>
<listitem><para>Behavior of <option>idle</option> is very similar to <option>simple</option>; however,
actual execution of the service program is delayed until all active jobs are dispatched. This may be used
<varlistentry>
<term><varname>TimeoutStartSec=</varname></term>
- <listitem><para>Configures the time to wait for start-up. If a
- daemon service does not signal start-up completion within the
- configured time, the service will be considered failed and
- will be shut down again. Takes a unit-less value in seconds,
- or a time span value such as "5min 20s". Pass
- <literal>infinity</literal> to disable the timeout logic. Defaults to
- <varname>DefaultTimeoutStartSec=</varname> from the manager
- configuration file, except when
- <varname>Type=oneshot</varname> is used, in which case the
- timeout is disabled by default (see
+ <listitem><para>Configures the time to wait for start-up. If a daemon service does not signal start-up
+ completion within the configured time, the service will be considered failed and will be shut down again. The
+ precise action depends on the <varname>TimeoutStartFailureMode=</varname> option. Takes a unit-less value in
+ seconds, or a time span value such as "5min 20s". Pass <literal>infinity</literal> to disable the timeout logic.
+ Defaults to <varname>DefaultTimeoutStartSec=</varname> from the manager configuration file, except when
+ <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>
<listitem><para>This option serves two purposes. First, it configures the time to wait for each
<varname>ExecStop=</varname> command. If any of them times out, subsequent <varname>ExecStop=</varname> commands
are skipped and the service will be terminated by <constant>SIGTERM</constant>. If no <varname>ExecStop=</varname>
- commands are specified, the service gets the <constant>SIGTERM</constant> immediately. Second, it configures the time
+ commands are specified, the service gets the <constant>SIGTERM</constant> immediately. This default behavior
+ can be changed by the <varname>TimeoutStopFailureMode=</varname> option. 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>).
</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>TimeoutStartFailureMode=</varname></term>
+ <term><varname>TimeoutStopFailureMode=</varname></term>
+
+ <listitem><para>These options configure the action that is taken in case a daemon service does not signal
+ start-up within its configured <varname>TimeoutStartSec=</varname>, respectively if it does not stop within
+ <varname>TimeoutStopSec=</varname>. Takes one of <option>terminate</option>, <option>abort</option> and
+ <option>kill</option>. Both options default to <option>terminate</option>.</para>
+
+ <para>If <option>terminate</option> is set the service will be gracefully terminated by sending the signal
+ specified in <varname>KillSignal=</varname> (defaults to <constant>SIGTERM</constant>, see
+ <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). If the
+ service does not terminate the <varname>FinalKillSignal=</varname> is sent after
+ <varname>TimeoutStopSec=</varname>. If <option>abort</option> is set, <varname>WatchdogSignal=</varname> is sent
+ instead and <varname>TimeoutAbortSec=</varname> applies before sending <varname>FinalKillSignal=</varname>.
+ This setting may be used to analyze services that fail to start-up or shut-down intermittently.
+ By using <option>kill</option> the service is immediately terminated by sending
+ <varname>FinalKillSignal=</varname> without any further timeout. This setting can be used to expedite the
+ shutdown of failing services.
+ </para></listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>RuntimeMaxSec=</varname></term>
project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
a list of signal names.</para>
- <para>Note that this setting does not change the the mapping between numeric exit statuses and their
+ <para>Note that this setting does not change the mapping between numeric exit statuses and their
names, i.e. regardless how this setting is used 0 will still be mapped to <literal>SUCCESS</literal>
(and thus typically shown as <literal>0/SUCCESS</literal> in tool outputs) and 1 to
<literal>FAILURE</literal> (and thus typically shown as <literal>1/FAILURE</literal>), and so on. It
this option will have no effect.</para>
<example>
- <title>A service with with the <varname>SuccessExitStatus=</varname> setting</title>
+ <title>A service with the <varname>SuccessExitStatus=</varname> setting</title>
<programlisting>SuccessExitStatus=TEMPFAIL 250 SIGUSR1</programlisting>
<para>Exit status 75 (<constant>TEMPFAIL</constant>), 250, and the termination signal
- <constant>SIGKILL</constant> are considered clean service terminations.</para>
+ <constant>SIGUSR1</constant> are considered clean service terminations.</para>
</example>
<para>Note: <command>systemd-analyze exit-status</command> may be used to list exit statuses and
manager. If set to <constant>kill</constant> and one of the service's processes is killed by the OOM
killer the kernel is instructed to kill all remaining processes of the service, too. Defaults to the
setting <varname>DefaultOOMPolicy=</varname> in
- <citerefentry><refentrytitle>system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> is
- set to, except for services where <varname>Delegate=</varname> is turned on, where it defaults to
+ <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ is set to, except for services where <varname>Delegate=</varname> is turned on, where it defaults to
<constant>continue</constant>.</para>
<para>Use the <varname>OOMScoreAdjust=</varname> setting to configure whether processes of the unit
WantedBy=multi-user.target</programlisting>
<para>For <emphasis>bus-activatable</emphasis> services, do not
- include a <literal>[Install]</literal> section in the systemd
+ include a [Install] section in the systemd
service file, but use the <varname>SystemdService=</varname>
option in the corresponding DBus service file, for example
(<filename>/usr/share/dbus-1/system-services/org.example.simple-dbus-service.service</filename>):</para>
projects / thirdparty / systemd.git / blobdiff