Who is silently kicking the watchdog timer in Linux?

Question

I am using the 4.9 Linux kernel on an embedded platform and noticing that the watchdog timer is getting refreshed automatically even though I have no user-space daemon running like the watchdog documentation mentions.

Answer 1

Taken almost verbatim from shodanex's answer to a related question.

If you enabled the watchdog driver in your kernel, the watchdog driver sets up a kernel timer in charge of resetting the watchdog.

If no application opens the /dev/watchdog file, then the kernel takes care of resetting the watchdog. Since it is a timer, it won't appear as a dedicated kernel thread, but handled by the soft IRQ thread. Now, if an application opens this file, it becomes responsible of the watchdog, and can reset it by writing to the file, as documented the watchdog documentation.

In July 2016 a commit in the 4.7 kernel to watchdog_dev.c enabled this behavior for all watchdog timer drivers. Before this time, it appears to be spotty and driver specific. The behavior doesn't seem to be documented anywhere other than this thread and the source code.

/*
* A worker to generate heartbeat requests is needed if all of the
* following conditions are true.
* - Userspace activated the watchdog.
* - The driver provided a value for the maximum hardware timeout, and
*   thus is aware that the framework supports generating heartbeat
*   requests.
* - Userspace requests a longer timeout than the hardware can handle.
*
* Alternatively, if userspace has not opened the watchdog
* device, we take care of feeding the watchdog if it is
* running.
*/

return (hm && watchdog_active(wdd) && t > hm) ||
       (t && !watchdog_active(wdd) && watchdog_hw_running(wdd));