On 15/03/2021 23.41, [email protected] wrote: > Dnia 2021-03-15, o godz. 08:26:38 > Matt Spinler <[email protected]> napisał(a): > for not responding sooner. >> In my case, the code is on a BMC (OpenBMC), and the output of the >> watchdog is wired to a fan watchdog hardware circuit (involving a latch >> and a standalone fan control chip), which the watchdog app is pinging. >> So if the watchdog app dies the fans get set to full speed, however on >> the next main power cycle of the server (the BMC is on a different power >> domain) we want things back to normal, so the watchdog has to work again >> when it is restarted, which it wasn't doing without my change.
Thanks for the explanation. Can you point me at the watchdog driver code which does this "get things back to normal" on a (graceful) shutdown/stop? > I wonder what is the "architecturally correct" way of fixing this kind of > problem, since doing "stop" as a way to "start" seems counter-intuitive. Indeed. Denys, can you consider applying the up-thread patch. Whether you'll make it default n or y is up to you. Even if it's n, I think one can achieve the same thing with a wrapper #!/bin/sh ( shift $(($# - 1)) && [ -c "$1" ] && printf 'V' > "$1" ) exec busybox watchdog "$@" (or in any other number of ways, depending on how one starts the daemon). But there is no way of avoiding the annoying "nowayout" messages from the kernel if busybox is built with this open-write-close-open. Rasmus _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
