Cosa è successo ai segnali di uccisione 32 e 33?

Question

Se si immette kill -l in bash e si sonda il numero di segnali.

Che cosa è successo ai segnali di eliminazione 32 e 33?

Answer 1

Questo non è centrato su Centos. Su Archlinux ho:

$ kill -l 
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 

Come si può vedere, ciò che è più di 31 è sempre lo stesso segnale SIGRTMAX con alcune variazioni.

Inoltre, sul file sorgente /usr/include/asm/signal.h abbiamo trovato:

#define NSIG  32 
typedef unsigned long sigset_t; 

#endif /* __ASSEMBLY__ */ 

#define SIGHUP  1 
#define SIGINT  2 
#define SIGQUIT  3 
#define SIGILL  4 
#define SIGTRAP  5 
#define SIGABRT  6 
#define SIGIOT  6 
#define SIGBUS  7 
#define SIGFPE  8 
#define SIGKILL  9 
#define SIGUSR1  10 
#define SIGSEGV  11 
#define SIGUSR2  12 
#define SIGPIPE  13 
#define SIGALRM  14 
#define SIGTERM  15 
#define SIGSTKFLT 16 
#define SIGCHLD  17 
#define SIGCONT  18 
#define SIGSTOP  19 
#define SIGTSTP  20 
#define SIGTTIN  21 
#define SIGTTOU  22 
#define SIGURG  23 
#define SIGXCPU  24 
#define SIGXFSZ  25 
#define SIGVTALRM 26 
#define SIGPROF  27 
#define SIGWINCH 28 
#define SIGIO  29 
#define SIGPOLL  SIGIO 
/* 
#define SIGLOST  29 
*/ 
#define SIGPWR  30 
#define SIGSYS  31 
#define SIGUNUSED 31 

/* These should not be considered constants from userland. */ 
#define SIGRTMIN 32 
#define SIGRTMAX _NSIG 

Ciò conferma che SIGRTMIN & SIGRTMAX sono i più grandi segnali e avere il valore 32 entrambi.

altre informazioni su segnali a man 7 signals

Answer 2

L'opzione POSIX realtime signals definisce un insieme di segnali da SIGRTMIN a SIGRTMAX aventi diverse proprietà utili (ad esempio, essi hanno una priorità di ben definito - basso numero primo segnale - e più istanze dello stesso segnale possono essere accodate e associate a un parametro tramite sigqueue(). Questi sono implementati dal kernel usando i numeri di segnale 32 verso l'alto.

Ma POSIX non richiede SIGRTMIN e SIGRTMAX di essere costanti per codice utente-terra a tempo di compilazione, e la GNU libc non lo sono: se si mette un file di origine utilizzando l'utente-land <signal.h> attraverso il preprocessore (ad esempio, con gcc -E), vedrai che SIGRTMIN si espande effettivamente a (__libc_current_sigrtmin()).

implementation of this inside glibc riserva almeno i primi due valori supportati dal kernel per i propri scopi interni. Il primo di questi (la più alta priorità di tale segnale) viene utilizzato per supportare la gestione della cancellazione del thread; il secondo è usato per qualcosa relativo all'implementazione di setuid. (Vedere here. Non so quali circostanze utilizzino la capacità di allocare ulteriori segnali per uso interno.)

Quindi i numeri di segnale mancanti sono dovuti a bash che mostra la vista di un'applicazione dei segnali disponibili (che omette quelli utilizzati internamente da glibc), piuttosto che dal punto di vista del kernel.