Signal queue depth in Linux

signals

How many signals can be queued on a process that has all signals blocked? What if I use sigqueue() more often then that limit? Will those signals not be queued? Will I get an error?

Best Answer

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.

Related Solutions

Process Signals – Causes of Various Signals Sent to Processes

In addition to processes calling kill(2), some signals are sent by the kernel (or sometimes by the process itself) in various circumstances:

Terminal drivers send signals corresponding to various events:
- Key press notifications: SIGINT (please go back to the main loop) on Ctrl+C, SIGQUIT (please quit immediately) on Ctrl+\, SIGTSTP (please suspend) on Ctrl+Z. The keys can be changed with the stty command.
- SIGTTIN and SIGTTOU are sent when a background process tries to read or write to its controlling terminal.
- SIGWINCH is sent to signal that the size of the terminal window has changed.
- SIGHUP is sent to signal that the terminal has disappeared (historically because your modem had hung up, nowadays usually because you've closed the terminal emulator window).
Some processor traps can generate a signal. The details are architecture and system dependent; here are typical examples:
- SIGBUS for an unaligned access memory;
- SIGSEGV for an access to an unmapped page;
- SIGILL for an illegal instruction (bad opcode);
- SIGFPE for a floating-point instruction with bad arguments (e.g. sqrt(-1)).
A number of signals notify the target process that some system event has occured:
- SIGALRM notifies that a timer set by the process has expired. Timers can be set with alarm, setitimer and others.
- SIGCHLD notifies a process that one of its children has died.
- SIGPIPE is generated when a process tries to write to a pipe when the reading end has been closed (the idea is that if you run foo | bar and bar exits, foo gets killed by a SIGPIPE).
- SIGPOLL (also called SIGIO) notifies the process that a pollable event has occured. POSIX specifies pollable events registered through the I_SETSIG ioctl. Many systems allow pollable events on any file descriptor, set via the O_ASYNC fcntl flag. A related signal is SIGURG, which notifies of urgent data on a device (registered via the I_SETSIG ioctl) or socket.
- On some systems, SIGPWR is sent to all processes when the UPS signals that a power failure is imminent.

These lists are not exhaustive. Standard signals are defined in signal.h.

Most signals can be caught and handled (or ignored) by the application. The only two portable signals that cannot be caught are SIGKILL (just die) and STOP (stop execution).

SIGSEGV (segmentation fault) and its cousin SIGBUS (bus error) can be caught, but it's a bad idea unless you really know what you're doing. A common application for catching them is printing a stack trace or other debug information. A more advanced application is to implement some kind of in-process memory management, or to trap bad instructions in virtual machine engines.

Finally, let me mention something that isn't a signal. When you press Ctrl+D at the beginning of a line in a program that's reading input from the terminal, this tells the program that the end of the input file is reached. This isn't a signal: it's transmitted via the input/output API. Like Ctrl+C and friends, the key can be configured with stty.

Bash – calling sigprocmask from bash

There doesn't seem to be a pure bash solution.

Ksh (both ksh93 and mksh) unblock all signals (tested on Debian wheezy), so if you can use ksh instead of bash, it will solve your problem.

If you can't change the fact that bash is invoked, you might be able to make bash execute ksh and make ksh execute the child process: replace

bash -c '…; exec child_process'

bash -c '…; exec ksh -c "exec child_process"'

Beware of quoting issues!

Ksh is fast and easy to use, but often not part of the default installation. If that is an issue, you can use Perl instead, which is part of the default installation in most non-embedded Linux systems.

perl -e '
    use POSIX;
    $s = POSIX::SigSet->new(); $s->fillset();
    sigprocmask(1, $s, $s) or die $!;    # 1 = SIG_UNBLOCK
    exec "child_process"'