Add support for (emulated) i6300ESB watchdog

[sbyx]

I6300ESB is the watchdog device able to be emulated via qemu/kvm e.g. with Proxmox. This enables watchdog support based on an existing HA addon like the one in https://github.com/alex107ivanov/hassio-addons

[jens-maus]

Sorry, but I don't get the idea of using a dedicated HA addon for activating the watchdog daemon? AFAIK HomeAssistantOS already comes with the busybox watchdog daemon. It might just require to actually provide a systemd init script to get it activated for the underlying hardware so that in case a hardware watchdog exists the hardware / or the VM will be reset accordingly. So please elaborate.

[sbyx]

I don't object here and it would be the cleaner solution in the end compared to an addon, but in any case we need the kernel driver for both watchdogd or an addon ;)

[jens-maus]

Ok, this if course makes sense. However, to allow the watchdog to work in Proxmox one has to execute the following qm command:

qm set <VMID> --watchdog model=i6300esb,action=reset

So that the virtual watchdog is correctly assigned to the VM. Then after startup /dev/watchdog exists, thus /sbin/watchdog is able to init it correctly. Nevertheless, I think this PR should also introduce the systemd setup of watchdogd within home assistant os directly or in a subsequent PR the virtual watchdog systemd init should be added.

[jens-maus]

Nevertheless, I think this PR should also introduce the systemd setup of watchdogd within home assistant os directly or in a subsequent PR the virtual watchdog systemd init should be added.

Perhaps it is enough to set RuntimeWatchdogSec= option in /etc/systemd/system.conf (cf. http://0pointer.de/blog/projects/watchdog.html) ?

[sbyx]

Or maybe ha supervisor would be a good place to drive /dev/watchdog the logic is rather trivial anyway.

[jens-maus]

Or maybe ha supervisor would be a good place to drive /dev/watchdog the logic is rather trivial anyway.

Dunno, because @agners has to decide that. But IMHO a hardware watchdog like /dev/watchdog is something bare metal that you should better not mess around in userspace (e.g. supervisor) but rather use the OS integrated (e.g. well proofen) tools/daemons like the busybox /sbin/watchdog or systemd. And if this is just a matter of changing /etc/systemd/system.conf this should be quite straight forward and easy to implement.

[agners]

I agree, in general we should let Home Assistant OS or Supervisor handle a Watchdog, not an add-on.

From what I know systemd's Watchdog handling is quite versatile as it "watchdogs" systemd, which in turn can then check other processes (and an init system is the perfect agent for such a "watchdog proxy").

Setting RuntimeWatchdogSec to something other then off would probably a good starting point. The question is a bit what number do we pick here? I know that devices have different capabilities, e.g. some devices support only a very specific watchdog timeout. Also, what happens if the user has the linked add-on installed? I hope that systemd handles these two cases well. If so, I think there is not much which speaks against enabling it.

[sbyx]

Normally only one process is able to open a file handle on /dev/watchdog. Since systemd is probably there much earlier than any addon, than the addon would simply fail to start. In any case I didn't want to start a discussion about addons vs watchdogd vs systemd, but simply add kernel driver support for the watchdog device supported by qemu.

[sbyx]

On the interval it seems systemd handles this gracefully, i.e. if the interval setting is not supported it will query the driver for the (fixed) interval supported by the watchdog and use that: https://github.com/systemd/systemd/blob/main/src/shared/watchdog.c#L262

So I guess the most sensible approach would be either to find a suitable interval (I don't know 30s or so) and then enable in systemd-system.conf or just use "default" which should use the watchdog standard:

RuntimeWatchdogSec=default
WatchdogDevice=/dev/watchdog

I just tested it, if there is no watchdog device it will not print any errors unless you explicitly set systemd log-level to debug. So I guess if you are brave we could give it a try.

PS: I guess we may want to check if at least the most useful WDT drivers are enabled already in the kernel, thinking about CONFIG_ITCO_WDT on Intel, CONFIG_BCM2835_WDT for RasPi etc.

[agners]

Thanks for your investigation! I am fine with giving this a try. I think I'd go with the default setting. But in any case, this should be a separate PR.

CONFIG_BCM2835_WDT is already enabled on the Pis.

For Intel, besides CONFIG_ITCO_WDT we should also enable CONFIG_IT87_WDT which seems quite popular. Maybe others as well.