5

I have tried to run the WatchDog Daemon using the tutorial found at http://binerry.de/post/28263824530/raspberry-pi-watchdog-timer

So basic process I ran through to get WatchDog up and running is:

1. sudo modprobe bcm2708_wdog
2. sudo nano /etc/modules (add line “bcm2708_wdog”)
3. apt-get install watchdog chkconfig
4. chkconfig watchdog on
5. /etc/init.d/watchdog start
6. nano /etc/watchdog.conf (enable line “watchdog-device = /dev/watchdog”)

When I reboot I see that the WatchDog daemon starts in one of the last system startup tasks, however when I try a fork bomb, System becomes unusable but never resets.

Fork bomb code use below:(Warning to others reading, below code can cause damage. Read linked tutorial on top for more info)

#!/bin/bash
:(){ :|:& };:
  • I recommend also check networking : /etc/watchdog.conf ping = <routerip> interface = eth0 interval = 20 realtime = yes priority = 1 watchdog-device = /dev/watchdog – Boris Ivanov Aug 20 '15 at 19:31
3

a) for a effective forkbomb you need to disable the swap partition. (swapoff -a) b) the system may survive a single forkbomb. Simply start a number of them.

A very simply test can be done by killing the watchdog process. By doing so the watchdog process doesn't ping the watchdog device, so the hardware watchdog will reboot the pi. In a realworld situation the watchdog daemon my not be able to ping anything because of high load on the system. The result would be the hardware reboot.

  • I turned off swap, and let process run for a while but still the unit did not restart. would multiple fork bombs be more effective than just the one? I would think you would acheive the same result with just one(I really don't know, just from my limited knowledge on how forks work). – Richard Nov 26 '12 at 18:25
3

I have a theory of why system is not rebooting, but not yet tested.

in /etc/watchdog.conf there are lines:

realtime = yes
priority = 1

basically what I am thinking is that the forkbomb runs but at a lower priority than 1. WatchDog Daemon is still able to get the pulses to the hardware WatchDog. System is still running pretty inoperable, but because WatchDog Daemon has such a high priority, it is happy.

in the same config file there is a line:

max-load-1     =24

I uncommented this line and now the WatchDog Daemon works as expected.

The only problem here is that it is possible to reboot machine when it is not truly hung. In my case, I am not running lxde and only running a few python cron jobs that are not resource hungry so it shouldn't be a issue for me.

3

I spent a bit of time getting the watchdog working on a Debian Stretch version of Raspbian:

pi@orangepi:~ $ cat /etc/rpi-issue
Raspberry Pi reference 2018-11-13
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 7e0c786c641ba15990b5662f092c106beed40c9f, stage2
pi@orangepi:~ $ uname -a
Linux orangepi 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux

Turns out it's pretty easy and it doesn't even require the additional watchdog package. Instead, it uses the Systemd watchdog facilities.

Edit the file /etc/systemd/system.conf and set the following options:

RuntimeWatchdogSec=10
ShutdownWatchdogSec=10min

Save the file, reboot, and try the fork bomb:

pi@orangepi:~ $ cat > /tmp/test.sh
#!/bin/bash
:(){ :|:& };:

# hit ctrl+d here
pi@orangepi:~ $ sudo bash /tmp/test.sh

After about 30 seconds the shell exits, and upon logging in again, the uptime is reset:

pi@orangepi:~ $ uptime
 05:43:16 up 1 min,  1 user,  load average: 0.38, 0.12, 0.04
1

I had the same experience when running the fork-bomb - the system become unstable - and kicked me off my ssh session - but the pi didn't reboot.

I got it to work (at least once) however - by running the fork-bomb as root.

   $ sudo su -
   # swapoff -a
   # :(){ :|:& };:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.