From: Franck Bui Date: Mon, 27 Sep 2021 08:16:09 +0000 (+0200) Subject: watchdog: update the documentation X-Git-Tag: v250-rc1~510^2~3 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=807938e7ecceddde1879a5e5a993189a5f8564dc;p=thirdparty%2Fsystemd.git watchdog: update the documentation While at it, split the watchdog section into a few paragraphs to make it easier to read as it becomes lengthy. --- diff --git a/man/systemd-system.conf.xml b/man/systemd-system.conf.xml index 5824e01e0c8..4172ec00ab2 100644 --- a/man/systemd-system.conf.xml +++ b/man/systemd-system.conf.xml @@ -133,33 +133,46 @@ RebootWatchdogSec= KExecWatchdogSec= - Configure the hardware watchdog at runtime and at reboot. Takes a timeout value in seconds (or - in other time units if suffixed with ms, min, h, - d, w). If RuntimeWatchdogSec= is set to a non-zero - value, the watchdog hardware (/dev/watchdog or the path specified with - WatchdogDevice= or the kernel option systemd.watchdog-device=) 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. RebootWatchdogSec= 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 RebootWatchdogSec= 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 systemd-shutdown - binary, see system bootup7 - for details. During the first phase of the shutdown operation the system and service manager remains running - and hence RuntimeWatchdogSec= is still honoured. In order to define a timeout on this first - phase of system shutdown, configure JobTimeoutSec= and JobTimeoutAction= - in the [Unit] section of the shutdown.target unit. By default - RuntimeWatchdogSec= defaults to 0 (off), and RebootWatchdogSec= to - 10min. KExecWatchdogSec= may be used to additionally enable the watchdog when kexec - is being executed rather than when rebooting. Note that if the kernel does not reset the watchdog on kexec (depending - on the specific hardware and/or driver), in this case the watchdog might not get disabled after kexec succeeds - and thus the system might get rebooted, unless RuntimeWatchdogSec= is also enabled at the same time. - For this reason it is recommended to enable KExecWatchdogSec= only if - RuntimeWatchdogSec= is also enabled. - These settings have no effect if a hardware watchdog is not available. + Configure the hardware watchdog at runtime and at reboot. Takes a timeout value in + seconds (or in other time units if suffixed with ms, min, + h, d, w). If set to zero the watchdog logic + is disabled: no watchdog device is opened, configured, or pinged. If set to the special string + infinity the watchdog is opened and pinged in regular intervals, but the timeout + is not changed from the default. If set to any other time value the watchdog timeout is configured to + the specified value (or a value close to it, depending on hardware capabilities). + + If RuntimeWatchdogSec= is set to a non-zero value, the watchdog hardware + (/dev/watchdog or the path specified with WatchdogDevice= or + the kernel option systemd.watchdog-device=) 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. + + RebootWatchdogSec= 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 RebootWatchdogSec= 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 + systemd-shutdown binary, see system + bootup7 for + details. During the first phase of the shutdown operation the system and service manager remains + running and hence RuntimeWatchdogSec= is still honoured. In order to define a + timeout on this first phase of system shutdown, configure JobTimeoutSec= and + JobTimeoutAction= in the [Unit] section of the + shutdown.target unit. By default RuntimeWatchdogSec= defaults + to 0 (off), and RebootWatchdogSec= to 10min. + + KExecWatchdogSec= may be used to additionally enable the watchdog when kexec + is being executed rather than when rebooting. Note that if the kernel does not reset the watchdog on + kexec (depending on the specific hardware and/or driver), in this case the watchdog might not get + disabled after kexec succeeds and thus the system might get rebooted, unless + RuntimeWatchdogSec= is also enabled at the same time. For this reason it is + recommended to enable KExecWatchdogSec= only if + RuntimeWatchdogSec= is also enabled. + + These settings have no effect if a hardware watchdog is not available.