The user may asks for procd watchdog handler to be stopped with or without disabling it, by specifying the magicclose flag.
If the flag is set, the watchdog will be disabled and the fd closed, allowing the user to take control over the watchdog.
If the flag is not set, the watchdog will not be disabled and the fd will not be closed.
Use-case
I would like to take over the watchdog and handle it with a script.
Problem
Stopping the handler with magicclose == true is not reliable. If the system fails before the user re-enables the watchdog, the system might hang without a proper reset.
Stopping the handler with magicclose == false doesn't help either. The procd will only stop refreshing the watchdog, but will leave the fd open. At least on Raspberry Pi, this prevents anyone else from opening the watchdog device, resulting in EBUSY.
The fix
With this patch, watchdog fd will always be closed, regardless of the magicclose flag, allowing for the described use-case. To take over the watchdog, stop it with magicclose == false and open the watchdog device in your custom way.
Peculiarity
You will note an allegedly critical log line coming from kernel "watchdog did not stop!" This is actually what we want. In my opinion, it should only be a warning, not a critical message.
Backward compatibility
For user that previously stopped the watchdog handler with magicclose == true, the functionality remains unchanged.
aparcar
commented
1 year ago
Current behavior
The user may asks for procd watchdog handler to be stopped with or without disabling it, by specifying the magicclose flag.
Use-case
I would like to take over the watchdog and handle it with a script.
Problem
Stopping the handler with magicclose == true is not reliable. If the system fails before the user re-enables the watchdog, the system might hang without a proper reset.
Stopping the handler with magicclose == false doesn't help either. The procd will only stop refreshing the watchdog, but will leave the fd open. At least on Raspberry Pi, this prevents anyone else from opening the watchdog device, resulting in EBUSY.
The fix
With this patch, watchdog fd will always be closed, regardless of the magicclose flag, allowing for the described use-case. To take over the watchdog, stop it with magicclose == false and open the watchdog device in your custom way.
Peculiarity
You will note an allegedly critical log line coming from kernel "watchdog did not stop!" This is actually what we want. In my opinion, it should only be a warning, not a critical message.
Backward compatibility
For user that previously stopped the watchdog handler with magicclose == true, the functionality remains unchanged.