Partially, It shows that systemd is handling the watchdog as I expect it to here, but it also means that the "dysfunctional" times where the system isn't resetting properly is _not_ due to watchdog triggering, but is a "normal system" according to systemd.
Which is a worse case for me, since it's harder to debug. So, conclusion: systemd seems to handle watchdog properly systemd seems to not die properly when we expect it to, leaving us to find more debugging. I hope that makes more sense than less. On Tue, Feb 27, 2018 at 5:34 PM, Mantas Mikulėnas <[email protected]> wrote: > On Tue, Feb 27, 2018 at 6:25 PM, D.S. Ljungmark <[email protected]> wrote: >> >> >> >> On 27/02/18 15:21, Lennart Poettering wrote: >> > On Di, 27.02.18 15:12, D.S. Ljungmark ([email protected]) wrote: >> > >> >>> I figure you can send SIGSTOP to PID 1, no? (there are some signals >> >>> the kernel blocks for PID 1, but I think SIGSTOP is not among them, >> >>> please try) >> >> >> >> It seems that SIGSTOP is being filtered, because nothing appears to >> >> happen, and the system certainly isn't rebooting. >> > >> > You should be able to trigger an abort in PID 1 by sending it SIGABRT >> > or SIGQUIT or so. If PID 1 aborts it will actually enter a freeze loop >> > in which it stops pinging the hw watchdog. >> > >> > Lennart >> >> >> ABRT works, or well.. >> >> systemd[1]: Caught <ABRT>, core dump failed (child 3844, code=killed, >> status=6/ABRT). >> >> And then a broadcast, freezing execution >> >> >> And after that, what I was afraid of: >> >> [25417.186351] watchdog: watchdog0: watchdog did not stop! >> > > Isn't that exactly the result you asked for? > > -- > Mantas Mikulėnas _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
