.\" -*- coding: UTF-8 -*- .\" Copyright (c) 1993 by Thomas Koenig (ig25@rz.uni-karlsruhe.de) .\" and Copyright (c) 2002, 2006, 2020 by Michael Kerrisk .\" and Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk .\" .\" .\" %%%LICENSE_START(VERBATIM) .\" Permission is granted to make and distribute verbatim copies of this .\" manual provided the copyright notice and this permission notice are .\" preserved on all copies. .\" .\" Permission is granted to copy and distribute modified versions of this .\" manual under the conditions for verbatim copying, provided that the .\" entire resulting derived work is distributed under the terms of a .\" permission notice identical to this one. .\" .\" Since the Linux kernel and libraries are constantly changing, this .\" manual page may be incorrect or out-of-date. The author(s) assume no .\" responsibility for errors or omissions, or for damages resulting from .\" the use of the information contained herein. The author(s) may not .\" have taken the same level of care in the production of this manual, .\" which is licensed free of charge, as they might when working .\" professionally. .\" .\" Formatted or processed versions of this manual, if unaccompanied by .\" the source, must acknowledge the copyright and authors of this work. .\" %%%LICENSE_END .\" .\" Modified Sat Jul 24 17:34:08 1993 by Rik Faith (faith@cs.unc.edu) .\" Modified Sun Jan 7 01:41:27 1996 by Andries Brouwer (aeb@cwi.nl) .\" Modified Sun Apr 14 12:02:29 1996 by Andries Brouwer (aeb@cwi.nl) .\" Modified Sat Nov 13 16:28:23 1999 by Andries Brouwer (aeb@cwi.nl) .\" Modified 10 Apr 2002, by Michael Kerrisk .\" Modified 7 Jun 2002, by Michael Kerrisk .\" Added information on real-time signals .\" Modified 13 Jun 2002, by Michael Kerrisk .\" Noted that SIGSTKFLT is in fact unused .\" 2004-12-03, Modified mtk, added notes on RLIMIT_SIGPENDING .\" 2006-04-24, mtk, Added text on changing signal dispositions, .\" signal mask, and pending signals. .\" 2008-07-04, mtk: .\" Added section on system call restarting (SA_RESTART) .\" Added section on stop/cont signals interrupting syscalls. .\" 2008-10-05, mtk: various additions .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH SIGNAL 7 "21 dicembre 2020" Linux "Manuale del programmatore di Linux" .SH NOME signal \- panoramica sui segnali .SH DESCRIZIONE Linux supporta sia i segnali POSIX affidabili (d'ora in avanti "segnali standard") che i segnali real\-time POSIX. .SS "Disposizioni dei segnali" Ciascun segnale ha una \fIdisposizione\fP attuale, che determina come si comporta il processo quando il segnale viene recapitato. .PP Le voci nella colonna "Action" della tabella qui sotto specificanola disposizione predefinita di ogni segnale, come segue: .IP Term L'azione predefinita è terminare il processo. .IP Ign L'azione predefinita è ignorare il segnale. .IP Core L'azione predefinita è terminare il processo ed eseguire un core dump (vedere \fBcore\fP(5)). .IP Stop L'azione predefinita è arrestare il processo. .IP Cont L'azione predefinita è far continuare il processo se esso è attualmente fermo. .PP Un processo può cambiare la disposizione di un segnale usando \fBsigaction\fP(2) o \fBsignal\fP(2) (L'ultimo è meno portabile quando si crea un gestore di segnale; si veda \fBsignal\fP(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 \fIgestore di segnale\fP, una funzione definita dal programmatore che è automaticamente invocata quando il segnale è recapitato. .PP 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 \fBsigaltstack\fP(2) per una spiegazione su come farlo e quando può essere utile. .PP La disposizione del segnale è un attributo per processo: in un'applicazione multithread, la disposizione di un particolare segnale è la stessa per tutti i thread. .PP Un processo figlio creato tramite \fBfork\fP(2) eredita una copia della disposizione dei segnali del genitore. Durante un \fBexecve\fP(2), la disposizione dei segnali gestiti viene inizializzata ai valori predefiniti; la disposizione dei segnali ignorati viene lasciata com'è. .SS "Inviare un segnale" Le seguenti chiamate di sistema e funzioni di libreria permettonoal chiamante di inviare un segnale: .TP \fBraise\fP(3) Invia un segnale al thread chiamante. .TP \fBkill\fP(2) invia un segnale al processo specificato, a tutti i membri del processo di gruppo specificato o a tutti i processi nel sistema. .TP \fBpidfd_send_signal\fP(2) Invia un segnale a un processo identificato da un descrittore di file di PID. .TP \fBkillpg\fP(3) Invia un segnale a tutti i membri del processo di gruppo specificato. .TP \fBpthread_kill\fP(3) Invia un segnale al thread POSIX specificato nello stesso processo del chiamante. .TP \fBtgkill\fP(2) Invia un segnale ad un processo specificato all'interno di un processo ben preciso (è la chiamata di sistema usata per implementare \fBpthread_kill\fP(3)). .TP \fBsigqueue\fP(3) Invia un segnale real\-time insieme a dati di accompagnamento al processo specificato. .SS "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): .TP \fBpause\fP(2) Sospende l'esecuzione finché non viene intercettato un segnale qualunque. .TP \fBsigsuspend\fP(2) .\" Cambia temporaneamente la maschera del segnale (vedere sotto) e sospende l'esecuzione finché viene intercettato uno dei segnali senza maschera. .SS "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: .IP * 2 \fBsigwaitinfo\fP(2), \fBsigtimedwait\fP(2) e \fBsigwait\fP(3) sospendono l'esecuzione finché viene consegnato uno dei segnali contenuti in un insieme specifico. Ognuna di queste chiamate restituisce informazioni sul segnale consegnato. .IP * \fBsignalfd\fP(2) restituisce un descrittore di file che può essere usato per leggere informazioni sui segnali consegnati al chiamante. Ogni \fBread\fP(2) da questo descrittore di file blocca il chiamante finché uno dei segnali nell'insieme specificato dalla chiamata \fBsignalfd\fP(2) viene consegnato al chiamante stesso. Il buffer restituito da \fBread\fP(2) contiene una struttura che descrive il segnale. .SS "Maschera segnale e segnali pendenti" Un segnale può essere \fIbloccato\fP, cioé non verrà recapitato fino a quando non verrà sbloccato. Un segnale viene definito \fIpendente\fP nel periodo di tempo che passa tra quando è stato generato e quando è recapitato. .PP Ciascun thread in un processo ha una \fImaschera segnale\fP indipendente, che indica l'insieme di segnali che il thread attualmente sta bloccando. Un thread può manipolare la sua maschera segnale usando \fBpthread_sigmask\fP(3). In un'applicazione tradizionale a thread singolo, si può usare \fBsigprocmask\fP(2) per manipolare la maschera segnale. .PP Un processo figlio creato tramite \fBfork\fP(2) eredita una copia della maschera di segnale del processo genitore: la maschera di segnale viene preservata attraverso \fBexecve\fP(2). .PP 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 \fBkill\fP(2) o \fBsigqueue\fP(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, \fBSIGSEGV\fP per un accesso in memoria non valido, o \fBSIGFPE\fP per un'operazione aritmetica erronea), o perché è stato indirizzato a uno specifico thread usando interfacce come \fBtgkill\fP(2) o \fBpthread_kill\fP(3). .PP .\" Joseph C. Sible notes: .\" On Linux, if the main thread has the signal unblocked, then the kernel .\" will always deliver the signal there, citing this kernel code .\" .\" Per this comment in kernel/signal.c since time immemorial: .\" .\" /* .\" * Now find a thread we can wake up to take the signal off the queue. .\" * .\" * If the main thread wants the signal, it gets first crack. .\" * Probably the least surprising to the average bear. .\" */ .\" .\" But this does not mean the signal will be delivered only in the .\" main thread, since if a handler is already executing in the main thread .\" (and thus the signal is blocked in that thread), then a further .\" might be delivered in a different thread. .\" 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. .PP Un thread può ottenere l'insieme di segnali che attualmente ha pendenti usando \fBsigpending\fP(2). Questo insieme consisterà nell'unione dell'insieme dei segnali diretti ai processi pendenti e l'insieme di segnali pendenti per il thread chiamante. .PP .\" L'insieme di segnali pendenti di un processo figlio creato tramite \fBfork\fP(2) inizialmente è vuoto: l'insieme di segnali pendenti è preservato attraverso \fBexecve\fP(2). .SS "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: .IP 1. 3 Il kernel effettua necessari passi preliminari per l'esecuzione del gestore di segnale: .RS .IP a) 3 Il segnale è rimosso dal'insieme dei segnali pendenti. .IP b) If the signal handler was installed by a call to \fBsigaction\fP(2) that specified the \fBSA_ONSTACK\fP flag and the thread has defined an alternate signal stack (using \fBsigaltstack\fP(2)), then that stack is installed. .IP c) Various pieces of signal\-related context are saved into a special frame that is created on the stack. The saved information includes: .RS .IP + 2 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); .IP + architecture\-specific register state required for resuming the interrupted program; .IP + La maschera di segnale corrente del thread; .IP + Le impostazioni dello stack del segnale alternativo del thread. .RE .IP (If the signal handler was installed using the \fBsigaction\fP(2) \fBSA_SIGINFO\fP flag, then the above information is accessible via the \fIucontext_t\fP object that is pointed to by the third argument of the signal handler.) .IP d) Any signals specified in \fIact\->sa_mask\fP when registering the handler with \fBsigprocmask\fP(2) are added to the thread's signal mask. The signal being delivered is also added to the signal mask, unless \fBSA_NODEFER\fP was specified when registering the handler. These signals are thus blocked while the handler executes. .RE .IP 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 \fBsigreturn\fP(2)). .IP 3. The kernel passes control back to user\-space, where execution commences at the start of the signal handler function. .IP 4. When the signal handler returns, control passes to the signal trampoline code. .IP 5. The signal trampoline calls \fBsigreturn\fP(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 \fBsigreturn\fP(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. .PP Note that if the signal handler does not return (e.g., control is transferred out of the handler using \fBsiglongjmp\fP(3), or the handler executes a new program with \fBexecve\fP(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 \fBsigprocmask\fP(2)), if it is desired to unblock the signals that were blocked on entry to the signal handler. (Note that \fBsiglongjmp\fP(3) may or may not restore the signal mask, depending on the \fIsavesigs\fP value that was specified in the corresponding call to \fBsigsetjmp\fP(3).) .PP .\" 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!). .SS "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. .TS l c c l ____ lB c c l. Segnale Standard Azione Commento SIGABRT P1990 Core Segnale di interruzione anomala da \fBabort\fP(3) SIGALRM P1990 Term Segnale del timer tempo da \fBalarm\fP(2) SIGBUS P2001 Core Errore sul bus (accesso errato alla memoria) SIGCHLD P1990 Ign Processo figlio terminato o fermato SIGCLD \- Ign Un sinonimo di \fBSIGCHLD\fP 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 \fBSIGPWR\fP SIGINT P1990 Term Interruzione da tastiera SIGIO \- Term I/O ora possibile (4.2BSD) SIGIOT \- Core Trappola IOT. Sinonimo di \fBSIGABRT\fP 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 \fBpipe\fP(7) SIGPOLL P2001 Term Evento suscettibile di polling (Sys V); Sinonimo di \fBSIGIO\fP 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 \fBseccomp\fP(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 \fBSIGSYS\fP 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 \fBsetrlimit\fP(2) SIGXFSZ P2001 Core Limite dimensione file superato (4.2BSD); vedi anche \fBsetrlimit\fP(2) SIGWINCH \- Ign Dimensioni finestra cambiate (4.3BSD, Sun) .TE .PP I segnali \fBSIGKILL\fP e \fBSIGSTOP\fP non possono essere intercettati, bloccati o ignorati. .PP Fino a Linux 2.2 incluso, il comportamento predefinito per \fBSIGSYS\fP, \fBSIGXCPU\fP, \fBSIGXFSZ\fP, e (su architetture diverse da SPARC e MIPS) \fBSIGBUS\fP era terminare il processo (senza eseguire un core dump). (In alcuni altri sistemi UNIX l'azione predefinita per \fBSIGXCPU\fP e \fBSIGXFSZ\fP è 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. .PP \fBSIGEMT\fP 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. .PP \fBSIGPWR\fP (non specificato in POSIX.1\-2001) è tipicamente ignorato in via predefinita in questi altri UNIX dove appare. .PP .\" \fBSIGIO\fP (non specificato in POSIX.1\-2001) è ignorato in via predefinita in molti altri sistemi UNIX. .SS "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. .PP .\" 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 \fIsiginfo_t\fP (si veda \fBsigaction\fP(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. .SS "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. .TS l c c c c l l c c c c l ______ lB c c c c l. Segnale x86/ARM Alpha/ MIPS PARISC Note molti altri SPARC SIGHUP \01 \01 \01 \01 SIGINT \02 \02 \02 \02 SIGQUIT \03 \03 \03 \03 SIGILL \04 \04 \04 \04 SIGTRAP \05 \05 \05 \05 SIGABRT \06 \06 \06 \06 SIGIOT \06 \06 \06 \06 SIGBUS \07 10 10 10 SIGEMT \- \07 \07 \- SIGFPE \08 \08 \08 \08 SIGKILL \09 \09 \09 \09 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 \- \- \07 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 .TE .PP Si noti quanto segue: .IP * 3 Dove definito, \fBSIGUNUSED\fP è sinonimo di \fBSIGSYS\fP. Da glibc 2.26, \fBSIGUNUSED\fP non è più definito su nessuna architettura. .IP * .\" Il segnale 29 è \fBSIGINFO\fP/\fBSIGPWR\fP (synonimi per lo stesso valore) su Alpha ma \fBSIGLOST\fP su SPARC. .SS "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 \fBSIGRTMIN\fP e \fBSIGRTMAX\fP. POSIX.1\-2001 richiede che un'implementazione supporti almeno i segnali real\-time \fB_POSIX_RTSIG_MAX\fP(8). .PP 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 \fBpthreads\fP(7)), e sistema il valore di \fBSIGRTMIN\fP 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 \fInon dovrebbero mai riferirsi ai segnali real\-time usando numeri prefissati\fP. Dovrebbero invece sempre fare riferimento ai segnali real\-time usando la notazione \fBSIGRTMIN\fP+n, e includere controlli adatti (run\-time) perché \fBSIGRTMIN\fP+n non ecceda \fBSIGRTMAX\fP. .PP 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. .PP L'azione predefinita per i segnali real\-time non gestiti è di terminare il processo ricevente. .PP I segnali real\-time si distinguono da quanto segue: .IP 1. 4 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. .IP 2. 4 Se il segnale è inviato usando \fBsigqueue\fP(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 \fBSA_SIGINFO\fP a \fBsigaction\fP(2) allora esso può ottenere questo dato attraverso il campo \fIsi_value\fP della struttura \fIsiginfo_t\fP passata come secondo argomento al gestore. Inoltre i campi \fIsi_pid\fP e \fIsi_uid\fP di questa struttura possono essere usati per ottenere PID e ID di un utente reale del processo che invia il segnale. .IP 3. 4 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. .PP 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. .PP Conformemente a POSIX, un'implementazione deve permettere che almeno (32) segnali real\-time \fB_POSIX_SIGQUEUE_MAX\fP 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 \fI/proc/sys/kernel/rtsig\-max\fP. Un file correlato, \fI/proc/sys/kernel/rtsig\-nr\fP, può essere usato per trovare quanti segnali real\-time sono attualmente accodati. In Linux 2.6.8, queste interfacce \fI/proc\fP sono sostituite dal limite di risorsa \fBRLIMIT_SIGPENDING\fP che specifica un limite per utente per i segnali accodati. Vedere \fBsetrlimit\fP(2) per ulteriori dettagli. .PP L'aggiunta di segnali real\-time ha richiesto l'estensione della struttura del set di segnali (\fIsigset_t\fP) 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: .TS lb lb l l. Linux 2.0 e precedenti Linux 2.2 e successivi \fBsigaction\fP(2) \fBrt_sigaction\fP(2) \fBsigpending\fP(2) \fBrt_sigpending\fP(2) \fBsigprocmask\fP(2) \fBrt_sigprocmask\fP(2) \fBsigreturn\fP(2) \fBrt_sigreturn\fP(2) \fBsigsuspend\fP(2) \fBrt_sigsuspend\fP(2) \fBsigtimedwait\fP(2) \fBrt_sigtimedwait\fP(2) .TE .\" .SS "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: .IP * 2 che la chiamata venga automaticamente riavviata dopo il ritorno del gestore di segnale; o .IP * che la chiamata fallisca con l'errore \fBEINTR\fP. .PP Il verificarsi di uno di questi due comportamenti dipende dall'interfaccia e dall'uso o meno del flag \fBSA_RESTART\fP alla creazione del gestore di segnale (vedere \fBsigaction\fP(2)). I dettagli variano tra i sistemi UNIX: seguono quelli per Linux. .PP .\" The following system calls use ERESTARTSYS, .\" so that they are restartable 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 \fBSA_RESTART\fP, altrimenti la chiamata fallisce con l'errore \fBEINTR\fP: .IP * 2 chiamate \fBread\fP(2), \fBreadv\fP(2), \fBwrite\fP(2), \fBwritev\fP(2) e \fBioctl\fP(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. .IP * \fBopen\fP(2), se si può bloccare (per esempio nell'aprire un FIFO: vedere \fBfifo\fP(7)). .IP * \fBwait\fP(2), \fBwait3\fP(2), \fBwait4\fP(2), \fBwaitid\fP(2) e \fBwaitpid\fP(2). .IP * .\" If a timeout (setsockopt()) is in effect on the socket, then these .\" system calls switch to using EINTR. Consequently, they and are not .\" automatically restarted, and they show the stop/cont behavior .\" described below. (Verified from 2.6.26 source, and by experiment; mtk) .\" FIXME What about sendmmsg()? Interfacce socket: \fBaccept\fP(2), \fBconnect\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2), \fBrecvmsg\fP(2), \fBsend\fP(2), \fBsendto\fP(2) e \fBsendmsg\fP(2), a meno che venga impostato un timeout sul socket (vedere sotto). .IP * Interfacce che bloccano i file: \fBflock\fP(2) e le operazioni \fBF_SETLKW\fP e \fBF_OFD_SETLKW\fP di \fBfcntl\fP(2) .IP * Interfacce per messaggi POSIX in coda: \fBmq_receive\fP(3), \fBmq_timedreceive\fP(3), \fBmq_send\fP(3) e \fBmq_timedsend\fP(3). .IP * .\" commit 72c1bbf308c75a136803d2d76d0e18258be14c7a \fBfutex\fP(2) \fBFUTEX_WAIT\fP (a partire da Linux 2.6.22; prima falliva sempre con \fBEINTR\fP). .IP * \fBgetrandom\fP(2). .IP * \fBpthread_mutex_lock\fP(3), \fBpthread_cond_wait\fP(3), e con le relative API. .IP * \fBfutex\fP(2) \fBFUTEX_WAIT_BITSET\fP. .IP * .\" as a consequence of the 2.6.22 changes in the futex() implementation Interfacce semaforo POSIX: \fBsem_wait\fP(3) e \fBsem_timedwait\fP(3) (a partire da Linux 2.6.22; prima falliva sempre con \fBEINTR\fP). .IP * .\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06 \fBread\fP(2) da un descrittore di file \fBinotify\fP(7) (da Linux 3.8; prima, falliva sempre con \fBEINTR\fP). .PP .\" These are the system calls that give EINTR or ERESTARTNOHAND .\" on interruption by a signal handler. Le seguenti interfacce non vengono mai riavviate dopo l'interruzione da parte di un gestore di segnale, senza curarsi dell'uso di \fBSA_RESTART\fP; falliscono sempre con l'errore \fBEINTR\fP quando vengono interrotte da un gestore di segnale: .IP * 2 Interfacce socket in "input", quando è stato impostato un timeout (\fBSO_RCVTIMEO\fP) sul socket usando \fBsetsockopt\fP(2): \fBaccept\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2) (anche con un argomento \fItimeout\fP non NULLO) e \fBrecvmsg\fP(2). .IP * .\" FIXME What about sendmmsg()? Interfacce socket in "output", quando è stato impostato un timeout (\fBSO_RCVTIMEO\fP) sul socket usando \fBsetsockopt\fP(2): \fBconnect\fP(2), \fBsend\fP(2), \fBsendto\fP(2) e \fBsendmsg\fP(2). .IP * Interfacce usate per aspettare segnali: \fBpause\fP(2), \fBsigsuspend\fP(2), \fBsigtimedwait\fP(2) e \fBsigwaitinfo\fP(2). .IP * Interfacce condivise per descrittori di file: \fBepoll_wait\fP(2), \fBepoll_pwait\fP(2), \fBpoll\fP(2), \fBppoll\fP(2), \fBselect\fP(2) e \fBpselect\fP(2). .IP * .\" On some other systems, SA_RESTART does restart these system calls Interfacce IPV System V: \fBmsgrcv\fP(2), \fBmsgsnd\fP(2), \fBsemop\fP(2) e \fBsemtimedop\fP(2). .IP * Interfacce sleep: \fBclock_nanosleep\fP(2), \fBnanosleep\fP(2) e \fBusleep\fP(3). .IP * \fBio_getevents\fP(2). .PP La funzione \fBsleep\fP(3) non viene mai riavviata anche quando viene interrotta da un gestore, ma restituisce uno stato di successo: il numero di secondi rimanenti. .SS "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 \fBEINTR\fP dopo che il processo è stato fermato da un segnale di stop, e poi riavviato tramite \fBSIGCONT\fP. Questo comportamento non è sanzionato da POSIX.1, e non avviene su altri sistemi. .PP Le interfacce Linux che si comportano in questo modo sono: .IP * 2 Interfacce socket in "input", quando è stato impostato un timeout (\fBSO_RCVTIMEO\fP) sul socket usando \fBsetsockopt\fP(2): \fBaccept\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2) (anche con un argomento \fItimeout\fP non NULLO) e \fBrecvmsg\fP(2). .IP * .\" FIXME What about sendmmsg()? Interfacce socket in "input", quando è stato impostato un timeout (\fBSO_RCVTIMEO\fP) sul socket usando \fBsetsockopt\fP(2): \fBaccept\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2) (anche con un argomento \fItimeout\fP non NULL), e \fBrecvmsg\fP(2). .IP * 2 \fBepoll_wait\fP(2), \fBepoll_pwait\fP(2). .IP * \fBsemop\fP(2), \fBsemtimedop\fP(2). .IP * \fBsigtimedwait\fP(2), \fBsigwaitinfo\fP(2). .IP * .\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06 Linux 3.7 e precedenti: \fBread\fP(2) da un descrittore di file \fBinotify\fP(7) .IP * Linux 2.6.21 e precedenti: \fBfutex\fP(2) \fBFUTEX_WAIT\fP, \fBsem_timedwait\fP(3), \fBsem_wait\fP(3). .IP * Linux 2.6.8 e precedenti: \fBmsgrcv\fP(2), \fBmsgsnd\fP(2). .IP * Linux 2.4 e precedenti: \fBnanosleep\fP(2). .SH "CONFORME A" POSIX.1, tranne dove indicato. .SH NOTE Per una trattazione delle funzioni async\-signal\-safe, vedi \fBsignal\-safety\fP(7). .PP Il file \fI/proc/[pid]/task/[tid]/status\fP contiene deversi campi che mostrano i segnali che un thread sta bloccando (\fISigBlk\fP), intercettando (\fISigCgt\fP), o ignorando (\fISigIgn\fP). (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 (\fISigPnd\fP) e anche la serie di segnali pendenti che sono diretti al processo nella sua interezza (\fIShdPnd\fP). I campi corrispondenti in \fI/proc/[pid]/status\fP mostrale le informazioni per il thread principale. Si veda \fBproc\fP(5) per ulteriori dettagli. .SH BUG Ci sono sei segnali che possono essere recapitati come conseguenza di un'eccezione hardware: \fBSIGBUS\fP, \fBSIGEMT\fP, \fBSIGFPE\fP, \fBSIGILL\fP, \fBSIGSEGV\fP e \fBSIGTRAP\fP. Quale di questi segnali viene recapitato per ogni determinata eccezione hardware non è documentato, e non sempre ha senso farlo. .PP Per esempio, un accesso alla memoria non valido che causa il recapito di \fBSIGSEGV\fP su un'architettura CPU può causare il recapito di \fBSIGBUS\fP su un'altra srchitettura, o vice versa. .PP Un altro esempio: usando l'istruzione x86 \fIint\fP con un argomento vietato (qualsiasi numero che non sia 3 o 128) provoca il recapito di \fBSIGSEGV\fP, anche se \fBSIGILL\fP sarebbe più indicato, per come la CPU riferisce l'operazione vietata al kernel. .SH "VEDERE ANCHE" \fBkill\fP(1), \fBclone\fP(2), \fBgetrlimit\fP(2), \fBkill\fP(2), \fBpidfd_send_signal\fP(2), \fBrestart_syscall\fP(2), \fBrt_sigqueueinfo\fP(2), \fBsetitimer\fP(2), \fBsetrlimit\fP(2), \fBsgetmask\fP(2), \fBsigaction\fP(2), \fBsigaltstack\fP(2), \fBsignal\fP(2), \fBsignalfd\fP(2), \fBsigpending\fP(2), \fBsigprocmask\fP(2), \fBsigreturn\fP(2), \fBsigsuspend\fP(2), \fBsigwaitinfo\fP(2), \fBabort\fP(3), \fBbsd_signal\fP(3), \fBkillpg\fP(3), \fBlongjmp\fP(3), \fBpthread_sigqueue\fP(3), \fBraise\fP(3), \fBsigqueue\fP(3), \fBsigset\fP(3), \fBsigsetops\fP(3), \fBsigvec\fP(3), \fBsigwait\fP(3), \fBstrsignal\fP(3), \fBswapcontext\fP(3), \fBsysv_signal\fP(3), \fBcore\fP(5), \fBproc\fP(5), \fBnptl\fP(7), \fBpthreads\fP(7), \fBsigevent\fP(7) .SH COLOPHON Questa pagina fa parte del rilascio 5.10 del progetto Linux \fIman\-pages\fP. 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/. .PP .SH TRADUZIONE La traduzione italiana di questa pagina di manuale è stata creata da Ottavio G. Rizzo , Giulio Daprelà , Elisabetta Galli e Marco Curreli . .PP Questa traduzione è documentazione libera; leggere la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Versione 3 .UE o successiva per le condizioni di copyright. Non ci assumiamo alcuna responsabilità. .PP Per segnalare errori nella traduzione di questa pagina di manuale inviare un messaggio a .MT pluto-ildp@lists.pluto.it .ME .