systemctl-service-watchdogs
Monitor service watchdog events
TLDR
Show whether service watchdogs are currently enabled
Enable service runtime watchdogs
Disable service runtime watchdogs
SYNOPSIS
The concept of "systemctl-service-watchdogs" is implemented through unit file configuration and observed via the systemctl command, rather than being a direct command itself. To understand and manage services utilizing watchdogs, you would typically use commands like:
systemctl status <service-name>
(To observe the current state and any watchdog-related restarts)
systemctl show <service-name> --property=WatchdogSec
(To retrieve the configured watchdog timeout for a service)
Configuration of watchdogs happens within a service unit file (e.g., /etc/systemd/system/my-service.service):
[Service]
WatchdogSec=<seconds>
Restart=on-watchdog
PARAMETERS
WatchdogSec=<interval>
(Unit file option) Specifies the watchdog timeout period. If the service fails to send a keep-alive signal within this time, systemd considers it failed. The interval can be a number of seconds or a time unit like '10s' or '5min'.
Restart=on-watchdog
(Unit file option) Configures the service to be restarted automatically by systemd if a watchdog timeout occurs. Other restart options exist (e.g., 'always', 'on-failure').
--property=<property>
(systemctl show option) Used with systemctl show to display specific properties of a unit, such as `WatchdogSec` or `RuntimeWatchdogUSec`.
sd_notify(3)
(Service internal mechanism) A function call services use to notify systemd about their status, including sending watchdog keep-alive signals (e.g., `WATCHDOG=1`). While not a command-line parameter, it's crucial for watchdog functionality.
DESCRIPTION
The term "systemctl-service-watchdogs" refers to the functionality within systemd for monitoring the responsiveness of services using watchdog timers, and how the systemctl utility interacts with these features. It is not a standalone command. A systemd watchdog is a mechanism to ensure a service remains operational and responsive. If a service configured with a watchdog fails to send periodic "keep-alive" signals to systemd within a specified `WatchdogSec` interval, systemd will deem the service non-responsive and, depending on configuration, restart it.
This enhances system reliability by preventing services from silently hanging. systemctl is the primary interface for administrators to inspect the status of such services, view their watchdog configuration, and understand why a service might have been restarted due to a watchdog timeout.
CAVEATS
The term "systemctl-service-watchdogs" is descriptive of a systemd feature and its interaction via systemctl, not a direct executable command.
Proper configuration of `WatchdogSec` is critical; too short an interval can lead to spurious restarts, while too long an interval can delay detection of a hung service. The service itself must be programmed to periodically send watchdog notifications via sd_notify() for this feature to work correctly. Without the service actively pinging systemd, `WatchdogSec` alone is insufficient to prevent timeouts.
CONFIGURING SERVICE WATCHDOGS
To enable a watchdog for a service, you need to edit or create its systemd unit file (e.g., /etc/systemd/system/my-app.service). Within the `[Service]` section, add `WatchdogSec=` and `Restart=on-watchdog`. For example:
[Unit]
Description=My Responsive Application
[Service]
ExecStart=/usr/local/bin/my-app
WatchdogSec=30s
Restart=on-watchdog
After modifying the unit file, run `sudo systemctl daemon-reload` and then `sudo systemctl restart my-app.service` for the changes to take effect.
SERVICE WATCHDOG INTERACTION (INTERNAL)
For a watchdog-enabled service to function correctly, the application running within that service must periodically send a 'keep-alive' signal to systemd. This is typically done by calling the sd_notify() function (from libsystemd) with the `WATCHDOG=1` message. The application should perform this call at intervals less than half of the configured `WatchdogSec` to ensure responsiveness and avoid accidental timeouts. For example, if `WatchdogSec=30s`, the service should notify systemd at least every 15 seconds.
HISTORY
Watchdog timers have long been a feature in hardware and operating systems to prevent total system hangs. With the advent of systemd as the primary init system in many Linux distributions (starting around 2010-2012), robust service management became a core focus. The software watchdog functionality for individual services was integrated into systemd to provide a higher level of application reliability, allowing the init system to automatically recover unresponsive services without requiring a full system reboot.
SEE ALSO
systemctl(1), systemd(1), systemd.service(5), systemd-notify(1)


