What has happened to the 32 and 33 kill signals?

Question

If you enter kill -l in bash and probe number of signals.

What has happened to the 32 and 33 kill signals?

Answer 1

The POSIX realtime signals option defines a set of signals from SIGRTMIN to SIGRTMAX which have various useful properties (e.g. they have a well-defined delivery priority -- lowest signal number first -- and multiple instances of the same signal can be queued, and associated with a parameter, via sigqueue()). These are implemented by the kernel using signal numbers 32 upwards.

But POSIX does not require SIGRTMIN and SIGRTMAX to be compile-time constants for user-land code, and in the GNU libc they are not: if you put a source file using the user-land <signal.h> through the preprocessor (e.g. with gcc -E), you'll see that SIGRTMIN actually expands to (__libc_current_sigrtmin()).

The implementation of this inside glibc reserves at least the first two values supported by the kernel for its own internal purposes. The first of those (the highest priority such signal) is used to support thread cancellation handling; the second is used for something related to the implementation of setuid. (See here. I'm not sure what circumstances make use of the ability to allocate further signals for internal use.)

So the missing signal numbers are due to bash showing you an application's view of the available signals (which omits those used internally by glibc), rather than the kernel's view.