One of many signal
s that can be sent to a process in the unix environment, and certainly one of my favorites. In contrast to the polite SIGHUP
or the obscure SIGABRT
, it shows you mean business - that process had better freaking reform
. In the metaphor of Doom-based process control
, you are pulling out the rocket launcher.
Many people are used to sending signals with the kill command, and think of signals purely in this context, however, signals have been made to serve many purposes beyond merely vaporizing running processes, in what is really a form of primitive inter-process communication. The kernel of a unix system will send a process a SIGSEGV if it attempts to step outside of the ring and start fighting with the audience; there is also the ever popular SIGBUS and SIGILL... all of which inspire your process to shit its memory image in your home directory as what is commonly called a core before keeling over. Occasionally, you will meet someone who actually knows what to do with these files other than delete them. Call the police. Do not attempt to apprehend this person yourself.
Processes can ask themselves to be signaled at intervals with a SIGALRM. They're notified via signal when their children die (SIGCHLD). Signals play an integral role in stop and go debugging (SIGTRAP, SIGSTOP, SIGCONT). Users can even generate their own signals for whatever wack purpose they desire, although that would make them pretty weird (SIGUSR1, etc).
All of these signals are just #define's in an include file (signal.h!) - defined to integers. So people generally save typing by memorizing the integer equivalents of the signal names. Most unix users know SIGKILL's is 9. Many others will know SIGHUP's is 1.
As this is one of the more "hidden in plain sight" aspects of unix, the exact meaning and purpose of many signals is not generally documented, even in the excellently organized linux documentation. I was going to put some links here to make up for that but, funny thing, I couldn't find any. The tradition continues.
SIGKILL has, however, a reputation of effectiveness that it does not deserve. Many people consider a kill -9 a kind fire-and-forget affair. Others claim that it "cannot be trapped or ignored." Unfortunately, this isn't quite the case.
Yes, a programmer can use a simple API (different on different unices) to trap signals and therefore "handle" them - by executing whatever code one would like in response. By design, some signals are meant to be untrappable, to minimize the effect of bugs in the signal handlers of irresponsible programmers. Unfortunately, it is possible to trap SIGKILL.
No, I will not tell you how. The knowledge must not be used for evil.
Worse yet, processes need not have malevolent intentions in order to become unkillable. In the process table, the operating system maintains a state flag describing the process state of every... uh... process. Running and Sleeping (R and S in your ps output) are the two most common, but beware the devil...
D - Uninterruptible sleep "(Usually IO)"
When a process has blocked for an IO operation, it has, more or less, transferred its execution to codespace inside a kernel device driver, which is busy trying to get some blocks off a disk, or display pr0n on your screen, and so forth.
Maybe you can see where this is going. Theoretically, the user-space process is asleep - and not taking up CPU time - because it's waiting to be "woken up" by the kernel when the blocking IO operation completes.
Unfortunately, and this is the painful truth, sometimes blocking IO operations never return.
In that case, my friends, your signals queue up, waiting for a day which will never come. The read and write locks are never going away. That process will be there forever. It can survive a hail of kill -9's as if they were little fluffy feathers, all the while laughing at your impotence.
Device drivers, you see, don't take kindly to handling signals.
Is this a design flaw? Perhaps. Although you can never make asynchronous event management fine-grained enough to satisfy everyone. And the true argument is made - if your device driver is blocking calls forever, you've probably got bigger problems...
For the record, the existence of the SIGKILL_DESPERATELY signal is a just a rumor, spread by desperate, burned souls from email clients running on the last available slot on their process tables.
By way of epilogue, I should probably mention Zombie processes as well, though these are, contrary to popular belief, less severe - the result of simple miscommunication between parent and child.