Linux Watchdog Daemon - Version 6.0

Back to PSC's home page
Back to Watchdog

Watchdog V6.0

This page provides just a simple link to download the source code and differential patches (about 0.5MB tar/gzip file) that have been used to create an "experimental version 6.0" of the Linux Watchdog for use in Dundee with the following updates/changes/improvements (depending on your point of view) starting from the original 5.13 version:

You can read the changelog here.

NOTE: This is not the official version, that is maintained by Michael Meskes "meskes at debian dot org" and the GIT site is here:  A number of the the above changes made in Dundee have been incorporated in to the official version, but some have not been done yet.

NOTE: Check back periodically to get the archive file, as the "V6.0" number mentioned here will not be updated until it is considered 'stable'. You did read the bit about this being experimental, didn't you?

This page is intended for folk who want to try this out, but before doing so you should read the patch-log.txt file and take a look at the source code to see it is doing what you want. The 'xref' directory has two sub-directories that tell you which patches affect which files, and which files have been changed by a list of patches.

WARNING: The information on this page, and in the linked source code, is provided with absolutely no warranty at all so do not use it for production systems, etc, without thorough testing. We accept no liability for any errors or omissions!
[top of page]


To build the test version, grab the archive linked to from this page, uncompress it, and then uncompress the watchdog-6.0.tar.gz file from inside that. Change in to that directory (watchdog-6.0) and then run the commands:

autoreconf -i
cd src

You need to have the appropriate tools installed, I think if you use "apt-get build-dep watchdog" on a Debian/Ubuntu machine (as root or using sudo as appropriate) it installs what you need. However, it seems you may need some extra tools installed:

apt-get install build-essential automake libtool

In addition you might want to install GIT and learn how to use it to make a clone of the official version later, so that you can try code changes, etc.

To run that version stop any current official package with "pkill watchdog" (as root or with sudo, but do not kill with -9 or you will reboot by surprise if hardware timer is in use). Don't use the usual "service watchdog stop" as that starts the wd_keepalive daemon in its place.

Then run the compiled version with "./watchdog -c test.conf -v" where test.conf is a local copy of your normal file edited to add any special options (e.g. the temperature devices). The -v option will result in lots of syslog messages about the temperature(s) and any other checks, etc, but will help you verify it looks OK.

See also the configuration page and the command-line options on this site.
[top of page]

Debugging Options

Makefile Build Options

The Makefile created by the 5.13-era of git clone has the compile settings:

CFLAGS = -g -O2

Which enabled debug symbols (-g) and normal levels of release code optimisation (-O2). This results in a larger binary than the “as shipped” version, but in the event of needing to use gdb for debugging, there is enough information to be usable. However, this is not optimal for release or debugging/development, so you might want to manually edit the Makefile and change the above line to one of the following choices. For release only:

CFLAGS = -O2 -Wall

If you keep the '-g' option for debug symbols you can use the 'strip' command to remove them later to make the binary smaller.

For debugging:

CFLAGS = -g -O0 -DDEBUG -Wall

In this case the “-DDEBUG” option results in the fatal_error() call in logmessage.c using an asert() call to cause a core-dump if such an error message is output. This is not recommended for production use or live testing! The use of "-Wall" for picking up coding errors is also strongly recommended, even if some of the warnings are pedantic, it is worth taking a careful look at any problems it finds.

Generally to enable the core dump for analysis by gdb you need to run the following bash command before you run the daemon:

ulimit -c unlimited

[top of page]

Memory Checking - Electric Fence

In addition, you might be interested in checking for memory errors to prevent leaks slowly using up system memory. One useful tool in this respect the Electric Fence library which replaces the normal glibc memory allocation and freeing routines by ones that use the hardware virtual memory manager to enforce checking. Make sure you install this with the command:

apt-get install electric-fence

Then edit the Makefile to change the "LIBS" line to add "-lefence":

LIBS = -lrt -lefence

If the program makes a mistake with access to dynamically allocated memory then it will simply core-dump. So if testing with this option you should disable the use of the hardware watchdog (by editing the config file) or use the --no-action command line to stop it from opening /dev/watchdog even when configured to do so.
Again, this is not for production use!

[top of page]

Memory Checking - Valgrind

Another tool for solving memory access problems is 'valgrind' which runs the program under test in what is essentially a virtual machine. An example of using valgrind is given here:

When I ran it I used this command:

valgrind --tool=memcheck --leak-check=full --show-reachable=yes --track-origins=yes \
            ./watchdog --config-file ../watchdog.conf --verbose --foreground \
            --no-action --force --loop-exit 5

One problem with this is you can't then easily send a signal to the watchdog as it is being tested to stop it normally. To deal with this type of test the '--loop-exit' command line option was added, with the above example running for 5 intervals.

[top of page]

Last Updated on 28-Mar-2016 by Paul Crawford
Copyright (c) 2014-16 by Paul S. Crawford. All rights reserved.
Email psc(at)sat(dot)dundee(dot)ac(dot)uk
Absolutely no warranty, use this information at your own risk.