
A guide to Linux signals - benev
http://www.linuxvoice.com/core-technology-signals/
======
thatcks
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.

~~~
dozzie
There's more than that in SIGHUP. It's sent to the process group owning the
terminal[1] (/dev/tty[1-X], /dev/pts/*) when said terminal is closed. Your
shell, Midnight Commander, Vim, Emacs, and what not terminates when you close
your terminal emulator window.

[1] I don't quite remember what happens to other process groups, since you
could have some background jobs stopped.

~~~
misterdata
Yes, and using the 'nohup' utility you can effectively block the delivery of
SIGHUP to a particular process, to ensure it does not terminate when you close
your SSH connection.

~~~
jon-wood
Awesome, I knew nohup could be used for that, but hadn't worked out why it was
called that.

------
danieltillett
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.

~~~
useerup
> They are much nicer to use than the Windows equivalent

Seriously? You find a system with global events where you must perform your
own resource book-keeping to clean up the correct resources nicer than
structured exception handling?

~~~
danieltillett
Yes as soon as you have to support both 32 and 64 builds in a multi-threaded
program that is using the C run time library. This of course is just my
opinion :)

~~~
pjc50
Why is SEH a problem in that case? SEH is occasionally flaky but much nicer
than trying to handle SEGV.

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

~~~
JoeAltmaier
One of my pet peeves: documentation that doesn't say anything. Methods (and
callbacks) are listed by name with some thrifty description of argument. But
none of the important stuff is ever there: is it reentrant? stateless? Who
owns each non-scalar argument? Can it be invoked from user space? installable
driver? kernel driver? Signal handler? Does it have latency constraints? Can I
use it from a different thread than it was constructed under? Is it protected
during thread death? Is it atomic vs what other methods? What other apis are
allowed/forbidden when writing a callback?

As an embedded programmer, I end up reading library source most of the time
trying to find these answers. And if it isn't open, then I have to black-box
test or lard calls up with semaphores which might not be necessary. The state
of API documentation is in the stone age.

------
sohkamyung
For a more in-depth look at Signals, there's Michael Kerrisk's Linux Man Pages
on Signals [1]. AFAIK, the best reference on Signals is in the book by Stevens
and Rago [2].

[1] [http://man7.org/linux/man-
pages/man7/signal.7.html](http://man7.org/linux/man-pages/man7/signal.7.html)
[2] Advanced Programming in the Unix Environment, Second Edition

------
Symbiote

        ps -ef | grep foobar
    

is more easily done with

    
    
        pgrep foobar
    

or perhaps

    
    
        pgrep -a foobar

~~~
SEJeff
or ps -ef | grep fo[o]bar

So you don't have to | grep -v grep :)

I ask people to explain what that does and how it works as a sysadmin
interview question.

~~~
notfoss
That's nice. Apparently, we can place the brackets around any of the
characters too! Can you explain how it works?

~~~
SEJeff
Sure, the square brackets in posix regex (used by grep) are for character
ranges. You can wrap any single character in the brackets and it works the
same.

So foob[a]r matches the literal string foobar. If you grepped foob[ab]r it
would match both literal strings foobar and foobbr. However, it doesn't match
the literal string foob[a]r because [] is a character range. To match that,
you'd need to escape it something like foob\\[a\\]r, which would _not_ match
the literal string foobar. This is why you don't need grep -v grep

Understanding how and why this works will dramatically help you slice and dice
text strings in a shell, so it makes a great SysAdmin interview question.

------
mixblast
What about SIGSTOP and SIGCONT? They're quite useful to pause and resume
processes (Ctrl-Z).

~~~
noselasd
And indeed also very useful for testing. "what happens if we simulate this
process being a bit slow" \- send it a SIGSTOP. Doing so can simulate a number
of other weird cases too as observed from the outside , such as a process
trashing on swap, NFS hanging.

I've found that doing that to etcd causes other etcd in the cluster to
randomly hang - while it handles a lot of other failures fine (instant
poweroff, network partitioning, randomly crash etcd, sending SIGSTOP to on
member of a cluster breaks everything - I don't know if that's improved since
I did those tests though)

------
jackgavigan
Aren't these Unix (or, more accurately, POSIX) signals, rather than Linux
signals?

------
wnoise
WINCH comes from the terminal driver, not from the "window manager".

------
positron4
Thank you for this excellent article. Much appreciated!

------
rewqfdsa
The trouble with signals is that there are so few of them and we can't add
more without breaking the ABI.

~~~
nitrogen
If you need to send more types of messages, there are other IPC mechanisms.

