Provided by: manpages-it_4.15.0-9_all 
NOME
signal - panoramica sui segnali
DESCRIZIONE
Linux supporta sia i segnali POSIX affidabili (d'ora in avanti "segnali standard") che i
segnali real-time POSIX.
Disposizioni dei segnali
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:
Term L'azione predefinita è terminare il processo.
Ign L'azione predefinita è ignorare il segnale.
Core L'azione predefinita è terminare il processo ed eseguire un core dump (vedere
core(5)).
Stop L'azione predefinita è arrestare il processo.
Cont L'azione predefinita è far continuare il processo se esso è attualmente fermo.
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'è.
Inviare un segnale
Le seguenti chiamate di sistema e funzioni di libreria permettonoal chiamante di inviare
un segnale:
raise(3)
Invia un segnale al thread chiamante.
kill(2)
invia un segnale al processo specificato, a tutti i membri del processo di gruppo
specificato o a tutti i processi nel sistema.
pidfd_send_signal(2)
Invia un segnale a un processo identificato da un descrittore di file di PID.
killpg(3)
Invia un segnale a tutti i membri del processo di gruppo specificato.
pthread_kill(3)
Invia un segnale al thread POSIX specificato nello stesso processo del chiamante.
tgkill(2)
Invia un segnale ad un processo specificato all'interno di un processo ben preciso
(è la chiamata di sistema usata per implementare pthread_kill(3)).
sigqueue(3)
Invia un segnale real-time insieme a dati di accompagnamento al processo
specificato.
Attendere che un segnale venga intercettato
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):
pause(2)
Sospende l'esecuzione finché non viene intercettato un segnale qualunque.
sigsuspend(2)
Cambia temporaneamente la maschera del segnale (vedere sotto) e sospende
l'esecuzione finché viene intercettato uno dei segnali senza maschera.
Accettare in modo sincrono un segnale
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:
* sigwaitinfo(2), sigtimedwait(2) e sigwait(3) sospendono l'esecuzione finché viene
consegnato uno dei segnali contenuti in un insieme specifico. Ognuna di queste chiamate
restituisce informazioni sul segnale consegnato.
* signalfd(2) restituisce un descrittore di file che può essere usato per leggere
informazioni sui segnali consegnati al chiamante. Ogni read(2) da questo descrittore di
file blocca il chiamante finché uno dei segnali nell'insieme specificato dalla chiamata
signalfd(2) viene consegnato al chiamante stesso. Il buffer restituito da read(2)
contiene una struttura che descrive il segnale.
Maschera segnale e segnali pendenti
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).
Esecuzione dei gestori di segnale
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:
1. Il kernel effettua necessari passi preliminari per l'esecuzione del gestore di segnale:
a) Il segnale è rimosso dal'insieme dei segnali pendenti.
b) If the signal handler was installed by a call to sigaction(2) that specified the
SA_ONSTACK flag and the thread has defined an alternate signal stack (using
sigaltstack(2)), then that stack is installed.
c) Various pieces of signal-related context are saved into a special frame that is
created on the stack. The saved information includes:
+ the program counter register (i.e., the address of the next instruction in the
main program that should be executed when the signal handler returns);
+ architecture-specific register state required for resuming the interrupted
program;
+ La maschera di segnale corrente del thread;
+ Le impostazioni dello stack del segnale alternativo del thread.
(If the signal handler was installed using the sigaction(2) SA_SIGINFO flag, then
the above information is accessible via the ucontext_t object that is pointed to by
the third argument of the signal handler.)
d) Any signals specified in act->sa_mask when registering the handler with
sigprocmask(2) are added to the thread's signal mask. The signal being delivered
is also added to the signal mask, unless SA_NODEFER was specified when registering
the handler. These signals are thus blocked while the handler executes.
2. The kernel constructs a frame for the signal handler on the stack. The kernel sets the
program counter for the thread to point to the first instruction of the signal handler
function, and configures the return address for that function to point to a piece of
user-space code known as the signal trampoline (described in sigreturn(2)).
3. The kernel passes control back to user-space, where execution commences at the start of
the signal handler function.
4. When the signal handler returns, control passes to the signal trampoline code.
5. The signal trampoline calls sigreturn(2), a system call that uses the information in
the stack frame created in step 1 to restore the thread to its state before the signal
handler was called. The thread's signal mask and alternate signal stack settings are
restored as part of this procedure. Upon completion of the call to sigreturn(2), the
kernel transfers control back to user space, and the thread recommences execution at
the point where it was interrupted by the signal handler.
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 executing 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!).
Segnali standard
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.
Semantica di accodamento e recapito per i segnali standard
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.
Numerazione dei segnali per i segnali standard
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:
* Dove definito, SIGUNUSED è sinonimo di SIGSYS. Da glibc 2.26, SIGUNUSED non è più
definito su nessuna architettura.
* Il segnale 29 è SIGINFO/SIGPWR (synonimi per lo stesso valore) su Alpha ma SIGLOST su
SPARC.
Segnali real-time
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:
1. Istanze multiple di segnali real-time possono essere accodate. Viceversa, se istanze
multiple di un segnale predefinito sono consegnate mentre questo segnale è bloccato,
allora viene accodata solo un'istanza.
2. Se il segnale è inviato usando sigqueue(3), un valore di accompagnamento (che sia un
intero o un puntatore) può essere inviato con il segnale. Se il processo ricevente
stabilisce un gestore per questo segnale usando il flag SA_SIGINFO a sigaction(2)
allora esso può ottenere questo dato attraverso il campo si_value della struttura
siginfo_t passata come secondo argomento al gestore. Inoltre i campi si_pid e si_uid
di questa struttura possono essere usati per ottenere PID e ID di un utente reale del
processo che invia il segnale.
3. I segnali real-time sono recapitati in un ordine garantito. I segnali real-time
multipli dello stesso tipo sono recapitati nell'ordine in cui vengono inviati. Se
segnali real-time diversi sono inviati ad un processo, essi sono consegnati partendo
dal segnale con il numero più basso (cioè i segnali con i numeri bassi hanno la
priorità maggiore). Al contrario, se segnali standard multipli sono pendenti per un
processo, essi verranno recapitati in un ordine non specificato.
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)
Interruzione delle chiamate di sistema e funzioni di libreria da parte di gestori di segnale
Se viene chiamato un gestore di segnale mentre una chiamata di sistema o una funzione di
libreria sono bloccate, può succedere:
* che la chiamata venga automaticamente riavviata dopo il ritorno del gestore di segnale;
o
* che la chiamata fallisca con l'errore EINTR.
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:
* chiamate read(2), readv(2), write(2), writev(2) e ioctl(2) su dispositivi "lenti". Un
dispositivo è "lento" quando le chiamate I/O possono bloccarsi per un tempo
indeterminato, per esempio un terminale, una pipe o un socket Se una chiamata I/O su un
dispositivo lento ha già trasferito alcuni dati al momento dell'interruzione da parte
del gestore di segnale, la chiamata restituirà uno stato di successo (di solito il
numero di byte trasferiti). Da notare che un disco (locale) non è un dispositivo lento,
stando a quanto dice la sua definizione. Le operazioni I/O sui dischi non vengono
interrotte dai segnali.
* open(2), se si può bloccare (per esempio nell'aprire un FIFO: vedere fifo(7)).
* wait(2), wait3(2), wait4(2), waitid(2) e waitpid(2).
* Interfacce socket: accept(2), connect(2), recv(2), recvfrom(2), recvmmsg(2), recvmsg(2),
send(2), sendto(2) e sendmsg(2), a meno che venga impostato un timeout sul socket
(vedere sotto).
* Interfacce che bloccano i file: flock(2) e le operazioni F_SETLKW e F_OFD_SETLKW di
fcntl(2)
* Interfacce per messaggi POSIX in coda: mq_receive(3), mq_timedreceive(3), mq_send(3) e
mq_timedsend(3).
* futex(2) FUTEX_WAIT (a partire da Linux 2.6.22; prima falliva sempre con EINTR).
* getrandom(2).
* pthread_mutex_lock(3), pthread_cond_wait(3), e con le relative API.
* futex(2) FUTEX_WAIT_BITSET.
* Interfacce semaforo POSIX: sem_wait(3) e sem_timedwait(3) (a partire da Linux 2.6.22;
prima falliva sempre con EINTR).
* read(2) da un descrittore di file inotify(7) (da Linux 3.8; prima, falliva sempre con
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:
* Interfacce socket in "input", quando è stato impostato un timeout (SO_RCVTIMEO) sul
socket usando setsockopt(2): accept(2), recv(2), recvfrom(2), recvmmsg(2) (anche con un
argomento timeout non NULLO) e recvmsg(2).
* Interfacce socket in "output", quando è stato impostato un timeout (SO_RCVTIMEO) sul
socket usando setsockopt(2): connect(2), send(2), sendto(2) e sendmsg(2).
* Interfacce usate per aspettare segnali: pause(2), sigsuspend(2), sigtimedwait(2) e
sigwaitinfo(2).
* Interfacce condivise per descrittori di file: epoll_wait(2), epoll_pwait(2), poll(2),
ppoll(2), select(2) e pselect(2).
* Interfacce IPV System V: msgrcv(2), msgsnd(2), semop(2) e semtimedop(2).
* Interfacce sleep: clock_nanosleep(2), nanosleep(2) e usleep(3).
* io_getevents(2).
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.
In certain circumstances, the seccomp(2) user-space notification feature can lead to
restarting of system calls that would otherwise never be restarted by SA_RESTART; for
details, see seccomp_unotify(2).
Interruzione di chiamate di sistema e funzioni di libreria da parte di segnali di stop
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:
* Interfacce socket in "input", quando è stato impostato un timeout (SO_RCVTIMEO) sul
socket usando setsockopt(2): accept(2), recv(2), recvfrom(2), recvmmsg(2) (anche con un
argomento timeout non NULLO) e recvmsg(2).
* Interfacce socket in "input", quando è stato impostato un timeout (SO_RCVTIMEO) sul
socket usando setsockopt(2): accept(2), recv(2), recvfrom(2), recvmmsg(2) (anche con un
argomento timeout non NULL), e recvmsg(2).
* epoll_wait(2), epoll_pwait(2).
* semop(2), semtimedop(2).
* sigtimedwait(2), sigwaitinfo(2).
* Linux 3.7 e precedenti: read(2) da un descrittore di file inotify(7)
* Linux 2.6.21 e precedenti: futex(2) FUTEX_WAIT, sem_timedwait(3), sem_wait(3).
* Linux 2.6.8 e precedenti: msgrcv(2), msgsnd(2).
* Linux 2.4 e precedenti: nanosleep(2).
CONFORME A
POSIX.1, tranne dove indicato.
NOTE
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.
BUG
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.
VEDERE ANCHE
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)
COLOPHON
Questa pagina fa parte del rilascio 5.13 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/.
TRADUZIONE
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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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⟩.