Was ist mit den 32- und 33-Kill-Signalen passiert?

Die Option POSIX-Echtzeitsignale definiert eine Reihe von Signalen von SIGRTMIN bis SIGRTMAX , die verschiedene nützliche Eigenschaften haben (z. B. haben sie eine klar definierte Lieferpriorität - die niedrigste Signalnummer zuerst - und mehrere Instanzen des gleichen Signals können in die Warteschlange gestellt und über sigqueue() mit einem Parameter verknüpft werden). Diese werden vom Kernel mit den Signalnummern 32 aufwärts implementiert.

Aber POSIX benötigt nicht SIGRTMIN und SIGRTMAX als Kompilierzeitkonstanten für den User-Land-Code, und in der GNU libc sind sie nicht: wenn Sie eine Quelldatei mit dem Benutzer-land <signal.h> einfügen Durch den Präprozessor (zB mit gcc -E ) sehen Sie, dass SIGRTMIN tatsächlich auf (__libc_current_sigrtmin()) expandiert.

Die Implementation dieser inneren Glibc reserviert mindestens die ersten zwei Werte, die vom Kernel für seine eigenen internen Zwecke unterstützt werden. Der erste von ihnen (das Signal mit der höchsten Priorität) wird verwendet, um die Thread-Löschungsbehandlung zu unterstützen; Die zweite wird für etwas verwendet, das mit der Implementierung von setuid zusammenhängt. (Siehe hier Ich bin nicht sicher, welche Umstände die Fähigkeit nutzen, weitere Signale für den internen Gebrauch zuzuordnen.

Die fehlenden Signalnummern sind daher auf bash zurückzuführen, die Ihnen die Ansicht einer Anwendung auf die verfügbaren Signale zeigt (wobei die von glibc intern verwendeten Signale weggelassen werden) und nicht die Ansicht des Kernels.