SIGNAL(7) | Manuale del programmatore di Linux | SIGNAL(7) |
signal - panoramica sui segnali
Linux supporta sia i segnali POSIX affidabili (d'ora in avanti "segnali standard") che i segnali real-time POSIX.
Ciascun segnale ha una disposizione attuale, che determina come si comporta il processo quando il segnale viene recapitato.
Le voci nella colonna "Action" della tabella qui sotto specificanola disposizione predefinita di ogni segnale, come segue:
Un processo può cambiare la disposizione di un segnale usando sigaction(2) o signal(2) (L'ultimo è meno portabile quando si crea un gestore di segnale; si veda signal(2) per i dettagli.) Usando queste chiamate di sistema, un processo può assumere uno dei seguenti comportamenti al recapito del segnale: eseguire l'azione predefinita; ignorare il segnale; intercettare il segnale con un gestore di segnale, una funzione definita dal programmatore che è automaticamente invocata quando il segnale è recapitato.
Il gestore di segnale viene chiamato, in modo predefinito, nel normale stack del processo. È possibile fare in modo che il gestore di segnale usi uno stack alternativo: vedere sigaltstack(2) per una spiegazione su come farlo e quando può essere utile.
La disposizione del segnale è un attributo per processo: in un'applicazione multithread, la disposizione di un particolare segnale è la stessa per tutti i thread.
Un processo figlio creato tramite fork(2) eredita una copia della disposizione dei segnali del genitore. Durante un execve(2), la disposizione dei segnali gestiti viene inizializzata ai valori predefiniti; la disposizione dei segnali ignorati viene lasciata com'è.
Le seguenti chiamate di sistema e funzioni di libreria permettonoal chiamante di inviare un segnale:
Le seguenti chiamate di sistema sospendono l'esecuzione del thread chiamante finché non viene intercettato un segnale (o finché un segnale non gestito fa terminare il processo):
Anziché intercettare un segnale in modo asincrono tramite un gestore di segnale, è possibile accettare il segnale in modo sincrono, cioé bloccare l'esecuzione finché il segnale viene consegnato: a questo punto il kernel restituirà informazioni sul segnale al chiamante. Ci sono in generale due modi per farlo:
Un segnale può essere bloccato, cioé non verrà recapitato fino a quando non verrà sbloccato. Un segnale viene definito pendente nel periodo di tempo che passa tra quando è stato generato e quando è recapitato.
Ciascun thread in un processo ha una maschera segnale indipendente, che indica l'insieme di segnali che il thread attualmente sta bloccando. Un thread può manipolare la sua maschera segnale usando pthread_sigmask(3). In un'applicazione tradizionale a thread singolo, si può usare sigprocmask(2) per manipolare la maschera segnale.
Un processo figlio creato tramite fork(2) eredita una copia della maschera di segnale del processo genitore: la maschera di segnale viene preservata attraverso execve(2).
Un segnale può essere diretto al processo o diretto al thread. Un segnale diretto al processo è uno che è indirizzato (e quindi pendente) al processo nella sua interezza. Un segnale può essere diretto al processo perché è stato generato dal kernel per ragioni diverse da un'eccezione hardware, o perché è stato inviato usando kill(2) o sigqueue(3). Un segnale diretto al thread è uno che è indirizzato a uno specifico thread. Un segnale può essere diretto al thread perché è stato generato come conseguenza dell'esecuzione di una istruzione specifica in linguaggio macchina che ha provocato un'eccezione hardware (per esempio, SIGSEGV per un accesso in memoria non valido, o SIGFPE per un'operazione aritmetica erronea), o perché è stato indirizzato a uno specifico thread usando interfacce come tgkill(2) o pthread_kill(3).
Un segnale diretto al processo può essere recapitato a uno qualunque dei thread che attualmente non hanno il segnale bloccato. Se più di uno dei thread ha il segnale sbloccato, allora il kernel sceglie un thread arbitrario a cui recapitare il segnale.
Un thread può ottenere l'insieme di segnali che attualmente ha pendenti usando sigpending(2). Questo insieme consisterà nell'unione dell'insieme dei segnali diretti ai processi pendenti e l'insieme di segnali pendenti per il thread chiamante.
L'insieme di segnali pendenti di un processo figlio creato tramite fork(2) inizialmente è vuoto: l'insieme di segnali pendenti è preservato attraverso execve(2).
Whenever there is a transition from kernel-mode to user-mode execution (e.g., on return from a system call or scheduling of a thread onto the CPU), the kernel checks whether there is a pending unblocked signal for which the process has established a signal handler. If there is such a pending signal, the following steps occur:
Note that if the signal handler does not return (e.g., control is transferred out of the handler using siglongjmp(3), or the handler executes a new program with execve(2)), then the final step is not performed. In particular, in such scenarios it is the programmer's responsibility to restore the state of the signal mask (using sigprocmask(2)), if it is desired to unblock the signals that were blocked on entry to the signal handler. (Note that siglongjmp(3) may or may not restore the signal mask, depending on the savesigs value that was specified in the corresponding call to sigsetjmp(3).)
From the kernel's point of view, execution of the signal handler code is exactly the same as the execution of any other user-space code. That is to say, the kernel does not record any special state information indicating that the thread is currently excuting inside a signal handler. All necessary state information is maintained in user-space registers and the user-space stack. The depth to which nested signal handlers may be invoked is thus limited only by the user-space stack (and sensible software design!).
Linux supporta i segnali standard elencati di seguito. La seconda colonna della tabella indica quale standard ha descritto il segnale: "P1990" indica che il segnale è descritto nello standard POSIX.1-1990 originale; "P2001" indica che il segnale è stato aggiunto in SUSv2 e POSIX.1-2001.
Segnale | Standard | Azione | Commento |
SIGABRT | P1990 | Core | Segnale di interruzione anomala da abort(3) |
SIGALRM | P1990 | Term | Segnale del timer tempo da alarm(2) |
SIGBUS | P2001 | Core | Errore sul bus (accesso errato alla memoria) |
SIGCHLD | P1990 | Ign | Processo figlio terminato o fermato |
SIGCLD | - | Ign | Un sinonimo di SIGCHLD |
SIGCONT | P1990 | Cont | Il processo può continuare, se era stato fermato. |
SIGEMT | - | Term | Emulatore di trap |
SIGFPE | P1990 | Core | Eccezione in un numero in virgola mobile |
SIGHUP | P1990 | Term | La linea sul terminale che ha il controllo è stata |
agganciata o il processo che ha il controllo è morto | |||
SIGILL | P1990 | Core | Istruzione illegale |
SIGINFO | - | Un sinonimo di SIGPWR | |
SIGINT | P1990 | Term | Interruzione da tastiera |
SIGIO | - | Term | I/O ora possibile (4.2BSD) |
SIGIOT | - | Core | Trappola IOT. Sinonimo di SIGABRT |
SIGKILL | P1990 | Term | Termina il processo |
SIGLOST | - | Term | Perso il lock del file (non usato) |
SIGPIPE | P1990 | Term | Pipe rotta: scrittura su una pipe priva di |
lettori; vedi pipe(7) | |||
SIGPOLL | P2001 | Term | Evento suscettibile di polling (Sys V); |
Sinonimo di SIGIO | |||
SIGPROF | P2001 | Term | Timer del profiler scaduto |
SIGPWR | - | Term | Mancanza di corrente (System V) |
SIGQUIT | P1990 | Core | Segnale d'uscita della tastiera |
SIGSEGV | P1990 | Core | Riferimento di memoria non valido |
SIGSTKFLT | - | Term | Errore dello stack del coprocessore (inutilizzato) |
SIGSTOP | P1990 | Stop | Ferma il processo |
SIGTSTP | P1990 | Stop | Stop digitato dal terminale |
SIGSYS | P2001 | Core | Chiamata di sistema errata (SVr4); |
vedi anche seccomp(2) | |||
SIGTERM | P1990 | Term | Segnale di termine |
SIGTRAP | P2001 | Core | Trappola per trace/breakpoint |
SIGTTIN | P1990 | Stop | Input da terminale per un processo sullo sfondo |
SIGTTOU | P1990 | Stop | Output da terminale per un processo sullo sfondo |
SIGUNUSED | - | Core | Sinonimo di SIGSYS |
SIGURG | P2001 | Ign | Condizione urgente sul socket (4.2BSD) |
SIGUSR1 | P1990 | Term | Segnale 1 definito dall'utente |
SIGUSR2 | P1990 | Term | Segnale 2 definito dall'utente |
SIGVTALRM | P2001 | Term | Allarme virtuale (4.2BSD) |
SIGXCPU | P2001 | Core | Superato tempo limite di CPU (4.2BSD); |
vedi anche setrlimit(2) | |||
SIGXFSZ | P2001 | Core | Limite dimensione file superato (4.2BSD); |
vedi anche setrlimit(2) | |||
SIGWINCH | - | Ign | Dimensioni finestra cambiate (4.3BSD, Sun) |
I segnali SIGKILL e SIGSTOP non possono essere intercettati, bloccati o ignorati.
Fino a Linux 2.2 incluso, il comportamento predefinito per SIGSYS, SIGXCPU, SIGXFSZ, e (su architetture diverse da SPARC e MIPS) SIGBUS era terminare il processo (senza eseguire un core dump). (In alcuni altri sistemi UNIX l'azione predefinita per SIGXCPU e SIGXFSZ è terminare il processo senza eseguire un core dump.) Linux 2.4 è conforme ai requisiti di POSIX.1-2001 per questi segnali, terminando il processo con un core dump.
SIGEMT non è specificato in POSIX.1-2001, tuttavia appare in molti altri sistemi UNIX, dove la sua azione predefinita è tipicamente di terminare il processo con un core dump.
SIGPWR (non specificato in POSIX.1-2001) è tipicamente ignorato in via predefinita in questi altri UNIX dove appare.
SIGIO (non specificato in POSIX.1-2001) è ignorato in via predefinita in molti altri sistemi UNIX.
Se ci sono più segnali pendenti per un medesimo processo, l'ordine in cui i segnali vengono recapitati non è specificato.
I segnali standard non vengono accodati. Se vengono generate istanze multiple di un segnale standard mentre quel segnale è bloccato, solo un'istanza del segnale viene marcata come pendente (e il segnale verrà recapitato non appena verrà sbloccato). Nel caso in cui un segnale standard sia già pendente, la struttura siginfo_t (si veda sigaction(2)) associata con quel segnale non viene sovrascritta all'arrivo di successive istanze dello stesso segnale. Quindi, il processo riceverà l'informazione associata alla prima istanza del segnale.
Il valore numerico di ogni segnale è indicato nella tabella seguente. Come mostrato nella tabella, molti segnallii hanno valori numerici diversi su architetture diverse. Il primo argomento numerico in ogni riga della tabella mostra il numero di segnale su x86, ARM, e molte altre architteture; il secondo valore è per Alpha e SPARC; il terzo è per MIPS; e l'ultimo è per PARISC. Un trattino (-) indica che un segnale è assente nell'architettura corrispondente.
Segnale | x86/ARM | Alpha/ | MIPS | PARISC | Note |
molti altri | SPARC | ||||
SIGHUP | 1 | 1 | 1 | 1 | |
SIGINT | 2 | 2 | 2 | 2 | |
SIGQUIT | 3 | 3 | 3 | 3 | |
SIGILL | 4 | 4 | 4 | 4 | |
SIGTRAP | 5 | 5 | 5 | 5 | |
SIGABRT | 6 | 6 | 6 | 6 | |
SIGIOT | 6 | 6 | 6 | 6 | |
SIGBUS | 7 | 10 | 10 | 10 | |
SIGEMT | - | 7 | 7 | - | |
SIGFPE | 8 | 8 | 8 | 8 | |
SIGKILL | 9 | 9 | 9 | 9 | |
SIGUSR1 | 10 | 30 | 16 | 16 | |
SIGSEGV | 11 | 11 | 11 | 11 | |
SIGUSR2 | 12 | 31 | 17 | 17 | |
SIGPIPE | 13 | 13 | 13 | 13 | |
SIGALRM | 14 | 14 | 14 | 14 | |
SIGTERM | 15 | 15 | 15 | 15 | |
SIGSTKFLT | 16 | - | - | 7 | |
SIGCHLD | 17 | 20 | 18 | 18 | |
SIGCLD | - | - | 18 | - | |
SIGCONT | 18 | 19 | 25 | 26 | |
SIGSTOP | 19 | 17 | 23 | 24 | |
SIGTSTP | 20 | 18 | 24 | 25 | |
SIGTTIN | 21 | 21 | 26 | 27 | |
SIGTTOU | 22 | 22 | 27 | 28 | |
SIGURG | 23 | 16 | 21 | 29 | |
SIGXCPU | 24 | 24 | 30 | 12 | |
SIGXFSZ | 25 | 25 | 31 | 30 | |
SIGVTALRM | 26 | 26 | 28 | 20 | |
SIGPROF | 27 | 27 | 29 | 21 | |
SIGWINCH | 28 | 28 | 20 | 23 | |
SIGIO | 29 | 23 | 22 | 22 | |
SIGPOLL | Lo stesso di SIGIO | ||||
SIGPWR | 30 | 29/- | 19 | 19 | |
SIGINFO | - | 29/- | - | - | |
SIGLOST | - | -/29 | - | - | |
SIGSYS | 31 | 12 | 12 | 31 | |
SIGUNUSED | 31 | - | - | 31 |
Si noti quanto segue:
A partire dalla versione 2.2, Linux supporta i segnali real-time come originariamente definiti nelle estensioni real-time di POSIX.1b (e ora incluse in POSIX.1-2001). L'intervallo di segnali real-time supportati è definito dalle macro SIGRTMIN e SIGRTMAX. POSIX.1-2001 richiede che un'implementazione supporti almeno i segnali real-time _POSIX_RTSIG_MAX(8).
Il kernel Linux supporta un intervallo di 33 diversi segnali real-time, numerati da 32 a 64. Comunque, l'implementazione di glibc POSIX dei thread usa internamente due (per NTPL) o tre (per LinuxThreads) segnali real-time (vedere pthreads(7)), e sistema il valore di SIGRTMIN in modo adatto (a 34 o 35). Dato che l'intervallo di segnali real-time disponibili varia a seconda dell'implementazione dei thread di glibc (e questa variazione può avvenire al run-time in accordo con kernel e glibc disponibili), e poiché l'intervallo dei segnali real-time varia tra i vari sistemi UNIX, i programmi non dovrebbero mai riferirsi ai segnali real-time usando numeri prefissati. Dovrebbero invece sempre fare riferimento ai segnali real-time usando la notazione SIGRTMIN+n, e includere controlli adatti (run-time) perché SIGRTMIN+n non ecceda SIGRTMAX.
Diversamente dai segnali standard, i segnali real-time non hanno significati predefiniti: l'intero insieme dei segnali real-time può essere usato per scopi definiti dall'applicazione.
L'azione predefinita per i segnali real-time non gestiti è di terminare il processo ricevente.
I segnali real-time si distinguono da quanto segue:
Se sia i segnali standard che quelli real-time sono pendenti per un processo, POSIX non specifica quale consegnare per primo. Linux, come molte altre implementazioni, in questo caso dà priorità ai segnali predefiniti.
Conformemente a POSIX, un'implementazione deve permettere che almeno (32) segnali real-time _POSIX_SIGQUEUE_MAX vengano accodati a un processo. Tuttavia Linux fa le cose diversamente. Nei kernel fino a e incluso il 2.6.7, Linux impone un limite globale al numero di segnali real-time accodati per tutti i processi. Questo limite può essere visto e cambiato (con privilegi) attraverso il file /proc/sys/kernel/rtsig-max. Un file correlato, /proc/sys/kernel/rtsig-nr, può essere usato per trovare quanti segnali real-time sono attualmente accodati. In Linux 2.6.8, queste interfacce /proc sono sostituite dal limite di risorsa RLIMIT_SIGPENDING che specifica un limite per utente per i segnali accodati. Vedere setrlimit(2) per ulteriori dettagli.
L'aggiunta di segnali real-time ha richiesto l'estensione della struttura del set di segnali (sigset_t) da 32 a 64 bit. Di conseguenza, diverse chiamate di sistema erano superate da nuove chiamate di sistema che supportavano il set di segnali più ampio. Le vecchie e le nuove chiamate di sistema sono appresso elencate:
Linux 2.0 e precedenti | Linux 2.2 e successivi |
sigaction(2) | rt_sigaction(2) |
sigpending(2) | rt_sigpending(2) |
sigprocmask(2) | rt_sigprocmask(2) |
sigreturn(2) | rt_sigreturn(2) |
sigsuspend(2) | rt_sigsuspend(2) |
sigtimedwait(2) | rt_sigtimedwait(2) |
Se viene chiamato un gestore di segnale mentre una chiamata di sistema o una funzione di libreria sono bloccate, può succedere:
Il verificarsi di uno di questi due comportamenti dipende dall'interfaccia e dall'uso o meno del flag SA_RESTART alla creazione del gestore di segnale (vedere sigaction(2)). I dettagli variano tra i sistemi UNIX: seguono quelli per Linux.
Se un gestore di segnale interrompe una chiamata bloccata verso una delle seguenti interfacce, la chiamata viene automaticamente riavviata dopo il ritorno del gestore di segnale, se è stato usato il flag SA_RESTART, altrimenti la chiamata fallisce con l'errore EINTR:
Le seguenti interfacce non vengono mai riavviate dopo l'interruzione da parte di un gestore di segnale, senza curarsi dell'uso di SA_RESTART; falliscono sempre con l'errore EINTR quando vengono interrotte da un gestore di segnale:
La funzione sleep(3) non viene mai riavviata anche quando viene interrotta da un gestore, ma restituisce uno stato di successo: il numero di secondi rimanenti.
Su Linux, anche in assenza di gestori di segnale alcune interfacce di blocco possono fallire con l'errore EINTR dopo che il processo è stato fermato da un segnale di stop, e poi riavviato tramite SIGCONT. Questo comportamento non è sanzionato da POSIX.1, e non avviene su altri sistemi.
Le interfacce Linux che si comportano in questo modo sono:
POSIX.1, tranne dove indicato.
Per una trattazione delle funzioni async-signal-safe, vedi signal-safety(7).
Il file /proc/[pid]/task/[tid]/status contiene deversi campi che mostrano i segnali che un thread sta bloccando (SigBlk), intercettando (SigCgt), o ignorando (SigIgn). (La serie di segnali che sono intercettati o ignorati saràà la stessa in tutti i thread in un processo.) Altri campi mostrano la serie di segnali pendenti che sono diretti al thread (SigPnd) e anche la serie di segnali pendenti che sono diretti al processo nella sua interezza (ShdPnd). I campi corrispondenti in /proc/[pid]/status mostrale le informazioni per il thread principale. Si veda proc(5) per ulteriori dettagli.
Ci sono sei segnali che possono essere recapitati come conseguenza di un'eccezione hardware: SIGBUS, SIGEMT, SIGFPE, SIGILL, SIGSEGV e SIGTRAP. Quale di questi segnali viene recapitato per ogni determinata eccezione hardware non è documentato, e non sempre ha senso farlo.
Per esempio, un accesso alla memoria non valido che causa il recapito di SIGSEGV su un'architettura CPU può causare il recapito di SIGBUS su un'altra srchitettura, o vice versa.
Un altro esempio: usando l'istruzione x86 int con un argomento vietato (qualsiasi numero che non sia 3 o 128) provoca il recapito di SIGSEGV, anche se SIGILL sarebbe più indicato, per come la CPU riferisce l'operazione vietata al kernel.
kill(1), clone(2), getrlimit(2), kill(2), pidfd_send_signal(2), restart_syscall(2), rt_sigqueueinfo(2), setitimer(2), setrlimit(2), sgetmask(2), sigaction(2), sigaltstack(2), signal(2), signalfd(2), sigpending(2), sigprocmask(2), sigreturn(2), sigsuspend(2), sigwaitinfo(2), abort(3), bsd_signal(3), killpg(3), longjmp(3), pthread_sigqueue(3), raise(3), sigqueue(3), sigset(3), sigsetops(3), sigvec(3), sigwait(3), strsignal(3), swapcontext(3), sysv_signal(3), core(5), proc(5), nptl(7), pthreads(7), sigevent(7)
Questa pagina fa parte del rilascio 5.10 del progetto Linux man-pages. Una descrizione del progetto, le istruzioni per la segnalazione degli errori, e l'ultima versione di questa pagina si trovano su https://www.kernel.org/doc/man-pages/.
La traduzione italiana di questa pagina di manuale è stata creata da Ottavio G. Rizzo <rizzo@pluto.linux.it>, Giulio Daprelà <giulio@pluto.it>, Elisabetta Galli <lab@kkk.it> e Marco Curreli <marcocurreli@tiscali.it>
Questa traduzione è documentazione libera; leggere la GNU General Public License Versione 3 o successiva per le condizioni di copyright. Non ci assumiamo alcuna responsabilità.
Per segnalare errori nella traduzione di questa pagina di manuale inviare un messaggio a pluto-ildp@lists.pluto.it.
21 dicembre 2020 | Linux |