On Wed, Nov 02, 2011 at 02:53:45AM +0100, Lennart Poettering wrote: > On Mon, 24.10.11 18:04, Michael Olbrich ([email protected]) wrote: > > > This patch introduces a small watchdog daemon that supervises systemd > > and handles /dev/watchdog. This is mostly a prove of concept for now. > > Hmm, do we really want to do this externally? Maybe it would be nicer to > do this right from PID 1? I mean, it's just two ioctl()s right? i.e. a > tight loop that each time we get a TIMEOUT=1 notification message just > calls WDIOC_KEEPALIVE and WDIOC_SETTIMEOUT should be sufficient, right? > This sounds like something we could do in 10 lines in PID 1, which > otherwise would cost 200 lines outside of it. This would also allow us > to get rid of the extra properties on the Manager object, right?
As long as it's just about handling /dev/watchdog with a fixed interval, then that's fine. However, depending on the use-case there might be other requirements, e.g. whether it should be necessary or even possible to disable the watchdog. Also the watchdog hardware may be an external unit that a daemon communicates with using a higher level protocol. So how about a simple implementation inside systemd that is enabled if an interval is configured (where would I put that?) and /dev/watchdog exists. As long as we have something like patch 3, an external implementation can handle any more complex scenarios. Related to all this is something else I've been wondering about: Is it possible to block any reboot requests? e.g. during a system update, or something like that. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
