6

Is there a command like

vi > out
vi | out

That I could use to cause a watchdog reset of my embedded linux device?

Pro Backup
  • 4,924

4 Answers4

15

If you have a watchdog on your system and a driver that uses /dev/watchdog, all you have to do is kill the process that is feeding it; if there is no such process, then you can touch /dev/watchdog once to turn it on, and if you don't touch it again, it will reset.

You also might be interested in resetting the device using the "magic sysrq" way. If you have a kernel with the CONFIG_MAGIC_SYSRQ feature compiled in, then you can echo 1 > /proc/sys/kernel/sysrq to enable it, then echo b > /proc/sysrq-trigger to reboot. When you do this, it reboots immediately, without unmounting or or syncing filesystems.

Shawn J. Goff
  • 46,081
  • 4
    Simply killing the watchdog daemon might not be good enough. Depending on how the watchdog device is configured it might disable the watchdog if /dev/watchdog is closed. In that case you can try sending SIGSTOP to your watchdog process instead. – Kristof Provost Feb 07 '13 at 15:22
  • If killing the watchdog daemon you must use SIGKILL and not the usual SIGTERM which performs an orderly shut-down and so closes the driver. Using SIGSTOP as suggested by @KristofProvost achieves the same goal of preventing the periodic refresh. – Paul Crawford Oct 02 '16 at 09:54
  • SIGSTOP will be better than SIGKILL when the driver stops the watchdog when the file descriptor gets closed. See the kernel documentation, especially regarding "Magic Close" and CONFIG_WATCHDOG_NOWAYOUT. – Vladimir Panteleev Sep 18 '22 at 09:52
9

If you think the watchdog is running OK, and want to test that it really is capable of recovering a crashed system, then you can do one better than Shawn's answer by using the "magic sysrq" to crash the system with a kernel panic. Syncing your file system first is a good idea, so do something like this as root:

sync; sleep 2; sync; echo c > /proc/sysrq-trigger

That should cause a kernel panic if the sysrq is enabled. Then if you wait around 60 seconds (typical time-out for the watchdog module) you should see the machine reboot. Please note this will only work with hardware watchdogs and not the 'softdog' module.

slm
  • 369,824
  • I don't think this is a good way to test the watchdog. The kernel will itself reboot after 60 seconds, without any help from any watchdog, with a kernel crash like this: https://github.com/torvalds/linux/blob/a335366bad1364a07f49df9da1fdfa6d411a5f39/kernel/panic.c#L358-L367 – Vladimir Panteleev Sep 18 '22 at 08:15
1

Killing the watchdog process is one way, but note that this is not foolproof: the behavior depends on the specific watchdog driver, see the kernel documentation, especially regarding "Magic Close" and CONFIG_WATCHDOG_NOWAYOUT. The sysrq answers may also give you a false positive depending on the kernel configuration (CONFIG_PANIC_TIMEOUT).

I think the most straight-forward approach is to write your own, simple and intentionally-broken watchdog. The following program (based on the sample included with the kernel) worked for me:

// SPDX-License-Identifier: GPL-2.0
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>

#include <sys/ioctl.h> #include <linux/watchdog.h>

int main(void) { int fd = open("/dev/watchdog", O_RDWR); if (fd == -1) { perror("watchdog"); exit(EXIT_FAILURE); } int timeout; ioctl(fd, WDIOC_GETTIMEOUT, &timeout); printf("The timeout was %d seconds\n", timeout); timeout = 1; ioctl(fd, WDIOC_SETTIMEOUT, &timeout); printf("The timeout is now %d seconds. The system should reset soon...\n", timeout); while (1) { printf("Still here...\n"); sleep(1); } }

Run it like e.g. gcc prog.c && sudo sync && sudo ./a.out.

0

Just putting it in one line from previous two posts:

echo 1 | sudo tee -a /proc/sys/kernel/sysrq; sync; sleep 2; sync; echo c | sudo tee -a /proc/sysrq-trigger
kaptan
  • 305