Watchdog—The Linux Software Daemon
Starting with version 1.3.51 the Linux kernel provides a watchdog driver. Not only does it take care of hardware watchdogs, but it also implements a software watchdog. It was created by Alan Cox, alan@lxorguk.ukuu.org.uk, and modularized by Angelo Haritsis, ah@doc.ic.ac.uk.
The Linux software watchdog is a timer that continuously counts down from a specified start value. Once it reaches zero a function named “watchdog_fire” is called that logs the event and initiates a hard reset. A watchdog daemon is therefore needed to refresh the timer. As long as the daemon is present the timer will never fire, but if the daemon stops working for some reason, the timer will fire and reboot the machine. However, with no additional hardware, the watchdog is not able to recover from every possible hang up. For instance, if the interrupt system itself hangs up, the software watchdog is no cure at all.
At start-up, the daemon opens the watchdog device (a character device with major number 10 and minor number 130) starting the watchdog process—an infinite loop in which the daemon alternately writes to the watchdog device to refresh the timer, then sleeps for 10 seconds. If the daemon is killed, the device file is closed, and the timer is disabled again.
Initially, I compiled the example given by Alan Cox in the source tree to be able to start, refresh and stop the software watchdog daemon. Since I always run the latest kernel and libc release and rely on the machine to be up and running for e-mail, even this simple version proved very useful for me.
As time went by, more features were added. First, WATCHDOG became a real daemon in that it automatically forks as a background process, tucking its process ID away. Then, since WATCHDOG is performing a critical job, logging to the standard syslog facility was implemented, as well as some user-friendly options:
Logging is done in verbose mode each time the process awakes.
The sleep interval can be set from the command line.
The file system is synchronized every time the process updates the timer.
The watchdog device name can be chosen on the command line.
This rudimentary version was then released as a Debian package to give more people the chance to use, and thereby, test it. The next step was to implement some enhancements, namely the ability to test the accessibility of a user-named file every time the process is awake. This ability allows WATCHDOG to catch problems with machines mounting most or all of their directory tree via NFS or similar means of remote file systems—this connection can hang despite the local machine functioning correctly. Since this hangup can cause huge problems, the WATCHDOG daemon tries to access one file on this mount every time it awakes. If the connection is down, it will not be able to refresh the timer, and the system will be rebooted. WATCHDOG can be instructed to initiate a soft-boot instead of the normal hard reset when any call returns an error message.
At this point in the development of WATCHDOG, I released the daemon as version 1.0 to all Debian archives and to tsx-11.mit.edu.
With more people using WATCHDOG some problems have been encountered and fixed, and I began working on the one problem that still worried me. From time to time the process table got so full that no more processes could be started, so I changed WATCHDOG to check the process table every time it is awake. If the table is full, the system is rebooted. Doing a hard reset in this case seemed a bad idea, so instead, WATCHDOG initiates a complete shutdown. This action also posed a problem, since the process table might stay full despite WATCHDOG's attempt to kill all processes. For example, it is not possible to start the shutdown binary when the process table is not empty. To take care of this situation WATCHDOG contains code for the complete shutdown process, including the following actions:
idles init, so nothing new can be started,
kills all processes,
writes a reboot record to wtmp,
turns off accounting,
turns off quota,
turns off swap,
unmounts all mounted partitions,
calls reboot.
With this feature working correctly, version 2.0 was released on July 30, 1996 to tsx-11.mit.edu and every Debian mirror.
Of course, there are more ideas that need implementation. If anyone is in need of a check different from those described in this article, please write me at meskes@debian.org.
Michael Meskes made first contact with Linux while working on his doctoral thesis. He has been involved in testing and bug fixing the kernel and the C library since 1994. Since 1995 he has maintained several packages for Debian GNU/Linux. He likes professional football, in particular, the San Francisco 49ers. He welcomes your comments sent to meskes@debian.org.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- What's the tweeting protocol?
- Tech Tip: Really Simple HTTP Server with Python
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




4 hours 2 min ago
7 hours 37 min ago
8 hours 10 min ago
10 hours 33 min ago
10 hours 37 min ago
10 hours 38 min ago
15 hours 3 min ago
16 hours 54 min ago
22 hours 7 min ago
1 day 1 hour ago