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
On Tue, Feb 27, 2018 at 6:25 PM, D.S. Ljungmark wrote:
>
>
> On 27/02/18 15:21, Lennart Poettering wrote:
> > On Di, 27.02.18 15:12, D.S. Ljungmark (ljungm...@modio.se) wrote:
> >
> >>> I figure you can send SIGSTOP to PID 1, no? (there are some signals
> >>> the kernel
On 27/02/18 15:21, Lennart Poettering wrote:
> On Di, 27.02.18 15:12, D.S. Ljungmark (ljungm...@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
On Di, 27.02.18 15:12, D.S. Ljungmark (ljungm...@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
( re-send as I forgot the list )
On 27/02/18 13:20, Lennart Poettering wrote:> On Di, 27.02.18 12:44,
D.S. Ljungmark (ljungm...@modio.se) wrote:
>
>> Hi list!
>>
>> We're using systemd to control the hardware watchdog, and would want to
>> induce fail state to _verify_ that the shutdown/reboot
On Di, 27.02.18 12:44, D.S. Ljungmark (ljungm...@modio.se) wrote:
> Hi list!
>
> We're using systemd to control the hardware watchdog, and would want to
> induce fail state to _verify_ that the shutdown/reboot process works as
> expected.
>
> How do we make systemd "fail" to ping the watchdog?
Hi list!
We're using systemd to control the hardware watchdog, and would want to
induce fail state to _verify_ that the shutdown/reboot process works as
expected.
How do we make systemd "fail" to ping the watchdog?
How do we control which states ( root fs not available, etc) cause
systemd to