Always run as real-time process when supervisor is enabled (Was: Add support for "dummy" WDT subscriber process)

[troglobit]

Some systems don't have (the possibility to) instrument(ed) client processes with the API provided by watchdogd, yet they still may want to collect system information before the system goes down (due to overload or similar).

This should be relatively easy to implement using a configurable dummy process that subscribes.

[wkz]

Great idea! 😉

Some thoughts:

Is there a reason for it to be configurable? Couldn't watchdogd always run in "supervisor"-mode, typically in something like SCHED_FIFO/99? As part of its initialization it would fork off the dummy to monitor user-space, typically in SCHED_OTHER.

In this model, you always use the "controlled shutdown" mode. I.e. you always collect system information before rebooting.

[troglobit]

Sure, but it would break semantics compared to previous releases and some users (except for us ;) may wonder why they suddenly have a SCHED_FIFO process running after upgrading.

But you're right, the watchdog daemon on the system should behave more like "do what I mean" ...

[troglobit]

Nah, you're right @wkz. We already have the supervisor { enabled = false } setting, so adding another just for this does not make sense.

I'm going ahead and changing the default behavior when supervisor is enabled. I.e., if supervisor is enabled in the .conf file we always run at elevated priority, regardless if a process has subscribed yet or not.

[troglobit]

There, fixed. I've tested it on one of our devices already and chrt -p PID reveals watchdogd indeed does follow the supervisor: enabled setting to use rtprio or not.