In a service file, I set WatchdogSec to start at 2 seconds:

% systemctl --user cat psi-notify | grep WatchdogSec
WatchdogSec=2s

I then start the service and WatchdogUSec is set correctly:

% systemctl --user show psi-notify -p WatchdogUSec
WatchdogUSec=2s

Now I call sd_notify(0, "WATCHDOG_USEC=5000000"). The new timer seems to have taken effect, since I only send WATCHDOG=1 every 4 seconds, and systemd isn't triggering the watchdog handler, but still WatchdogUSec is 2s:

% systemctl --user show psi-notify -p WatchdogUSec
WatchdogUSec=2s

This surprised me a little, since I guess I considered the new WatchdogUSec to be a runtime-updated property. There are no other watchdog properties exposed.

Reading the code, we call service_override_watchdog_timeout, which instead sets watchdog_override_enable and watchdog_override_usec, but these aren't exposed by systemctl show over DBus.

This feels like it should be exposed somehow, either by changing WatchdogUSec exposed by systemctl show, or adding a new WatchdogOverrideUSec or similar.

In total we really have 3 different watchdog timeouts:

• watchdog_usec, from the unit definition
• watchdog_original_usec, usually a copy of this (seems not super valuable to expose)
• watchdog_override_usec, from sd_notify(WATCHDOG_USEC)

@poettering, any thoughts on how best to expose this? I don't want to make this too ugly, but it does feel like we're missing something right now.