Linux – a fatal signal

linuxsignals

The Linux Programming Interface says:

TASK_KILLABLE : This state is like TASK_UNINTERRUPTIBLE , but wakes the process if a fatal signal (i.e., one that would kill the process) is received. By converting relevant parts of the kernel code to use this state, various scenarios where a hung process requires a system restart can be avoided. Instead, the process can be killed by sending it a fatal signal. The first piece of kernel code to be converted to use TASK_KILLABLE was NFS.

A fatal signal can wake up a process in TASK_KILLABLE but not in TASK_UNINTERRUPTIBLE.

Does a fatal signal mean only SIGKILL, or also SIGTERM, SIGHUP, SIGQUIT, SIGINT, or …?

Best Answer

Most signals are fatal by default. Any signal listed with a default action of “terminate” or “dump core” is fatal, unless it’s ignored or handled explicitly. This includes such “benign” signals as SIGUSR1, as well as SIGKILL of course, SIGTERM etc.

This matches the Linux kernel’s definition of fatal signals; for a signal to be fatal:

it mustn’t be one of the ignored signals (from the kernel’s perspective) or one of the stop signals, i.e. respectively SIGCONT, SIGCHLD, SIGWINCH, and SIGURG on the one hand, and SIGSTOP, SIGTSTP, SIGTTIN, and SIGTTOU on the other;
its signal handler must be the default handler.

Thus a fatal signal is one which would result in the process being killed (without going through a handler specified by the program being run).

Related Solutions

Linux – Can signal be ignored (lost)

Aside from the "too many signals" problem, signals can be explicitly ignored. From man 2 signal:

If the signal signum is delivered to the process, then one of the
following happens:    
  *  If the disposition is set to SIG_IGN, then the signal is ignored.

Signals can also be blocked. From man 7 signal;

A signal may be blocked, which means that it will not be delivered
until it is later unblocked.  Between the time when it is generated
and when it is delivered a signal is said to be pending.

Both blocked and ignored sets of signals are inherited by child processes, so it may happen that the parent process of your application ignored or blocked one of these signals.

What happens when multiple signals are delivered before the process has finished handling previous ones? That depends on the OS. The signal(2) manpage linked above discusses it:

System V would reset the signal disposition to the default. Worse, rapid delivery of multiple signals would result in recursive (?) calls.
BSD would automatically block the signal until the handler is done.
On Linux, this depends on the compilation flags set for GNU libc, but I'd expect the BSD behaviour.

Signal queue depth in Linux

With ulimit

$ ulimit -a |grep signals 
  pending signals                 (-i) 62384

With plain C

$ cat<<EOF > siglimit.c
#include <stdio.h>
#include <unistd.h>
int main() { printf("%ld\n", sysconf( _SC_SIGQUEUE_MAX)); return 0; }
EOF
$ gcc siglimit.c && ./a.out
62384

You may, of course, get a value other than 62384, which is what I got on my system.