Provided by: manpages-it_4.23.1-1_all bug

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:

            (1.1)  Il segnale è rimosso dal'insieme dei segnali pendenti.

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

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

            (1.4)  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
       Starting with Linux 2.2, Linux supports real-time signals as  originally  defined  in  the
       POSIX.1b  real-time extensions (and now included in POSIX.1-2001).  The range of supported
       real-time signals is defined by the macros SIGRTMIN and SIGRTMAX.   POSIX.1-2001  requires
       that an implementation support at least _POSIX_RTSIG_MAX (8) real-time signals.

       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:

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

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

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

       According to POSIX, an implementation should  permit  at  least  _POSIX_SIGQUEUE_MAX  (32)
       real-time  signals to be queued to a process.  However, Linux does things differently.  Up
       to and including Linux 2.6.7, Linux imposes a system-wide limit on the  number  of  queued
       real-time  signals  for  all  processes.   This  limit  can be viewed and (with privilege)
       changed    via    the    /proc/sys/kernel/rtsig-max     file.      A     related     file,
       /proc/sys/kernel/rtsig-nr,  can  be  used  to  find  out  how  many  real-time signals are
       currently  queued.   In  Linux  2.6.8,  these  /proc  interfaces  were  replaced  by   the
       RLIMIT_SIGPENDING resource limit, which specifies a per-user limit for queued signals; see
       setrlimit(2)  for further details.

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

       The /proc/pid/task/tid/status file contains various fields that show the  signals  that  a
       thread is blocking (SigBlk), catching (SigCgt), or ignoring (SigIgn).  (The set of signals
       that are caught or ignored will be the same across  all  threads  in  a  process.)   Other
       fields show the set of pending signals that are directed to the thread (SigPnd) as well as
       the set of pending signals that are directed to the process  as  a  whole  (ShdPnd).   The
       corresponding  fields  in  /proc/pid/status show the information for the main thread.  See
       proc(5)  for further details.

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(3type)

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