Dear Maintainer,
After crashing the kernel with "echo c > /proc/sysrq-trigger" the
watchdoggery sometimes failes to trigger a reboot. It's as if the
watchdog daemon continues to successfully perform its checks and
thus continues to service the hardware watchdog even if the
kernel has paniced.
The watchdog configuration is trivial:
watchdog-device = /dev/watchdog
interval = 10
realtime = yes
priority = 1
pidfile = /run/foo.pid
pidfile = /run/bar.pid
When reading the manual I noticed this passage:
"watchdog will try periodically to fork itself to
see whether the process table is full."
Since I was a bit sceptic that a paniced kernel could
successfully fork, I wondered a bit about what "periodically"
meant. So I went digging to see exactly how often that fork
test is performed and how long a should expect to wait for it,
but it appears it is no longer done at all.
To verify, I added an empty script that simply returns 0 to
/etc/watchdog.d and after that, the watchdog kicks in as expected.
That's arguably heavier than a fork-exit-test, but still an
indication.
I then went digging in the git history to check if it might be
intentional, but it appears not. The way I read it, the check
went missing along with 12-year-old commit
0fc6d009c78f ("This patch allows zero or more scripts/programs...")
which was new for version 5.10.
Notice how the "if (tbinary == NULL)" test is moved to before the
fork() call in the check_bin() function in that patch. But maybe
I misread something?
Anyway, please repair the broken fork test (or adjust the manual
to the new reality.)
Cheers,
Peter