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" delle tabelle qui sotto specificano la 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.

A process can change the disposition of a signal using sigaction(2) or signal(2). (The latter is less portable when establishing a signal handler; see signal(2) for details.) Using these system calls, a process can elect one of the following behaviors to occur on delivery of the signal: perform the default action; ignore the signal; or catch the signal with a signal handler, a programmer-defined function that is automatically invoked when the signal is delivered. (By default, the signal handler is invoked on the normal process stack. It is possible to arrange that the signal handler uses an alternate stack; see sigaltstack(2) for a discussion of how to do this and when it might be useful.)

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.

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 processo o 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).

A signal may be generated (and thus pending) for a process as a whole (e.g., when sent using kill(2)) or for a specific thread (e.g., certain signals, such as SIGSEGV and SIGFPE, generated as a consequence of executing a specific machine-language instruction are thread directed, as are signals targeted at a specific thread using pthread_kill(3)). A process-directed signal may be delivered to any one of the threads that does not currently have the signal blocked. If more than one of the threads has the signal unblocked, then the kernel chooses an arbitrary thread to which to deliver the signal.

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).

Segnali standard¶

Linux supports the standard signals listed below. Several signal numbers are architecture-dependent, as indicated in the "Value" column. (Where three values are given, the first one is usually valid for alpha and sparc, the middle one for x86, arm, and most other architectures, and the last one for mips. (Values for parisc are not shown; see the Linux kernel source for signal numbering on that architecture.) A dash (-) denotes that a signal is absent on the corresponding architecture.

First the signals described in the original POSIX.1-1990 standard.

I segnali SIGKILL e SIGSTOP non possono essere intercettati, bloccati o ignorati.

Next the signals not in the POSIX.1-1990 standard but described in SUSv2 and POSIX.1-2001.

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.

Next various other signals.

Il segnale 29 è SIGINFO / SIGPWR su un alpha ma SIGLOST su uno sparc.

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.

Dove definito, SIGUNUSED è sinonimo di SIGSYS sulla maggior parte delle architetture. Da glibc 2.26, SIGUNUSED non è più definito su nessuna architettura.

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:

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.

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).