Check a Watchdog with wdctl Without Changing Its Timer

A hardware watchdog resets a hung system on its own, which is exactly why you check it with wdctl read-only before you touch anything. This guide gives you a safe first check, a way to select just the information you need, and a clear boundary between inspection and configuration. wdctl is part of util-linux. The installed manpage is generated from util-linux 2.39.3, while the executable found first on this machine is util-linux 2.42.4 at /home/linuxbrew/.linuxbrew/bin/wdctl. The commands below use options present in both versions.

Allow about ten minutes. You need a shell and permission to read the relevant device or sysfs information. Most checks are ordinary-user commands. Do not start with sudo: a watchdog device is part of a reset mechanism, not an ordinary data file.

1. Check the command and its local version

Start with metadata that cannot touch a watchdog:

$ command -v wdctl
/home/linuxbrew/.linuxbrew/bin/wdctl
$ wdctl --version
wdctl from util-linux 2.42.4

Your path and version may differ. The version matters when you compare output with a different host. Keep the installed wdctl(8) manpage beside the command when documenting a fleet, because distributions can backport changes.

Checkpoint: if command -v wdctl finds nothing, install or enable the util-linux package through your normal system process. Do not copy a binary from another host just to make this check work.

2. Ask for the default watchdog status

With no device argument, wdctl checks /dev/watchdog:

$ wdctl
Device:        /dev/watchdog
Identity:      ...

The exact identity, timeout and flag rows are hardware-specific. A machine without a default device reports an error such as No default device is available. That is a useful result: it means this host did not expose a watchdog at the default path, not that a watchdog exists but has a healthy status.

On this machine, there is no /dev/watchdog, so the command cannot produce hardware status. Do not invent a device path. Check what the host actually exposes:

$ ls -l /dev/watchdog* 2>/dev/null
$ ls -ld /sys/class/watchdog 2>/dev/null

An absent device node may reflect hardware, kernel, driver, container or device-policy differences. These commands only inspect names and permissions. They do not enable a driver or create a device node.

3. Read a named device only after checking the risk

If your host has a watchdog with a different device path, pass that path explicitly:

$ wdctl /dev/watchdog1

Replace /dev/watchdog1 with a path that exists on your host. The command accepts one or more device arguments and separates multiple results with a blank line.

Warning: do not run this against a production watchdog merely because the path exists. The manpage describes status reporting, but opening a hardware watchdog is driver-dependent and watchdogs are designed to reset a system when they are not serviced. Confirm the device ownership and operating procedure first. If a service already owns the watchdog, leave it alone and prefer the information available through sysfs or that service's monitoring interface.

If the device is already in use, or your user cannot read it, wdctl may read sysfs instead. That fallback can omit supported-feature flags, so missing flags do not necessarily mean the hardware lacks those features.

Checkpoint: treat a permission error as an access decision, not an invitation to add broad device permissions. Ask the system owner whether a read-only observation is acceptable before trying an elevated command.

4. Limit the output without changing the watchdog

The default report includes identity, timeouts and a table of flags when the device supplies them. These read-only display options help when the full report is noisy:

For scripts, first inspect the columns supported by this executable rather than assuming a field name:

$ wdctl --help
...
Available output columns:
          FLAG  flag name
   DESCRIPTION  flag description
        STATUS  flag status
   BOOT-STATUS  flag boot status
        DEVICE  watchdog device name

Use --output with a list from that help text when you need a particular flags-table layout. If a script needs stable machine-readable data, record the util-linux version and test the exact output on every supported distribution.

5. Keep status checks separate from timeout changes

The options --settimeout, --setpretimeout and --setpregovernor change watchdog settings. They are not display options. A pre-timeout is a notification before the watchdog reset may occur; the kernel handles it and a pre-timeout governor can determine the response.

Warning: do not copy an example such as wdctl --settimeout 60 into a runbook without an approved maintenance procedure. Changing a live timeout can alter how quickly an unserviced host resets, and changing the pre-timeout can alter kernel handling. The manpage does not provide a universal safe value because supported features and useful values are hardware-specific.

If a setting has already been changed accidentally, do not guess an undo value. Check the service or platform documentation that owns the watchdog, record the current report, and restore the previously approved value during the normal change process. Stopping a watchdog service or closing a device may also have driver-specific consequences.

Common traps

Done means