On Fri, Mar 29, 2024 at 11:10:56AM +0000, le...@solinno.co.uk wrote:
> diff --git a/docs/man/xenwatchdogd.8.pod b/docs/man/xenwatchdogd.8.pod
> new file mode 100644
> index 0000000000..2f6454f183
> --- /dev/null
> +++ b/docs/man/xenwatchdogd.8.pod
> @@ -0,0 +1,54 @@
> +=head1 NAME
> +
> +xenwatchdogd - Xen hypercall based watchdog daemon
> +
> +=head1 SYNOPSIS
> +
> +B<xenwatchdogd> [ I<OPTIONS> ] <I<TIMEOUT>> [ <I<SLEEP>> ]
> +
> +=head1 DESCRIPTION
> +
> +B<xenwatchdogd> arms the Xen watchdog timer to I<TIMEOUT> every I<SLEEP>
> +seconds. If the xenwatchdogd process dies or is delayed for more than
> +I<TIMEOUT> seconds, then Xen will reboot the domain.
Xen will not reboot the domain, it will just kill the domain with
watchdog as explanation. I think the toolstack is in charge of rebooting
the domain. There's a setting for `xl` created VM named
on_watchdog="ACTION", which by default is "destroy". So it's more likely
that the domain will be killed rather than rebooted.
So something like:
Depending on the configuration for the guest, the domain might be
destroyed, rebooted, or other. See B<on_watchdog> in xl.cfg(5)
> + If the domain being
> +rebooted is domain 0, the whole system will reboot.
Maybe something like "if B<xenwatchdogd> is running in dom0, the whole
system will reboot". I'm not sure if the host reboot in this case by
default, probably.
> +=head1 SIGNALS
> +
> +B<SIGUSR1> Will cause the program to disarm the watchdog timer and exit,
> +regardless of whether the safe exit option was passed.
"whether B<--safe-exit> option" ..
I think it's better to call-out the option explicitly.
Thanks,
--
Anthony PERARD
