[systemd-devel] Triggering the HW Watchdog

[D.S. Ljungmark]

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 <grawity at gmail.com> wrote:
> On Tue, Feb 27, 2018 at 6:25 PM, D.S. Ljungmark <ljungmark at modio.se> wrote:
>>
>>
>>
>> On 27/02/18 15:21, Lennart Poettering wrote:
>> > On Di, 27.02.18 15:12, D.S. Ljungmark (ljungmark at modio.se) 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