[systemd-devel] [PATCH 0/3] make the service property StartLimitAction writeable

[Lennart Poettering]

On Fri, 06.04.12 21:37, Michael Olbrich (m.olbrich at pengutronix.de) wrote:

Heya,
> I sent this before, but I didn't get any comments. This is the same series
> rebased onto the current master.
> This patch series make the service property StartLimitAction writeable. The
> first two patches are preparation to make it posible. The third patch
> actually implements this.
> Why this is useful: Consider a service with rather strict watchdog
> settings. StartLimitAction=reboot-force and low StartLimitBurst. If the
> service for some reason crashes immediately, then the system might reboot
> before a user can interfere.
> With StartLimitAction writeable a 'supervisor' service can start before
> this service and (based on some use-case dependent data) set
> StartLimitAction to 'none'. The user can then resolve the issue.

Thanks a lot. All three patches merged! Sorry for the delay.

Hmm, so, from your original watchdog work, what is still missing in git?
You had some code that "multiplexed" the hw watchdog for individual
services, but I couldn't wrap my head around it. Was there anything else
left? (Or anything still on your wishlist?)

The multiplexing I am still not convinced off, btw. With all the code
now in place we can soft-reboot the machine when a specific service
doesn't react, and hard-reboot the machine when systemd doesn't
react. With the multiplexing in place we'd simply forward the service
watchdog events to the hw watchdog, but what precisely would we gain
from that? I mean, we already can reboot the machine directly anyway if
a service doesn't respond, why add the (potentially fragile) indirection
to do the same via the hw watchdog timer? Or in other words, why would
somebody choose to make use of this hw watchdog indirection rather than
just tell systemd "StartLimitAction=reboot-immediate"? Can you explain?
What am I missing?

(as a side note: i submitted a little tool to util-linux which queries
/dev/watchdog for its state and is useful to figure out what watchdog is
available and what its capabilities are. I hope this is merged
soon. This should be useful for everybody experimenting with hardware
watchdogs...)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.