shaba/systemd-stable
1
1
Fork 0
mirror of https://github.com/systemd/systemd-stable.git synced 2024-12-22 13:33:56 +03:00
Code

man: document the RestartKillSignal= setting

Browse Source
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2019-10-02 13:53:49 +02:00
parent a232ebcc2c
commit b557f1c147
2 changed files with 37 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
man/systemd.kill.xml
View File

@ -85,32 +85,36 @@
unless it is empty.</para>
<para>Processes will first be terminated via <constant>SIGTERM</constant> (unless the signal to send
is changed via <varname>KillSignal=</varname>). Optionally, this is immediately followed by a
<constant>SIGHUP</constant> (if enabled with <varname>SendSIGHUP=</varname>). If processes still
remain after the main process of a unit has exited or the delay configured via the
<varname>TimeoutStopSec=</varname> has passed, the termination request is repeated with the
<constant>SIGKILL</constant> signal or the signal specified via <varname>FinalKillSignal=</varname>
(unless this is disabled via the <varname>SendSIGKILL=</varname> option). See
<citerefentry><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry> for more
information.</para>
is changed via <varname>KillSignal=</varname> or <varname>RestartKillSignal=</varname>). Optionally,
this is immediately followed by a <constant>SIGHUP</constant> (if enabled with
<varname>SendSIGHUP=</varname>). If processes still remain after the main process of a unit has
exited or the delay configured via the <varname>TimeoutStopSec=</varname> has passed, the termination
request is repeated with the <constant>SIGKILL</constant> signal or the signal specified via
<varname>FinalKillSignal=</varname> (unless this is disabled via the <varname>SendSIGKILL=</varname>
option). See <citerefentry><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>
for more information.</para>
<para>Defaults to <option>control-group</option>.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>KillSignal=</varname></term>
<listitem><para>Specifies which signal to use when killing a
service. This controls the signal that is sent as first step
of shutting down a unit (see above), and is usually followed
by <constant>SIGKILL</constant> (see above and below). For a
list of valid signals, see
<listitem><para>Specifies which signal to use when stopping a service. This controls the signal that
is sent as first step of shutting down a unit (see above), and is usually followed by
<constant>SIGKILL</constant> (see above and below). For a list of valid signals, see
<citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
Defaults to <constant>SIGTERM</constant>. </para>
Defaults to <constant>SIGTERM</constant>.</para>
<para>Note that, right after sending the signal specified in
this setting, systemd will always send
<constant>SIGCONT</constant>, to ensure that even suspended
tasks can be terminated cleanly.</para>
<para>Note that, right after sending the signal specified in this setting, systemd will always send
<constant>SIGCONT</constant>, to ensure that even suspended tasks can be terminated cleanly.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>RestartKillSignal=</varname></term>
<listitem><para>Specifies which signal to use when restarting a service. The same as
<varname>KillSignal=</varname> described above, with the exception that this setting is used in a
restart job. Not set by default, and the value of <varname>KillSignal=</varname> is used.</para>
</listitem>
</varlistentry>

32
man/systemd.service.xml
View File

@ -477,26 +477,24 @@
<varlistentry>
<term><varname>ExecStop=</varname></term>
<listitem><para>Commands to execute to stop the service
started via <varname>ExecStart=</varname>. This argument takes
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, it is implied that the service is stopped, and any processes
remaining for it are terminated
according to the <varname>KillMode=</varname> setting (see
<listitem><para>Commands to execute to stop the service started via
<varname>ExecStart=</varname>. This argument takes 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, 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
sending the signal specified in <varname>KillSignal=</varname>
when service stop is requested. Specifier and environment
variable substitution is supported (including
If this option is not specified, the process is terminated by sending the signal specified in
<varname>KillSignal=</varname> or <varname>RestartKillSignal=</varname> when service stop is
requested. Specifier and environment 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 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 it is usually not sufficient to specify a command for this setting that only asks the
service to terminate (for example, by sending some form of termination signal to 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> or
<varname>RestartKillSignal=</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