24

Executing kill -l on linux gives:

 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX

What happened to 32 and 33? Why is it not listed? They could have started at 1 and ended at 62 instead of skipping 2 in the middle?

Improve this question
1
  • P.S. There are not "error codes" -- they are signal numbers. Commented Sep 16, 2014 at 15:52

2 Answers 2

Reset to default
25

It is because of NPTL. Since it is part of the GNU C library nearly every modern linux distribution doesn't use the first two real time signals anymore. NPTL is an implementation of the POSIX Threads. NPTL makes internal use of the first two real-time signals.

This part of the signal manpage is very interesting:

The Linux kernel supports a range of 33 different real-time signals, numbered 32 to 64. However, the glibc POSIX threads implementation internally uses two (for NPTL) or three (for LinuxThreads) real-time signals (see pthreads(7)), and adjusts the value of SIGRTMIN suitably (to 34 or 35). Because the range of available real-time signals varies according to the glibc threading implementation (and this variation can occur at run time according to the available kernel and glibc), and indeed the range of real-time signals varies across UNIX systems, programs should never refer to real-time signals using hard-coded numbers, but instead should always refer to real-time signals using the notation SIGRTMIN+n, and include suitable (run-time) checks that SIGRTMIN+n does not exceed SIGRTMAX.

I also checked the source code for glibc; see line 22. __SIGRTMIN is increased +2, so the first two real time signals are excluded from the range of real time signals.

Improve this answer
1
  • So how does one get the current value of SIGRTMIN at run-time in a piece of executing code? Commented Feb 29, 2016 at 7:20
12

Because the signals are:

SIGWAITING 32 Ignore All LWPs blocked SIGLWP 33 Ignore Virtual Interprocessor Interrupt for Threads Library

Neither of which are supported in Linux. (LWP stands for LightWeight Process)

Source: IBM DeveloperWorks Solaris to Linux Porting Guide

Improve this answer
4
  • Linux had signal 32 and 33. See: unixhelp.ed.ac.uk/CGI/man-cgi?signal+7, Real-time Signals section. Commented Sep 16, 2014 at 9:50
  • @Gnouc - according to kill -l RTMIN starts at 34, not 32 as per you referenced document. This one says it starts at 33, but goes on to say that you shouldn't reference them by numbers as the numbers may vary depending on glibc threading implementation. Commented Sep 16, 2014 at 9:58
  • Of course it varies base on system, but the term Linux does not supported is incorrect. You can refer this: cse.psu.edu/~dheller/cmpsc311/Lectures/Process-Control-Signals/…. Maybe we need a vereran who working with Linux long time ago to let us know what happen with signal 32, 33. Why aren't they documented. Commented Sep 16, 2014 at 10:03
  • They are used internally by the RT pthread library - and in the past there would be three not two because a different system used that many for internal purposes. From a coding point of view you are not supposed to use compile-time constants for the signals above SIGSYS e.g. a SIGRTMIN set with a #define line because that number is subject to possible change later when the executable is run. This would have shown up a few years ago when both pthread libs were in use if an application compiled against the one pthread library was run on a system that had been rebooted with the other! Commented Feb 29, 2016 at 7:18

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.