Search

Work the Shell - Dealing with Signals

This month, I thought it would be interesting to take a bit of a detour from
my usual multi-month programming projects and instead focus on a specific
topic that is of great importance to people writing longer scripts: signal
management.

Signals are numeric messages sent to running applications from the
operating system, other applications or the user, and they generally invoke
a specific response like “shut down gracefully”, “stop
running so I can put you in the background” or “die!”

Most likely, you've used the kill command to send signals to
different programs, but if you've ever pressed Ctrl-C or Ctrl-Z to stop
a running app, you've also sent signals to a running application.

A signal is managed in a cascading manner. It's sent to the application
or script, then if the application doesn't have a specific handler
(signal management or response function), it's pushed back to the shell
or operating system. Some signals can't be managed within individual
apps, like SIGKILL, which is caught by the operating system and immediately
kills the running application (including the shell: SIGKILL your login
shell and you just logged out).

To start this journey, let's find out what signals your version of
Linux can handle. Do this by typing kill -l
(that's a lowercase L, not the digit 1):

Most of these are uninteresting. The cool ones are SIGHUP, which is sent on
a “hangup” or the user logging out; SIGINT, which is a simple
interrupt (Ctrl-C, usually); SIGKILL, the “terminate with extreme
prejudice” of signals; SIGTSTP, which is Ctrl-Z; SIGCONT, which is what
the application gets from the shell commands fg and bg subsequent
to a SIGTSTP; SIGWINCH, which is for window system events like a window
resize; and SIGUSR1 and SIGUSR2, which are intended for interprocess
communication.

Let's write some code to see what happens, shall we? Signals are
caught with the “trap” built in, and the general format of these
signal mapping commands is exemplified with:

Did you catch the infinite loop there? It's barely using any
resources because most of its time is spent in “sleep”, but if you
don't do something to end it, this script will run forever or until the
Mayans are proven right two years from now—one of the two.

Let's look at a more flexible way to manage signals by creating shell
script functions:

Perfect! To send the signals, execute the following commands
from a different terminal window:

$ kill -HUP 25309
$ kill -QUIT 25309
$ kill -INT 25309

Armed with this useful script, let's have a look at how to handle
a more complex signal like Ctrl-Z within a shell script.

Stop! Don't Stop!

I'm going to create a scenario here rather than just going
through the intellectual exercise. In a complex script, you realize that
you have certain passages where you need to ignore the TSTP signal (SIGTSTP
or Ctrl-Z or signal number 18) and other spots where it's fine to stop and restart.
Can it be done?

To start working out a solution, I'll create a function that not only
handles the specified signal, but also disables itself after a single
invocation:

Invoke trap - signal somewhere else in the script,
and you've reset that signal handler, so if I have the line:

trap 'sigtstp' TSTP

right before the section where I don't want the Ctrl-Z to work,
it'll ignore that first Ctrl-Z, then reset the signal handler and work
as expected the second time you press that key.

More useful is to ignore all Ctrl-Z stop signals until you're ready to
deal with them, and that's quite easily done with the minimalist:

trap : TSTP # ignore Ctrl-Z requests

And, then when you're ready to receive them again:

trap - TSTP # allow Ctrl-Z requests

Experimentation will show that there are some weird terminal buffering
issues associated with SIGTSTP, however, so don't be surprised if
you have a signal handler that has output. In this particular instance, it
won't show up until the script quits.

Reading a Configuration File

Let's look at a more practical example. Say you have an admin script that
is always supposed to be running as a dæmon, but occasionally you want to
tweak its configuration file and have it reread its setup (a lot faster
than killing and restarting it).

Further, let's use SIGUSR1 for this task, as that is its intended use,
so we're using the kernel's signal handling subsystem in the manner
it was intended.

Reading a configuration file might be something as simple as:

. $config

(Recall that using . means that any variables set in the
secondary file affect the current shell, not a subshell.
The source command does the same thing as the . command.)

We'll start with the configuration file containing
number=5,
then after 10–15 seconds, change it to number=1. Until we send
the actual USR1 signal, however, the script just plugs along without a clue
that it has changed:

Meanwhile, in another window, I've already edited the file, so I type in
this command:

$ kill -USR1 25843

And, here's what happens in the main script window:

(SIGUSR1: re-reading config file)
Target number = 1
Target number = 1

Cool, eh?

I hope this exploration of signal handling in shell scripts is
useful. I actually learned quite a bit about advanced handling as I
researched the code here. I'm still a bit stymied about how to reset the output
stream after catching a SIGTSTP, but I bet that some sharp
Linux Journal reader will have an answer.

Dave Taylor has been hacking shell scripts for a really long time, 30
years. He's the author of the popular Wicked Cool Shell
Scripts and can be found on Twitter as @DaveTaylor and more generally
at www.DaveTaylorOnline.com.