During Linux boot time, you might see a message that a watchdog timer driver is loaded, e.g.:MXC WatchDog Driver 2.0
MXC Watchdog # 0 Timer: initial timeout 60 sec
This does not actually trigger the watchdog! In order to trigger it, you have to read/write /dev/watchdog
. In order to avoid the watchdog to reset the system in the given timeout interval you have to write again to /dev/watchdog before
the timeout has elapsed.
See the example application /usr/local/DigiEL-*/apps/wd_test_c/wd_test.c
on how to do this.
In your application you can do similar like in wd_test
, but you should endlessly refresh the watchdog. The watchdog will only reset if your application doesn't get scheduled or doesn't find time to refresh it in the specified interval (e.g. it crashed or the system load was too high). The default interval of 2 secs might be a bit small, as sometimes due to high system load your application might be delayed. So its dependent on your expected system load and your type of application (and when in your application it is refreshing the timer) how you will select the timer interval. You will need to tune and test those values to make a tradeoff between detecting real bad situations and to avoid resetting the system too often during temporary high load.
A method for testing can be a fork bomb
. Trigger the watchdog timer with a very long test interval but the default watchdog interval:wd_test -n 99999 -d disable
on a second terminal (e.g. telnet/ssh session) start your fork bomb, and you will see a reset, as the wd_test application does not find time to refresh the watchdog every 2 secs.
Last updated: Jun 13, 2019