Difference between /dev/watchdog and /dev/watchdog[0-9]

watchdog

On my (embedded) system I have multiple watchdog character devices:

# ls -al /dev/watchdog*
crw------- 1 imp  root  10, 130 Apr 26 07:43 /dev/watchdog
crw------- 1 root root 253,   0 Apr 26 07:44 /dev/watchdog0
crw------- 1 root root 253,   1 Apr 26 07:44 /dev/watchdog1

# dmesg | grep -i watchdog
[    2.342104] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    6.713125] softdog: Software Watchdog Timer: 0.08 initialized. soft_noboot=0 soft_margin=120 sec soft_panic=0 (nowayout=1)

I'm pretty sure that /dev/watchdog0 is the hardware watchdog and /dev/watchdog1 is the software watchdog, but why is there also a /dev/watchdog ?

Background: The software watchdog is configured with nowayout flag, so, once it has been feeded it won't stop anymore until reboot. However, writing to /dev/watchdog doesn't seem to trigger the software watchdog and doesn't give me the important nowayout feature. I could use /dev/watchdog1 directly, but then I'd need some reliable way to identify the correct software watchdog device filename…

Best Answer

I had the same question. According to the kernel documentation:

id: [...] id 0 is special. It has both a /dev/watchdog0 cdev (dynamic major, minor 0) as well as the old /dev/watchdog miscdev. The id is set automatically when calling watchdog_register_device.

In other words, /dev/watchdog and /dev/watchdog0 both point to the same device. Any additional watchdogs will be numbered greater than 0 and will have only a single device node.

Related Solutions

Linux watchdog and systemd watchdog

Systemd's watchdog can be mainly used for 3 different actions:

hardware reset (leveraging the CPU hardware watchdog exposed at /dev/watchdog). This is enabled by the RuntimeWatchdogSec= option in /etc/systemd/system.conf
application reset, as long as this is foreseen in the systemd unit definition
system reset as a fallback measure in response to multiple unsuccessful application resets. Also defined in the systemd unit

example unit file:

[Unit]
Description=My Little Daemon
Documentation=man:mylittled(8)

[Service]
ExecStart=/usr/bin/mylittled
WatchdogSec=30s
Restart=on-failure
StartLimitInterval=5min
StartLimitBurst=4
StartLimitAction=reboot-force

The example is taken from: http://0pointer.de/blog/projects/watchdog.html, which gives a pretty complete overview of what and how you can use the watchdog service.

Fedora – Do I own a watchdog

Most modern PC hardware includes watchdog timer facilities. You can read more about them here via wikipedia: Watchdog Timers. Also from the Linux kernel docs:

excerpt - https://www.kernel.org/doc/Documentation/watchdog/watchdog-api.txt

A Watchdog Timer (WDT) is a hardware circuit that can reset the computer system in case of a software fault. You probably knew that already.

Usually a userspace daemon will notify the kernel watchdog driver via the /dev/watchdog special device file that userspace is still alive, at regular intervals. When such a notification occurs, the driver will usually tell the hardware watchdog that everything is in order, and that the watchdog should wait for yet another little while to reset the system. If userspace fails (RAM error, kernel bug, whatever), the notifications cease to occur, and the hardware watchdog will reset the system (causing a reboot) after the timeout occurs.

The Linux watchdog API is a rather ad-hoc construction and different drivers implement different, and sometimes incompatible, parts of it. This file is an attempt to document the existing usage and allow future driver writers to use it as a reference.

This SO Q&A titled, Who is refreshing hardware watchdog in Linux?, covers the linkage between the Linux kernel and the hardware watchdog timer.

What about the watchdog package?

The description in the RPM makes this pretty clear, IMO. The watchdog daemon can either act as a software watchdog or can interact with the hardware implementation.

excerpt from RPM description

The watchdog program can be used as a powerful software watchdog daemon or may be alternately used with a hardware watchdog device such as the IPMI hardware watchdog driver interface to a resident Baseboard Management Controller (BMC). watchdog periodically writes to /dev/watchdog; the interval between writes to /dev/watchdog is configurable through settings in the watchdog sysconfig file.

This configuration file is also used to set the watchdog to be used as a hardware watchdog instead of its default software watchdog operation. In either case, if the device is open but not written to within the configured time period, the watchdog timer expiration will trigger a machine reboot. When operating as a software watchdog, the ability to reboot will depend on the state of the machine and interrupts.

When operating as a hardware watchdog, the machine will experience a hard reset (or whatever action was configured to be taken upon watchdog timer expiration) initiated by the BMC.

Best Answer

Related Solutions

Linux watchdog and systemd watchdog

Fedora – Do I own a watchdog

What about the watchdog package?

Related Question