'\" t .\" Copyright (c) 1993 by Thomas Koenig (ig25@rz.uni-karlsruhe.de) .\" and Copyright (c) 2002, 2006 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 .\" .\" Traduzione by Ottavio G. Rizzo (otto@mast.queensu.ca) .\" Luglio 1998 .\" Aggiornamento alla versione 1.27, febbraio 2000 .\" Aggiornamento a man-pages-2.15 di Giulio Daprelà .\" dicembre 2005 .\" Aggiornamento a man-pages-2.31 di Giulio Daprelà - maggio 2006 .\" Aggiornamento a man-pages-2.49 di Giulio Daprelà - giugno 2007 .\" Aggiornamento a man-pages-3.12 di Elisabetta Galli - novembre 2008 .\" Aggiornamento a man-pages-3.53 di Marco Curreli .\" agosto 2013 (formattazione e modifiche minime) .\" Aggiornamento a man-pages-3.72 di Marco Curreli - settembre 2014 .\" .TH SIGNAL 7 2014-06-13 "Linux" "Linux Programmer's Manual" .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 .IR disposizione attuale, che determina come si comporta il processo quando il segnale viene recapitato. Le voci nella colonna "Azione" della tabella qui sotto specificano la 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 .BR core (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 .BR sigaction (2) o .BR signal (2) (l'ultimo è meno portabile quando si crea un gestore di segnale; si veda .BR 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 .IR "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 .BR sigaltstack (2) per una discussione 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 .BR fork (2) eredita una copia della disposizione dei segnali del genitore. Durante un .BR execve (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 permettono al chiamante di inviare un segnale: .TP 16 .BR raise (3) Invia un segnale al thread chiamante. .TP .BR kill (2) invia un segnale al processo specificato, a tutti i membri del processo di gruppo specificato o a tutti i processi nel sistema. .TP .BR killpg (2) Invia un segnale a tutti i membri del processo di gruppo specificato. .TP .BR pthread_kill (3) Invia un segnale al thread POSIX specificato nello stesso processo del chiamante. .TP .BR tgkill (2) Invia un segnale ad un processo specificato all'interno di un processo ben preciso (è la chiamata di sistema usata per implementare .BR pthread_kill (3)). .TP .BR sigqueue (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 processo chiamante o del thread finché non viene intercettato un segnale (o finché un segnale non gestito fa terminare il processo): .TP 16 .BR pause (2) Sospende l'esecuzione finché non viene intercettato un segnale qualunque. .TP .BR sigsuspend (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 .BR sigwaitinfo (2), .BR sigtimedwait (2), e .BR 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. .IP * .BR signalfd (2) restituisce un descrittore di file che può essere usato per leggere informazioni sui segnali consegnati al chiamante. Ogni .BR read (2) da questo descrittore di file blocca il chiamante finché uno dei segnali nell'insieme specificato dalla chiamata .BR signalfd (2) viene consegnato al chiamante stesso. Il buffer restituito da .BR read (2) contiene una struttura che descrive il segnale. .SS Maschera segnale e segnali pendenti Un segnale può essere .IR bloccato , cioé non verrà recapitato fino a quando non verrà sbloccato. Un segnale viene definito .I pendente nel periodo di tempo che passa tra quando è stato generato e quando è recapitato. Ciascun thread in un processo ha una .IR "maschera segnale" indipendente, che indica l'insieme di segnali che il thread attualmente sta bloccando. Un thread può manipolare la sua maschera segnale usando .BR pthread_sigmask (3). In un'applicazione tradizionale a thread singolo, si può usare .BR sigprocmask (2) per manipolare la maschera segnale. Un processo figlio creato tramite .BR fork (2) eredita una copia della maschera di segnale del processo genitore: la maschera di segnale viene preservata attraverso .BR execve (2). Un segnale può essere generato (e quindi pendente) per un processo nel suo insieme (per esempio quando è inviato usando .BR kill (2)) o per uno specifico thread (per esempio certi segnali, come .B SIGSEGV e .BR SIGFPE , generati come conseguenza dell'esecuzione di una istruzione specifica in linguaggio macchina sono diretti al thread, come lo sono i segnali indirizzati a uno specifico thread usando .BR 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 .BR 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 .BR fork (2) inizialmente è vuoto: l'insieme di segnali pendenti è preservato attraverso .BR execve (2). .SS Segnali standard Linux supporta i segnali standard elencati di seguito. Molti numeri di segnale dipendono dall'architettura, come indicato nella colonna "Valore" (dove sono indicati tre valori, il primo è normalmente valido per alpha e sparc, quello in mezzo per x86, arm e la maggior parte delle altre architetture, e l'ultimo per mips (i valori per parisc .I non vengono mostrati; si vedano i sorgenti del kernel Linux per la numerazione dei segnali su questa architettura). A \- denota che un segnale è assente sulla corrispondente architettura). Prima i segnali descritti nello standard POSIX.1\-1990 originale. .TS l c c l ____ lB c c l. Segnale Valore Azione Commento SIGHUP \01 Term La linea sul terminale che ha il controllo è stata agganciata o il processo che ha il controllo è morto SIGINT \02 Term Interrupt da tastiera SIGQUIT \03 Core Segnale d'uscita della tastiera SIGILL \04 Core Istruzione illegale SIGABRT \06 Core Segnale d'abbandono di \fBabort\fP(3) SIGFPE \08 Core Eccezione in virgola mobile SIGKILL \09 Term Termina il processo SIGSEGV 11 Core Riferimento di memoria non valido SIGPIPE 13 Term Pipe rotta: scrittura su una pipe priva di lettori SIGALRM 14 Term Segnale del timer da \fBalarm\fP(2) SIGTERM 15 Term Segnale di termine SIGUSR1 30,10,16 Term Segnale 1 definito dall'utente SIGUSR2 31,12,17 Term Segnale 2 definito dall'utente SIGCHLD 20,17,18 Ign Figlio fermato o terminato SIGCONT 19,18,25 Cont Continua se fermato SIGSTOP 17,19,23 Stop Ferma il processo SIGTSTP 18,20,24 Stop Stop digitato dal terminale SIGTTIN 21,21,26 Stop Input da terminale per un processo sullo sfondo SIGTTOU 22,22,27 Stop Output da terminale per un processo sullo sfondo .TE I segnali .B SIGKILL e .B SIGSTOP non possono essere intercettati, bloccati o ignorati. Seguono i segnali che non sono nello standard POSIX.1\-1990 ma sono descritti in SUSv2 e POSIX.1\-2001. .TS l c c l ____ lB c c l. Segnale Valore Azione Commento SIGBUS 10,7,10 Core Errore sul bus (accesso errato alla memoria) SIGPOLL Term Evento suscettibile di polling (Sys V). Sinonimo di \fBSIGIO\fP SIGPROF 27,27,29 Term Timer del profiler scaduto SIGSYS 12,31,12 Core Argomento errato alla routine (SVr4) SIGTRAP 5 Core Trappola per trace/breakpoint SIGURG 16,23,21 Ign Condizione urgente sul socket (4.2BSD) SIGVTALRM 26,26,28 Term Allarme virtuale (4.2BSD) SIGXCPU 24,24,30 Core Superato tempo limite di CPU (4.2BSD) SIGXFSZ 25,25,31 Core Limite dimensione file superato (4.2BSD) .TE Fino a Linux 2.2 incluso, il comportamento predefinito per .BR SIGSYS ", " SIGXCPU ", " SIGXFSZ ", " e (su architetture diverse da SPARC e MIPS) .B SIGBUS era terminare il processo (senza eseguire un core dump). (In alcuni altri sistemi UNIX l'azione predefinita per .BR 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. E ora altri vari segnali. .TS l c c l ____ lB c c l. Segnale Valore Azione Commento SIGIOT 6 Core Trappola IOT. Sinonimo di \fBSIGABRT\fP SIGEMT 7,\-,7 Term SIGSTKFLT \-,16,\- Term Errore dello stack del coprocessore (inutilizzato) SIGIO 23,29,22 Term I/O ora possibile (4.2 BSD) SIGCLD \-,\-,18 Ign Sinonimo di \fBSIGCHLD\fP SIGPWR 29,30,19 Term Mancanza di corrente (System V) SIGINFO 29,\-,\- Sinonimo di \fBSIGPWR\fP SIGLOST \-,\-,\- Term Perso il lock del file (non usato) SIGWINCH 28,28,20 Ign Dimensioni finestra cambiate (4.3BSD, Sun) SIGUNUSED \-,31,\- Core Sinonimo di \fBSIGSYS\fP) .TE (Il segnale 29 è .B SIGINFO / .B SIGPWR su alpha ma .B SIGLOST su sparc.) .B 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. .B SIGPWR (non specificato in POSIX.1\-2001) è tipicamente ignorato in via predefinita in questi altri UNIX dove appare. .B SIGIO (non specificato in POSIX.1\-2001) è ignorato in via predefinita in molti altri sistemi UNIX. Dove definito, .B SIGUNUSED è sinonimo di .\" parisc è l'unica eccezione: SIGSYS è 12, SIGUNUSED è 31 .B SIGSYS sulla maggior parte delle architetture. .SS Segnali Real-time 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 .B SIGRTMIN e .BR SIGRTMAX . POSIX.1\-2001 richiede che un'implementazione supporti almeno i segnali real-time .B _POSIX_RTSIG_MAX(8) . .PP Il kernel Linux supporta un intervallo di 32 diversi segnali real\-time, numerati da 33 a 64. Comunque, l'implementazione di glibc POSIX dei thread usa internamente due (per NTPL) o tre (per LinuxThreads) segnali real\-time (vedere .BR pthreads (7)), e sistema il valore di .B 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 .IR "non dovrebbero mai riferirsi ai segnali real-time usando numeri prefissati" . Dovrebbero invece sempre fare riferimento ai segnali real\-time usando la notazione .BR SIGRTMIN +n, e includere controlli adatti (run-time) perché .BR SIGRTMIN +n non ecceda .BR SIGRTMAX . .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 .BR 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 .B SA_SIGINFO a .BR sigaction (2) allora esso può ottenere questo dato attraverso il campo .I si_value della struttura .I siginfo_t passata come secondo argomento al gestore. Inoltre i campi .I si_pid e .I si_uid 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 in sospeso per un processo, essi verranno recapitati in un ordine non specificato. .PP Se sia i segnali predefinit che quelli real\-time sono in attesa di 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 .B _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 .IR /proc/sys/kernel/rtsig-max . Un file correlato, .IR /proc/sys/kernel/rtsig-nr , può essere usato per trovare quanti segnali real\-time sono attualmente accodati. In Linux 2.6.8, queste interfacce .I /proc sono sostituite dal limite di risorsa .B RLIMIT_SIGPENDING che specifica un limite per utente per i segnali accodati. Vedere .BR setrlimit (2) per ulteriori dettagli. .SS Funzioni async-signal-safe .PP Una funzione di manipolazione dei segnali deve fare molta attenzione, poiché qualunque processo può essere interrotto in un punto arbitrario durante l'esecuzione del programma. POSIX ha il concetto di "funzione sicura". Se un segnale interrompe l'esecuzione di una funzione non sicura, e .I handler chiama una funzione non sicura, allora il comportamento del programma non è definito. POSIX.1-2004 (già conosciuto come POSIX.1-2001 Technical Corrigendum 2) richiede all'implementazione di garantire che le seguenti funzioni possano essere chiamate in sicurezza in un gestore di segnali: .in +4 .nf _Exit() _exit() abort() accept() access() aio_error() aio_return() aio_suspend() alarm() bind() cfgetispeed() cfgetospeed() cfsetispeed() cfsetospeed() chdir() chmod() chown() clock_gettime() close() connect() creat() dup() dup2() execle() execve() fchmod() fchown() fcntl() fdatasync() fork() fpathconf() fstat() fsync() ftruncate() getegid() geteuid() getgid() getgroups() getpeername() getpgrp() getpid() getppid() getsockname() getsockopt() getuid() kill() link() listen() lseek() lstat() mkdir() mkfifo() open() pathconf() pause() pipe() poll() posix_trace_event() pselect() raise() read() readlink() recv() recvfrom() recvmsg() rename() rmdir() select() sem_post() send() sendmsg() sendto() setgid() setpgid() setsid() setsockopt() setuid() shutdown() sigaction() sigaddset() sigdelset() sigemptyset() sigfillset() sigismember() signal() sigpause() sigpending() sigprocmask() sigqueue() sigset() sigsuspend() sleep() sockatmark() socket() socketpair() stat() symlink() sysconf() tcdrain() tcflow() tcflush() tcgetattr() tcgetpgrp() tcsendbreak() tcsetattr() tcsetpgrp() time() timer_getoverrun() timer_gettime() timer_settime() times() umask() uname() unlink() utime() wait() waitpid() write() .fi .in .PP POSIX.1-2008 rimuove fpathconf(), pathconf(), e sysconf() dall'elenco precedente, e aggiunge le seguenti funzioni: .PP .in +4n .nf execl() execv() faccessat() fchmodat() fchownat() fexecve() fstatat() futimens() linkat() mkdirat() mkfifoat() mknod() mknodat() openat() readlinkat() renameat() symlinkat() unlinkat() utimensat() utimes() .fi .in .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 .BR EINTR . .PP Il verificarsi di uno di questi due comportamenti dipende dall'interfaccia e dall'uso o meno del flag .BR SA_RESTART alla creazione del gestore di segnale (vedere .BR 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 verrà automaticamente riavviata dopo il ritorno del gestore di segnale, se è stato usato il flag .BR SA_RESTART , altrimenti la chiamata fallirà con l'errore .BR EINTR : .\" Le seguenti chiamate di sistema usano ERESTARTSYS, .\" così da essere riavviabili chiamate .RS 4 .IP * 2 .BR read (2), .BR readv (2), .BR write (2), .BR writev (2), e .BR 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 (un disco non è un dispositivo lento, stando a quanto dice la sua definizione). 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). .IP * .BR open (2), se si può bloccare (per esempio nell'aprire un FIFO: vedere .BR fifo (7)). .IP * .BR wait (2), .BR wait3 (2), .BR wait4 (2), .BR waitid (2), e .BR waitpid (2). .IP * Interfacce socket: .\" Se si sta verificando un timeout (setsockopt()) sul socket, queste .\" chiamate di sistema passeranno ad usare EINTR. Di conseguenza non verranno .\" automaticamente riavviate, e mostreranno il comportamento stop/cont .\" descritto più sotto (verificato dai sorgenti 2.6.26 e tramite esperimenti; mtk) .BR accept (2), .BR connect (2), .BR recv (2), .BR recvfrom (2), .BR recvmmsg (2), .BR recvmsg (2), .BR send (2), .BR sendto (2), e .\" FIXME . What about sendmmsg()? .BR sendmsg (2), a meno che venga impostato un timeout sul socket (vedere sotto). .IP * Interfacce che bloccano i file: .BR flock (2) e .BR fcntl (2) .BR F_SETLKW . .IP * Interfacce per messaggi POSIX in coda: .BR mq_receive (3), .BR mq_timedreceive (3), .BR mq_send (3), e .BR mq_timedsend (3). .IP * .BR futex (2) .B FUTEX_WAIT (a partire da Linux 2.6.22; prima falliva sempre con .BR EINTR ). .IP * Interfacce semaforo POSIX: .BR sem_wait (3) e .BR sem_timedwait (3) (a partire da Linux 2.6.22; prima falliva sempre con .BR EINTR ). .RE .PP Le seguenti interfacce non vengono mai riavviate dopo l'interruzione da parte di un gestore di segnale, senza curarsi dell'uso di .BR SA_RESTART ; falliscono sempre con l'errore .B EINTR quando vengono interrotte da un gestore di segnale: .\" Queste sono chiamate di sistema che restituiscono EINTR o ERESTARTNOHAND .\" quando interrotte da un gestore di segnale. .RS 4 .IP * 2 Interfacce socket in "input", quando è stato impostato un timeout .RB ( SO_RCVTIMEO ) sul socket usando .BR setsockopt (2): .BR accept (2), .BR recv (2), .BR recvfrom (2), .BR recvmmsg (2) (anche con un argomento .IR imeout non NULLO) e .BR recvmsg (2). .IP * Interfacce socket in "output", quando è stato impostato un timeout .RB ( SO_RCVTIMEO ) sul socket usando .BR setsockopt (2): .BR connect (2), .BR send (2), .BR sendto (2), e .\" FIXME . What about sendmmsg()? .BR sendmsg (2). .IP * Interfacce usate per aspettare segnali: .BR pause (2), .BR sigsuspend (2), .BR sigtimedwait (2), e .BR sigwaitinfo (2). .IP * Interfacce condivise per descrittori di file .BR epoll_wait (2), .BR epoll_pwait (2), .BR poll (2), .BR ppoll (2), .BR select (2), e .BR pselect (2). .IP * Interfacce IPV System V: .\" Su alcuni altri sistemi, SA_RESTART non riavvia queste chiamate di sistema .BR msgrcv (2), .BR msgsnd (2), .BR semop (2), e .BR semtimedop (2). .IP * Interfacce sleep: .BR clock_nanosleep (2), .BR nanosleep (2), e .BR usleep (3). .IP * .BR read (2) da un descrittore di file .BR inotify (7). .IP * .BR io_getevents (2). .RE .PP La funzione .BR sleep (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 .BR EINTR dopo che il processo è stato fermato da un segnale di stop, e poi riavviato tramite .BR SIGCONT . Questo comportamento non è sanzionato da POSIX.1, e non avviene su altri sistemi. Le interfacce Linux che si comportano in questo modo sono: .RS 4 .IP * 2 Interfacce socket in "input", quando è stato impostato un timeout .RB ( SO_RCVTIMEO ) sul socket usando .BR setsockopt (2): .BR accept (2), .BR recv (2), .BR recvfrom (2), .BR recvmmsg (2) (anche con un argomento .IR timeout non NULL), e .BR recvmsg (2). .IP * Interfacce socket in "output", quando è stato impostato un timeout .RB ( SO_RCVTIMEO ) sul socket usando .BR setsockopt (2): .BR connect (2), .BR send (2), .BR sendto (2), e .\" FIXME . What about sendmmsg()? .BR sendmsg (2), se è stato impostato un timeout in invio .RB ( SO_SNDTIMEO ). .IP * 2 .BR epoll_wait (2), .BR epoll_pwait (2). .IP * .BR semop (2), .BR semtimedop (2). .IP * .BR sigtimedwait (2), .BR sigwaitinfo (2). .IP * .BR read (2) da un descrittore di file .BR inotify (7) . .IP * Linux 2.6.21 e precedenti: .BR futex (2) .BR FUTEX_WAIT , .BR sem_timedwait (3), .BR sem_wait (3). .IP * Linux 2.6.8 e precedenti: .BR msgrcv (2), .BR msgsnd (2). .IP * Linux 2.4 e precedenti: .BR nanosleep (2). .RE .SH CONFORME A POSIX.1, tranne dove indicato. .\" Dev'essere passato *molto* tempo da quando questo era vero: .\" .SH BUG .\" .B SIGIO .\" e .\" .B SIGLOST .\" hanno lo stesso valore. .\" L'ultimo è commentato nel sorgente del kernel, ma il processo di .\" costruzione di alcuni software pensa ancora che .\" il segnale 29 sia .\" .BR SIGLOST . .SH VEDERE ANCHE .BR kill (1), .BR getrlimit (2), .BR kill (2), .BR killpg (2), .BR restart_syscall (2), .BR rt_sigqueueinfo (2), .BR setitimer (2), .BR setrlimit (2), .BR sgetmask (2), .BR sigaction (2), .BR sigaltstack (2), .BR signal (2), .BR signalfd (2), .BR sigpending (2), .BR sigprocmask (2), .BR sigsuspend (2), .BR sigwaitinfo (2), .BR abort (3), .BR bsd_signal (3), .BR longjmp (3), .BR raise (3), .BR pthread_sigqueue (3), .BR sigqueue (3), .BR sigset (3), .BR sigsetops (3), .BR sigvec (3), .BR sigwait (3), .BR strsignal (3), .BR sysv_signal (3), .BR core (5), .BR proc (5), .BR pthreads (7), .BR sigevent (7) .SH COLOPHON Questa pagina fa parte del rilascio 3.73 del progetto Linux .IR man-pages . Una descrizione del progetto, le istruzioni per la segnalazione degli errori, e l'ultima versione di questa pagina si trova su \%http://www.kernel.org/doc/man\-pages/. La versione italiana fa parte del pacchetto .I man-pages-it v. 3.73, a cura di: ILDP "Italian Linux Documentation Project" \%http://www.pluto.it/ildp .br Per la traduzione in italiano si pu\(`o fare riferimento a http://www.pluto.it/ildp/collaborare/ .br Segnalare eventuali errori di traduzione a .IR ildp@pluto.it