1
1
mirror of https://github.com/systemd/systemd-stable.git synced 2024-12-23 17:34:00 +03:00

Merge pull request #8533 from poettering/bootup-shutdown-phase2

extend docs on second phase of shutdown and watchdog handling
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2018-03-23 15:11:46 +01:00 committed by GitHub
commit f01eca96d0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 36 additions and 28 deletions

View File

@ -298,8 +298,18 @@ systemd-reboot.service systemd-poweroff.service systemd-halt.service syste
v v v v
<emphasis>reboot.target</emphasis> <emphasis>poweroff.target</emphasis> <emphasis>halt.target</emphasis> <emphasis>kexec.target</emphasis></programlisting>
<para>Commonly used system shutdown targets are
<emphasis>emphasized</emphasis>.</para>
<para>Commonly used system shutdown targets are <emphasis>emphasized</emphasis>.</para>
<para>Note that
<citerefentry>system<refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<filename>systemd-reboot.service</filename>, <filename>systemd-poweroff.service</filename> and
<filename>systemd-kexec.service</filename> will transition the system and server manager (PID 1) into the second
phase of system shutdown (implemented in the <filename>systemd-shutdown</filename> binary), which will unmount any
remaining file systems, kill any remaining processes and release any other remaining resources, in a simple and
robust fashion, without taking any service or unit concept into account anymore. At that point, regular
applications and resources are generally terminated and released already, the second phase hence operates only as
safety net for everything that couldn't be stopped or released for some reason during the primary, unit-based
shutdown phase described above.</para>
</refsect1>
<refsect1>
@ -309,6 +319,7 @@ systemd-reboot.service systemd-poweroff.service systemd-halt.service syste
<citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
</para>
</refsect1>

View File

@ -114,7 +114,8 @@
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
<citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
<citerefentry><refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>
</para>
</refsect1>

View File

@ -157,31 +157,27 @@
<term><varname>RuntimeWatchdogSec=</varname></term>
<term><varname>ShutdownWatchdogSec=</varname></term>
<listitem><para>Configure the hardware watchdog at runtime and
at reboot. Takes a timeout value in seconds (or in other time
units if suffixed with <literal>ms</literal>,
<literal>min</literal>, <literal>h</literal>,
<literal>d</literal>, <literal>w</literal>). If
<varname>RuntimeWatchdogSec=</varname> is set to a non-zero
value, the watchdog hardware
(<filename>/dev/watchdog</filename> or the path specified with
<varname>WatchdogDevice=</varname> or the kernel option
<varname>systemd.watchdog-device=</varname>) will be programmed
to automatically reboot the system if it is not contacted within
the specified timeout interval. The system manager will ensure
to contact it at least once in half the specified timeout
interval. This feature requires a hardware watchdog device to
be present, as it is commonly the case in embedded and server
systems. Not all hardware watchdogs allow configuration of the
reboot timeout, in which case the closest available timeout is
picked. <varname>ShutdownWatchdogSec=</varname> may be used to
configure the hardware watchdog when the system is asked to
reboot. It works as a safety net to ensure that the reboot
takes place even if a clean reboot attempt times out. By
default <varname>RuntimeWatchdogSec=</varname> defaults to 0
(off), and <varname>ShutdownWatchdogSec=</varname> to 10min.
These settings have no effect if a hardware watchdog is not
available.</para></listitem>
<listitem><para>Configure the hardware watchdog at runtime and at reboot. Takes a timeout value in seconds (or
in other time units if suffixed with <literal>ms</literal>, <literal>min</literal>, <literal>h</literal>,
<literal>d</literal>, <literal>w</literal>). If <varname>RuntimeWatchdogSec=</varname> is set to a non-zero
value, the watchdog hardware (<filename>/dev/watchdog</filename> or the path specified with
<varname>WatchdogDevice=</varname> or the kernel option <varname>systemd.watchdog-device=</varname>) will be
programmed to automatically reboot the system if it is not contacted within the specified timeout interval. The
system manager will ensure to contact it at least once in half the specified timeout interval. This feature
requires a hardware watchdog device to be present, as it is commonly the case in embedded and server
systems. Not all hardware watchdogs allow configuration of all possible reboot timeout values, in which case
the closest available timeout is picked. <varname>ShutdownWatchdogSec=</varname> may be used to configure the
hardware watchdog when the system is asked to reboot. It works as a safety net to ensure that the reboot takes
place even if a clean reboot attempt times out. Note that the <varname>ShutdownWatchdogSec=</varname> timeout
applies only to the second phase of the reboot, i.e. after all regular services are already terminated, and
after the system and service manager process (PID 1) got replaced by the <filename>systemd-shutdown</filename>
binary, see system <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>
for details. During the first phase of the shutdown operation the system and service manager remains running
and hence <varname>RuntimeWatchdogSec=</varname> is still honoured. In order to define a timeout on this first
phase of system shutdown, configure <varname>JobTimeoutSec=</varname> and <varname>JobTimeoutAction=</varname>
in the <literal>[Unit]</literal> section of the <filename>shutdown.target</filename> unit. By default
<varname>RuntimeWatchdogSec=</varname> defaults to 0 (off), and <varname>ShutdownWatchdogSec=</varname> to
10min. These settings have no effect if a hardware watchdog is not available.</para></listitem>
</varlistentry>
<varlistentry>