38.11 Printer Queue Watcher: A Restartable Daemon Shell Script

[This article may not appear to have a lot to do with the subject of this chapter, but it illustrates the other side of signal handling - what a program or shell script can do when it receives a signal. Jerry's script uses the trap (44.12 ) command to catch several different signals, and act differently depending on whether the signal is a "hangup" (HUP , or signal 1) or a TERM (signal 15). -TOR ]

UNIX systems run "daemon" programs like cron (8) and syslogd (8) that wait in the background, looking for work to do. Many daemons read configuration files when they start up. System administrators sometimes change the configuration files and want the daemon to re-read the file. One way to do that is by terminating and restarting the program - but that's ugly and also means the daemon won't be running for a few seconds until it's restarted. So, many daemons are designed to re-read their configuration files and/or restart themselves when they get a signal (usually, the HUP signal, signal 1). System administrators do this by getting the daemon's process ID number and sending the signal with the kill command. Because the daemon "catches" the signal, the daemon isn't actually killed.

You can run a shell script as a daemon by putting it in the background. [4] Here's a simple example, a shell script named watchq . It reads a file full of printer queue names and stores it in a shell variable. Every 30 seconds, it runs lpq (43.2 ) on all printer queues listed. If any queues have an error, the script echoes a message and the output of lpq to a particular user with the write (1.33 ) command.

[4] It's usually also a good idea to be sure that the input and outputs are redirected (13.1 , 45.21 ) away from the terminal, maybe to the system console instead. On systems and shells that kill background jobs when you log out, use nohup (38.18 ) .

After the script has run for a while, the printer named office goes down. I edit the watchqs file and remove that printer so the poor user lisa won't keep getting complaints about it. Then I send a signal to have the file re-read:

/dev/null
 
-
 









kill
 

% cat watchq


#! /bin/sh
# watchq - "daemon" script that watches printer queue(s) for errors
temp=/tmp/WATCHQ$$             # Holds output of lpq
watch=/usr/local/lib/watchqs   # Queue names to watch
writeto=lisa                   # User who gets notices about printer
queues="`cat $watch`"          # Put list of queue names in $queues
trap 'queues="`cat $watch`"' 1 # Reset $queues if we get a SIGHUP
trap 'rm -f $temp; exit' 0 15  # Clean up temp file when killed

# Loop forever (until someone kills script):
while :
do
    for queue in $queues
    do
        lpq -P$queue >$temp
        if egrep '(out of paper|error|warning)' $temp >/dev/null
        then echo "PRINTER QUEUE $queue:" | cat - $temp | write $writeto
        fi
    done
    sleep 30
done
% echo office main lobby > /usr/local/lib/watchqs


% watchq &


[1] 4363
   ...
% echo main lobby > /usr/local/lib/watchqs


% kill -1 4363


   ...
% kill 4363


[1]    Exit -48             watchq

In real life, the watchq script might be started from a system file like /etc/rc.local when the system reboots. Lisa would probably edit the watchqs file herself. The username that's notified by write might also be resettable with a kill -1 .

This isn't foolproof and you can run into subtle problems. For instance, the write command may not work on some UNIXes if it's running from a daemon without a controlling tty (38.6 ) . Also, the error messages that egrep (27.5 ) searches for may not catch all problems and are system-dependent. But this script is just a demonstration - to show a great way to write a quick-and-dirty daemon.