A guide to Linux signals

A note: SIGHUP is far from obsolete in its original purpose. We may have stopped using modems but people still log in to Unix machines in ways that can get disconnected. If you SSH in to a machine and your SSH session is cut off by a network issue, your shell (and any command you have running) will get a SIGHUP.

Catching signals is a great way of catching nasty bugs in production code. I use them to be able to log information on the cause of an error before the code exits due to some sort of catastrophic bug (e.g. null pointer deference, etc). This also allows you to clean up to clean up temp files, etc. They are much nicer to use than the Windows equivalent.

One thing that might have been nice to note is the rules regarding what you can and can't do in signal handler code.

For a more in-depth look at Signals, there&#x27;s Michael Kerrisk&#x27;s Linux Man Pages on Signals [1]. AFAIK, the best reference on Signals is in the book by Stevens and Rago [2].<p>[1] <a href="http:&#x2F;&#x2F;man7.org&#x2F;linux&#x2F;man-pages&#x2F;man7&#x2F;signal.7.html" rel="nofollow">http:&#x2F;&#x2F;man7.org&#x2F;linux&#x2F;man-pages&#x2F;man7&#x2F;signal.7.html</a> [2] Advanced Programming in the Unix Environment, Second Edition

<p><pre><code> ps -ef | grep foobar </code></pre> is more easily done with<p><pre><code> pgrep foobar </code></pre> or perhaps<p><pre><code> pgrep -a foobar</code></pre>

What about SIGSTOP and SIGCONT? They&#x27;re quite useful to pause and resume processes (Ctrl-Z).

Aren&#x27;t these Unix (or, more accurately, POSIX) signals, rather than Linux signals?

WINCH comes from the terminal driver, not from the &quot;window manager&quot;.

Thank you for this excellent article. Much appreciated!

The trouble with signals is that there are so few of them and we can&#x27;t add more without breaking the ABI.