Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
| docs:guide-user:hardware:watchdog [2019/07/13 19:14] – added offline example bobafetthotmail | docs:guide-user:hardware:watchdog [2021/11/01 11:39] – [USB watchdogs] vgaetera | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ======Hardware | + | ====== Hardware |
| - | + | While older versions of OpenWrt used the watchdog daemon from BusyBox, all new versions implement the watchdog daemon via procd, which is the init process (PID1). | |
| - | While older versions of OpenWrt used the watchdog daemon from busybox, all new versions implement the watchdog daemon via procd, which is the init process (PID1). Therefore on modern OpenWrt, you will never see the watchdog process running. | + | Therefore on modern OpenWrt, you will never see the watchdog process running. |
| - | + | ||
| - | ====Supported Hardware==== | + | |
| + | ===== Supported hardware ===== | ||
| Most embedded devices will have their hardware watchdog enabled in the default kernel configuration of their target, which means it will be built-in (no kmod to install, it's always available). | Most embedded devices will have their hardware watchdog enabled in the default kernel configuration of their target, which means it will be built-in (no kmod to install, it's always available). | ||
| - | For x86 hardware you have some kmods to choose, **kmod-it87-wdt kmod-sp5100_tco** which are for AMD hardware, **kmod-itco-wdt** for Intel hardware and **kmod-w83627hf-wdt** that can work for both. | + | For x86 hardware you have some kmods to choose: |
| + | | ||
| + | | ||
| + | | ||
| - | The procd watchdog code always uses the primary watchdog device / | + | There are also USB-based watchdogs, which will be discussed below in their own sub-section because they are not handled by procd in any way. |
| - | ====Controlling | + | The procd watchdog code always uses the primary watchdog device ''/ |
| + | You can configure what watchdog that is (i.e. GSC Watchdog | ||
| + | ===== Controlling the watchdog ===== | ||
| You can see the current configuration of the watchdog service via ubus: | You can see the current configuration of the watchdog service via ubus: | ||
| - | If there is a watchdog available: | + | < |
| - | < | + | # ubus call system watchdog |
| - | root@OpenWrt:/ | + | |
| { | { | ||
| " | " | ||
| " | " | ||
| " | " | ||
| - | }</ | + | } |
| + | </ | ||
| - | If no watchdog is available: | + | If no watchdog is available, the status |
| - | < | + | |
| - | root@OpenWrt:/# | + | |
| - | { | + | |
| - | "status": "offline", | + | |
| - | " | + | |
| - | " | + | |
| - | }</ | + | |
| + | While there is no UCI configuration available for these options, you can change them in an rc script such as ''/ | ||
| - | While there is no uci configuration available for these options you could change them in an rc script such as rc.local if you wish: | + | <code bash> |
| + | # Change timeout to 60s | ||
| + | ubus call system watchdog ' | ||
| - | change | + | # Change frequency |
| - | < | + | ubus call system watchdog ' |
| - | ubus call system watchdog '{ "timeout": | + | |
| </ | </ | ||
| - | change to 1s frequency | + | To bypass procd, enable the magicclose feature, stop the service and control the watchdog manually: |
| - | < | + | |
| - | ubus call system watchdog '{ "frequency": | + | < |
| - | </ | + | ubus call system watchdog ' |
| - | To stop the service: | + | ubus call system watchdog ' |
| - | < | + | while :; do echo 1 > /dev/watchdog; sleep 5; done |
| - | ubus call system watchdog '{ " | + | |
| </ | </ | ||
| + | Note that watchdog will cause a reset after it expires. | ||
| - | ====Manually control hardware watchdog==== | + | ===== USB watchdogs |
| + | USB-based watchdogs are basically a microcontroller over a USB-serial dongle, that will close/open contacts when they trigger. | ||
| + | These contacts are usually on a header that can be connected to the Power and Reset switch of the board, or to a relay wired to interrupt the power supply to the device. | ||
| - | If you just stop procd from tickling | + | These are some photos of the device I am using: |
| - | < | + | {{:docs: |
| - | root@OpenWrt:~# ubus call system watchdog '{" | + | {{: |
| - | { | + | |
| - | "status": "stopped", | + | This kind of task is trivially easy to also do with an Arduino or Attiny board and some relays. |
| - | "timeout": 30, | + | |
| - | " | + | Some USB-based watchdogs are not using a serial dongle, but show up as USB HID devices and I don't know what is their protocol. |
| - | " | + | |
| - | } | + | This is a script that will generate a procd service to control one of such USB-serial watchdogs. |
| - | root@OpenWrt:~# echo 1 > / | + | |
| - | -ash: can't create | + | <code bash> |
| - | </ | + | cat << |
| - | But if you enable magicclose feature | + | #!/bin/sh |
| - | < | + | |
| - | root@OpenWrt: | + | # Watchdog control script for USB-serial based watchdogs |
| - | { | + | |
| - | "status": "running", | + | # The command to run the watchdog 160 seconds is: |
| - | | + | # echo -n -e "\x10" |
| - | "frequency": 5, | + | # The "x10" |
| - | "magicclose": | + | # just write a different hexadecimal number, and adjust the number of seconds in the sleep command below. |
| + | # DO NOT use a too small time though or the system will not have enough time to fully reboot before the watchdog triggers again. | ||
| + | |||
| + | # First we are detecting what usb serial we need to use, to avoid sending commands to the wrong device, like LTE modems. | ||
| + | # The device I used appears like this in dmesg when I connect it: | ||
| + | # [11705.304457] usb 4-1: new full-speed USB device number 2 using uhci_hcd | ||
| + | # [11705.538687] ch341 4-1:1.0: ch341-uart converter detected | ||
| + | # [11705.549626] usb 4-1: ch341-uart converter now attached to ttyUSB0 | ||
| + | # So I filter for ch341 serial chips. | ||
| + | |||
| + | usb_serial=" | ||
| + | cmd=" | ||
| + | |||
| + | if [ -z " | ||
| + | then | ||
| + | echo "no ch341 serial dongle detected, no watchdog | ||
| + | exit 1 | ||
| + | fi | ||
| + | |||
| + | case "${cmd}" in | ||
| + | |||
| + | (start) | ||
| + | echo "starting usb watchdog service" | ||
| + | |||
| + | while [ ! -f / | ||
| + | do | ||
| + | echo -n -e "\x10" | ||
| + | sleep 30 | ||
| + | done | ||
| + | rm / | ||
| + | |||
| + | echo "stopping usb watchdog service" | ||
| + | ;; | ||
| + | |||
| + | (stop) | ||
| + | touch / | ||
| + | ;; | ||
| + | |||
| + | (install) | ||
| + | cat << | ||
| + | #!/bin/sh / | ||
| + | |||
| + | USE_PROCD=1 | ||
| + | START=95 | ||
| + | STOP=01 | ||
| + | |||
| + | start_service() { | ||
| + | procd_open_instance | ||
| + | procd_set_param command /bin/sh / | ||
| + | # If process dies sooner than respawn_threshold, | ||
| + | procd_set_param respawn ${respawn_threshold:-3600} ${respawn_timeout: | ||
| + | procd_close_instance | ||
| } | } | ||
| - | root@OpenWrt: | + | stop_service() |
| - | { | + | / |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| } | } | ||
| - | root@OpenWrt:~# echo 1 > /dev/ | + | EOI |
| - | root@OpenWrt:~# | + | |
| - | </ | + | cat << " |
| + | / | ||
| + | / | ||
| + | / | ||
| + | EOI | ||
| + | |||
| + | chmod +x / | ||
| + | / | ||
| + | / | ||
| + | ;; | ||
| + | |||
| + | (remove) | ||
| + | / | ||
| + | / | ||
| + | rm -f / | ||
| + | rm -f / | ||
| + | rm -f / | ||
| + | ;; | ||
| + | |||
| + | esac | ||
| + | EOF | ||
| + | chmod +x / | ||
| + | / | ||
| + | </ | ||
| + | |||
| + | To install it, write the following commands in your device' | ||
| + | |||
| + | <code bash> | ||
| + | uclient-fetch -O usb-watchdog.sh " | ||
| + | . ./ | ||
| + | </ | ||
| + | |||
| + | You can then control it as normal for a procd service: | ||
| + | |||
| + | <code bash> | ||
| + | / | ||
| + | </ | ||
| + | |||
| + | This script also writes the system configuration to survive a system upgrade, so you shouldn' | ||