Provided by: manpages-fr_4.13-4_all bug

NOM

       signal – Panorama des signaux

DESCRIPTION

       Linux  prend  en  charge  à  la  fois  les  signaux  POSIX  classiques (« ci-après signaux
       standard ») et les signaux POSIX temps réel.

   Action des signaux
       Chaque signal a une action en vigueur qui détermine le comportement du processus lorsqu'il
       reçoit ce signal.

       Les  éléments  de  la colonne « Action » indiquent l'action par défaut pour chaque signal,
       avec la signification suivante :

       Term   Par défaut, terminer le processus.

       Ign    Par défaut, ignorer le signal.

       Core   Par défaut, terminer le processus et créer un fichier  d'image  mémoire  (consultez
              core(5)).

       Stop   Par défaut, arrêter le processus.

       Cont   Par défaut, continuer le processus s'il est actuellement arrêté.

       Un processus peut changer l’action d'un signal avec sigaction(2) ou signal(2) (la deuxième
       option est moins portable quand un gestionnaire de signal est défini ; consultez signal(2)
       pour  plus de détails). Avec ces appels système, un processus peut choisir de se comporter
       de l'une des façons suivantes lorsqu'il reçoit un signal : effectuer l'action par  défaut,
       ignorer  le  signal  ou intercepter le signal avec un gestionnaire de signal, c'est-à-dire
       une fonction définie par le programme qui est invoquée automatiquement lorsque  le  signal
       est transmis.

       Par défaut, le gestionnaire de signal est appelé sur la pile normale des processus. Il est
       possible de prévoir que le gestionnaire de  signal  utilise  une  autre  pile ;  consultez
       sigaltstack(2)  pour  une  discussion  sur  comment faire cela et quand cela pourrait être
       utile.

       L’action d'un signal est un attribut du processus : dans  une  application  multithreadée,
       l’action d'un signal particulier est la même pour tous les threads.

       Un  enfant créé par fork(2) hérite d'une copie des actions des signaux de son parent. Lors
       d'un execve(2), les actions des signaux pris  en  charge  sont  remises  aux  valeurs  par
       défaut ; les actions des signaux ignorés ne sont pas modifiées.

   Envoyer un signal
       Les  appels  système  et les fonctions de bibliothèque qui suivent permettent à l'appelant
       d'envoyer un signal :

       raise(3)
              Envoyer un signal au thread appelant.

       kill(2)
              Envoyer un signal au processus indiqué, à tous les membres du groupe  de  processus
              indiqué ou à tous les processus du système.

       pidfd_send_signal(2)
              Envoyer un signal à un processus identifié par un descripteur de fichier de PID.

       killpg(3)
              Envoyer un signal à tous les membres du groupe de processus indiqué.

       pthread_kill(3)
              Envoyer un signal au thread POSIX indiqué dans le même processus que l'appelant.

       tgkill(2)
              Envoyer  un  signal  au  thread  indiqué  à l'intérieur d'un processus donné (c'est
              l'appel système utilisé pour implémenter pthread_kill(3)).

       sigqueue(3)
              Envoyer un signal temps réel, avec ses données jointes, au processus indiqué.

   Attente de la capture d'un signal
       Les appels système suivants suspendent l'exécution du thread  appelant  jusqu'à  ce  qu'un
       signal soit reçu (ou qu'un signal non pris en charge termine le processus) :

       pause(2)
              Suspendre l'exécution jusqu'à ce que n'importe quel signal soit reçu.

       sigsuspend(2)
              Changer  temporairement  le  masque  de  signaux  (voir  ci-dessous)  et  suspendre
              l'exécution jusqu'à ce qu'un des signaux non masqué soit reçu.

   Accepter un signal de façon synchrone
       Au lieu d’intercepter un signal de façon asynchrone avec un gestionnaire de signal, il est
       possible  de l’accepter de façon synchrone, c'est-à-dire de bloquer l'exécution jusqu'à ce
       que le signal soit distribué. À ce moment, le noyau renvoie des informations concernant le
       signal à l'appelant. Il y a deux façons générales pour faire cela :

       – sigwaitinfo(2),  sigtimedwait(2)  et  sigwait(3) suspendent l'exécution jusqu'à ce qu'un
         des signaux dans l'ensemble indiqué soit distribué. Chacun de  ces  appels  renvoie  des
         informations concernant le signal distribué.

       – signalfd(2)  renvoie  un  descripteur  de  fichier  qui  peut être utilisé pour lire les
         informations concernant les signaux qui sont distribués  à  l'appelant.  Chaque  read(2)
         dans  ce descripteur de fichier est bloquant jusqu'à ce que un des signaux de l'ensemble
         indiqué dans l’appel signalfd(2) soit distribué à  l'appelant.  Le  tampon  renvoyé  par
         read(2) contient une structure qui décrit le signal.

   Masque de signaux et signaux en attente
       Un  signal  peut  être  bloqué,  ce  qui  signifie  qu'il  ne sera pas envoyé avant d'être
       débloqué. Entre le moment de sa création  et  celui  de  son  envoi,  le  signal  est  dit
       en attente.

       Chaque thread d'un processus a un masque de signaux indépendant qui indique l'ensemble des
       signaux bloqués par le thread.  Un  thread  peut  modifier  son  masque  de  signaux  avec
       pthread_sigmask(3).  Dans  une application traditionnelle à un seul thread, sigprocmask(2)
       peut être utilisée pour modifier le masque de signaux.

       Un processus enfant créé avec fork(2) hérite d'une copie  du  masque  de  signaux  de  son
       parent. Le masque de signaux est conservé au travers d'un execve(2).

       Un  signal  peut  être  « orienté  processus »  ou  « orienté  thread ». Un signal orienté
       processus est un signal qui cible (et par conséquent en attente pour)  le  processus  dans
       son  entier.  Il peut l’être parce qu’il a été généré par le noyau pour des raisons autres
       qu’une exception  matérielle  ou  parce  qu’il  a  été  envoyé  en  utilisant  kill(2)  ou
       sigqueue(3).  Un  signal orienté thread est destiné à un thread particulier. Un tel signal
       peut l’être parce qu’il a été généré  en  conséquence  de  l’exécution  d’une  instruction
       spécifique  de  code machine qui est déclenchée par une exception matérielle (par exemple,
       SIGSEGV pour un accès mémoire non autorisé ou SIGFPE  pour  une  erreur  mathématique)  ou
       parce qu’il visait un thread particulier en utilisant une interface telle que tgkill(2) ou
       pthread_kill(3).

       Un signal orienté processus peut être délivré à n’importe quel des threads qui  n’ont  pas
       présentement  le  signal bloqué. Si plus d’un des threads a le signal non bloqué, alors le
       noyau choisit un thread arbitraire auquel délivrer le signal.

       Un thread peut obtenir  l'ensemble  des  signaux  actuellement  en  attente  en  utilisant
       sigpending(2).  Cet  ensemble  est  l'union  de l’ensemble des signaux en attente orientés
       processus et l’ensemble des signaux en attente pour le thread appelant.

       Un enfant créé avec fork(2) débute avec un ensemble de signaux en attente vide. L'ensemble
       de signaux en attente est conservé au travers d'un execve(2).

   Exécution des gestionnaires de signal
       À  chaque  transition  d’une  exécution  en  mode  noyau vers une en mode utilisateur (par
       exemple, lors du retour d’un appel système ou l’ordonnancement d’un thread sur le CPU), le
       noyau  vérifie  s’il  existe  un  signal  en attente non bloqué pour lequel le processus a
       établi un gestionnaire de signal. Si un tel signal est en attente, les étapes suivantes se
       déroulent :

       1. Le  noyau réalise les étapes préparatoires nécessaires pour l’exécution du gestionnaire
          de signal :

          a) Le signal est supprimé de l’ensemble des signaux en attente.

          b) Si le gestionnaire de signal a été installé par un  appel  à  sigaction(2)  qui  est
             précisé par l’indicateur SA_ONSTACK et que le thread a défini une pile de signaux de
             remplacement (en utilisant sigaltstack(2)), alors cette pile est installée.

          c) Diverses pièces du contexte relatif au signal sont enregistrées dans  une  structure
             spéciale qui est créée dans la pile. Les informations enregistrées comprennent :

             * le  registre  de  compteur  du  programme  (c’est-à-dire l’adresse de la prochaine
               instruction dans le programme principal qui devrait être exécutée lors  du  renvoi
               du gestionnaire de signal) ;

             * l’état  du  registre  spécifique  à  l’architecture  nécessaire  pour reprendre le
               programme interrompu ;

             * le masque de signaux du thread actuel ;

             * les paramètres de la pile de signaux de remplacement du thread.

             (Si le gestionnaire de signal a été installé en utilisant l’indicateur SA_SIGINFO de
             sigaction(2),  alors les informations ci-dessus sont accessibles à l’aide de l’objet
             ucontext_t qui est pointé par le troisième argument du gestionnaire de signal.)

          d) Tout signal précisé dans act->sa_mask lors de l’enregistrement du gestionnaire  avec
             sigprocmask(2)  est  ajouté  au masque de signaux du thread. Le signal à transmettre
             est aussi ajouté au masque de signaux à moins que SA_NODEFER ait été précisé lors de
             l’enregistrement  du  gestionnaire.  Ces  signaux  sont alors bloqués pendant que le
             gestionnaire réalise l’exécution.

       2. Le noyau construit une structure pour le gestionnaire de signal sur la pile.  Le  noyau
          règle le compteur du programme pour le thread pour pointer à la première instruction de
          la fonction du gestionnaire de signal et  configure  l’adresse  de  retour  pour  cette
          fonction  pour  pointer  vers  un  élément  du code de l’espace utilisateur connu comme
          « trampoline de signal » (décrit dans sigreturn(2)).

       3. Le noyau repasse le contrôle à l’espace utilisateur où l’exécution commence au début de
          la fonction du gestionnaire de signal.

       4. Au renvoi du gestionnaire de signal, le contrôle passe au trampoline de signal.

       5. Le  trampoline  de  signal  appelle  sigreturn(2),  un  appel  système  qui utilise les
          informations dans la structure de la pile créée à la première étape pour  restaurer  le
          thread dans son état avant que le gestionnaire de signal ait été appelé. Les paramètres
          du masque de signaux du thread et de la pile de signaux de remplacement sont  restaurés
          dans  le  cadre  de  cette  procédure.  À  la  fin  de l’appel à sigreturn(2), le noyau
          transfère le contrôle à l’espace utilisateur et  le  thread  recommence  l’exécution  à
          partir du point où elle a été interrompue par le gestionnaire de signal.

       Remarquez  que  si  le gestionnaire de signal ne renvoie pas (par exemple, le contrôle est
       transféré en dehors du gestionnaire en utilisant siglongjmp(3) ou le gestionnaire  exécute
       un  nouveau  programme  avec  execve(2)),  alors  l’étape  finale  n’est  par réalisée. En
       particulier, dans de tels scénarios, c’est la responsabilité du programmeur  de  restaurer
       l’état du masque de signaux (en utilisant sigprocmask(2)) si le déblocage des signaux, qui
       étaient bloqués par une entrée dans le gestionnaire de  signal,  est  désiré.  (Notez  que
       siglongjmp(3)  peut ou ne peut pas restaurer le masque de signaux en fonction de la valeur
       savesigs qui était indiquée dans l’appel correspondant à sigsetjmp(3).)

       Du point de vue du noyau, l’exécution du code du gestionnaire de signal est exactement  la
       même  que  celle de n’importe quel code de l’espace utilisateur. C’est-à-dire que le noyau
       n’enregistre aucune information spéciale d’état indiquant que le thread  est  actuellement
       en  exécution  à  l’intérieur  d’un gestionnaire de signal. Toutes les informations d’état
       nécessaires sont entretenues dans des registres de l’espace  utilisateur  et  la  pile  de
       l’espace  utilisateur.  La  profondeur  à  laquelle  les gestionnaires de signal imbriqués
       peuvent être invoqués est donc limitée seulement par la pile de l’espace  utilisateur  (et
       une conception logicielle raisonnable).

   Signaux standard
       Linux  prend  en  charge  les  signaux  standard  listés ci-dessous. La seconde colonne du
       tableau indique quelle norme (si elle existe) décrit le signal : « P1990 » indique que  le
       signal est décrit dans la norme POSIX.1-1990 originelle. « P2001 » indique que le signal a
       été ajouté dans SUSv2 et POSIX.1-2001.

       Signal      Norme   Action   Commentaire
       ───────────────────────────────────────────────────────────────────────────────
       SIGABRT     P1990    Core    Signal d'arrêt d’abort(3)
       SIGALRM     P1990    Term    Signal de temporisation d’alarm(2)
       SIGBUS      P2001    Core    Erreur de bus (mauvais accès mémoire)
       SIGCHLD     P1990    Ign     Enfant arrêté ou terminé
       SIGCLD        -      Ign     Synonyme pour SIGCHLD
       SIGCONT     P1990    Cont    Continuer si arrêté
       SIGEMT        -      Term    Interception (trap) d’émulateur
       SIGFPE      P1990    Core    Exception de virgule flottante
       SIGHUP      P1990    Term    Déconnexion détectée sur le terminal de
                                    contrôle ou mort du processus de contrôle
       SIGILL      P1990    Core    Instruction illégale
       SIGINFO       -              Synonyme pour SIGPWR
       SIGINT      P1990    Term    Interruption depuis le clavier
       SIGIO         -      Term    E/S maintenant possible (4.2BSD)
       SIGIOT        -      Core    Interception IOT – synonyme pour SIGABRT
       SIGKILL     P1990    Term    Signal d’arrêt
       SIGLOST       -      Term    Perte de verrou de fichier (inutilisé)
       SIGPIPE     P1990    Term    Tube brisé : écriture dans un tube sans
                                    lecteur – voir pipe(7)
       SIGPOLL     P2001    Term    Événement scrutable (System V)
                                    – synonyme pour SIGIO
       SIGPROF     P2001    Term    Fin d'une temporisation de profilage
       SIGPWR        -      Term    Panne d'alimentation (System V)
       SIGQUIT     P1990    Core    Quitter depuis le clavier
       SIGSEGV     P1990    Core    Référence mémoire non valable
       SIGSTKFLT     -      Term    Erreur de pile sur coprocesseur (inutilisé)
       SIGSTOP     P1990    Stop    Processus d’arrêt
       SIGTSTP     P1990    Stop    Stop saisi sur le terminal
       SIGSYS      P2001    Core    Mauvais appel système (SVr4)
                                    – voir aussi seccomp(2)
       SIGTERM     P1990    Term    Signal de fin
       SIGTRAP     P2001    Core    Interception pour trace ou pour point d’arrêt
       SIGTTIN     P1990    Stop    Entrée du terminal pour processus en arrière-plan
       SIGTTOU     P1990    Stop    Sortie du terminal pour processus en arrière-plan
       SIGUNUSED     -      Core    Synonyme pour SIGSYS
       SIGURG      P2001    Ign     Condition urgente sur un socket (4.2BSD)
       SIGUSR1     P1990    Term    Signal utilisateur 1
       SIGUSR2     P1990    Term    Signal utilisateur 2
       SIGVTALRM   P2001    Term    Horloge virtuelle d’alarme (4.2BSD)
       SIGXCPU     P2001    Core    Limite de temps CPU dépassée (4.2BSD)

                                    Consultez setrlimit(2)
       SIGXFSZ     P2001    Core    Taille de fichier excessive (4.2BSD)
                                    Consultez setrlimit(2)
       SIGWINCH      -      Ign     Fenêtre redimensionnée (4.3BSD, Sun)

       Les signaux SIGKILL et SIGSTOP ne peuvent être ni capturés, ni bloqués, ni ignorés.

       Jusqu'à Linux 2.2 inclus, l'action par défaut pour SIGSYS, SIGXCPU, SIGXFSZ  et  (sur  les
       architectures  autres que SPARC ou MIPS) SIGBUS était de terminer simplement le processus,
       sans fichier image mémoire. (Sur certains  UNIX,  l'action  par  défaut  pour  SIGXCPU  et
       SIGXFSZ  est  de  finir  le processus sans fichier image mémoire.) Linux 2.4 se conforme à
       POSIX.1-2001 pour ces signaux et termine le processus avec un fichier image mémoire.

       SIGEMT n'est pas spécifié par POSIX.1-2001 mais apparaît  néanmoins  sur  la  plupart  des
       UNIX, avec une action par défaut typique correspondant à une fin du processus avec fichier
       image mémoire.

       SIGPWR (non spécifié dans POSIX.1-2001) est typiquement ignoré sur les autres UNIX  où  il
       apparaît.

       SIGIO  (non spécifié par POSIX.1-2001) est ignoré par défaut sur plusieurs autres systèmes
       UNIX.

   Sémantiques d’attente et de distribution pour les signaux standard
       Si plusieurs signaux standard sont en attente pour un processus, l’ordre dans  lequel  les
       signaux sont distribués n’est pas précisé.

       Les signaux standard ne sont pas mis en file d’attente. Si plusieurs instances d’un signal
       standard sont générées pendant que ce signal est  bloqué,  alors  une  seule  instance  du
       signal  est  marquée comme en attente (et le signal sera distribué une seule fois une fois
       débloqué). Dans le cas ou un signal standard est déjà en attente, la  structure  siginfo_t
       (consultez  sigaction(2))  associée  à  ce  signal  n’est  pas  écrasée  lors de l’arrivée
       d’instances  suivantes  du  même  signal.  Par  conséquent,  le  processus   recevra   les
       informations associées à la première instance du signal.

   Numérotation pour les signaux standard
       La  valeur  numérique  de chaque signal est donnée dans la table ci-dessous. Comme montrés
       dans cette table, plusieurs  signaux  ont  des  valeurs  numériques  différentes  sur  des
       architectures  différentes.  La  première  valeur  dans  chaque ligne indique le numéro de
       signal sur x86, ARM et la plupart des autres  architectures.  La  seconde  valeur  indique
       celui  pour  Alpha  et  SPARC.  La troisième indique celui de MIPS et la dernière celui de
       PA-RISC. Un tiret (-) indique que le signal est absent sur l’architecture correspondante.

       Signal        x86/ARM et la     Alpha/   MIPS   PA-RISC   Notes
                   plupart des arch.   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                                                   Idem à SIGIO
       SIGPWR             30            29/-     19      19
       SIGINFO             -            29/-     -        -
       SIGLOST             -            -/29     -        -
       SIGSYS             31             12      12      31
       SIGUNUSED          31             -       -       31

       Il est à noter que :

       –  si défini, SIGUNUSED est synonyme de SIGSYS. Depuis la glibc 2.26, SIGUNUSED n’est plus
          défini sur toutes les architectures ;

       –  le  signal 29 est SIGINFO/SIGPWR (synonymes pour la même valeur) sur Alpha mais SIGLOST
          sur SPARC.

   Signaux temps réel
       Depuis la version 2.2, Linux prend en charge les signaux temps réel tels  qu'ils  ont  été
       définis  à  l'origine  dans  les  extensions temps réel POSIX.1b (et inclus à présent dans
       POSIX.1-2001). L'éventail des signaux temps réel gérés est défini par les macros  SIGRTMIN
       et  SIGRTMAX.  POSIX.1-2001 exige qu'une implémentation gère au moins _POSIX_RTSIG_MAX (8)
       signaux temps réel.

       Le noyau Linux gère une gamme de 33 signaux temps réel différents, numérotés de 32  à  64.
       Cependant,  l'implémentation  des  threads POSIX de la glibc utilise en interne deux (pour
       l'implémentation NPTL) ou trois (pour l'implémentation LinuxThreads)  signaux  temps  réel
       (consultez pthreads(7)) et ajuste la valeur de SIGRTMIN en conséquence (à 34 ou 35). Comme
       la gamme de signaux temps réel varie en fonction de l'implémentation des  threads  par  la
       glibc  (et  cette  implémentation peut changer à l'exécution en fonction du noyau et de la
       glibc) et que la gamme de signaux temps réel varie bien sûr également suivant les systèmes
       UNIX,  les  programmes  ne  devraient  jamais  faire référence à des signaux temps réel en
       utilisant des numéros codés en dur, mais  devraient  toujours  à  la  place  utiliser  des
       signaux  temps  réel avec la notation SIGRTMIN+n avec des vérifications adéquates (lors de
       l'exécution) que SIGRTMIN+n ne dépasse pas SIGRTMAX.

       Contrairement aux signaux standard, les signaux temps  réel  n'ont  pas  de  signification
       prédéfinie :  l'ensemble complet de ces signaux peut être utilisé à des fins spécifiques à
       l'application.

       L'action par défaut pour un signal temps réel  non  géré  est  de  terminer  le  processus
       récepteur.

       Les signaux temps réel se distinguent de la façon suivante :

       1.  Plusieurs  instances  d'un  signal temps réel peuvent être mises en file d’attente. Au
           contraire, si plusieurs instances  d'un  signal  standard  arrivent  alors  qu'il  est
           présentement bloqué, une seule instance sera mise en file d’attente.

       2.  Si le signal est envoyé en utilisant sigqueue(3), il peut être accompagné d'une valeur
           (un entier ou un pointeur). Si le processus récepteur positionne un gestionnaire  pour
           ce  signal en utilisant l'attribut SA_SIGINFO pour l'appel sigaction(2), alors il peut
           accéder à la valeur transmise dans le champ si_value de la structure siginfo_t  passée
           en  second  argument  au  gestionnaire.  De plus, les champs si_pid et si_uid de cette
           structure fournissent le PID et l'UID réel du processus émetteur du signal.

       3.  Les signaux temps réel sont délivrés dans un ordre précis. Les  divers  signaux  temps
           réel  du  même  type  sont  délivrés  dans  l'ordre où ils ont été émis. Si différents
           signaux temps réel sont envoyés au processus, ils sont délivrés en commençant  par  le
           signal  de numéro le moins élevé (c’est-à-dire le signal de plus fort numéro est celui
           de priorité la plus faible). Par contre, si plusieurs signaux standard sont en attente
           pour un processus, l'ordre dans lequel ils sont délivrés n'est pas défini.

       Si  des  signaux  standard et des signaux temps réel sont simultanément en attente pour un
       processus, POSIX ne précise pas l'ordre de  délivrance.  Linux,  comme  beaucoup  d'autres
       implémentations, donne priorité aux signaux standard dans ce cas.

       D'après   POSIX,  une  implémentation  doit  permettre  la  mise  en  attente  d'au  moins
       _POSIX_SIGQUEUE_MAX (32) signaux temps réel pour un processus. Néanmoins, Linux fonctionne
       différemment.  Jusqu'au  noyau 2.6.7  inclus,  Linux impose une limite pour l'ensemble des
       signaux temps réel en attente sur le système pour tous les processus.  Cette  limite  peut
       être   consultée   et   modifiée   (avec   les   privilèges  adéquats)  grâce  au  fichier
       /proc/sys/kernel/rtsig-max. Un fichier associé, /proc/sys/kernel/rtsig-nr, indique combien
       de signaux temps réel sont actuellement en attente. Dans Linux 2.6.8, ces interfaces /proc
       ont été remplacées par la limite de ressources RLIMIT_SIGPENDING qui spécifie  une  limite
       par utilisateur pour les signaux en attente ; consultez setrlimit(2) pour plus de détails.

       L’ajout de signaux temps réel nécessite l’agrandissement de la structure de l’ensemble des
       signaux (sigset_t) de 32  à  64 bits.  Par  conséquent,  divers  appels  système  ont  été
       supplantés par de nouveaux appels système qui gèrent des ensembles de signaux plus grands.
       Les anciens et nouveaux appels système sont les suivants :

       Linux 2.0 et antérieurs   Linux 2.2 et postérieurs
       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)

   Interruption d’appel et de fonction par un gestionnaire de signal
       Si un gestionnaire de signal est invoqué pendant qu'un appel système ou  une  fonction  de
       bibliothèque est bloqué, alors :

       – soit l'appel est automatiquement redémarré après le renvoi du gestionnaire de signal ;

       – soit l'appel échoue avec l'erreur EINTR.

       Lequel  de  ces  deux  comportements  se  produira  dépend  de  l'interface  et  de  si le
       gestionnaire  de  signal  a  été  mis  en  place  avec  l'attribut  SA_RESTART  (consultez
       sigaction(2)). Les détails varient selon les systèmes UNIX ; voici ceux pour Linux.

       Si un appel en attente à l'une des interfaces suivantes est interrompu par un gestionnaire
       de signal, l'appel sera automatiquement redémarré  après  le  renvoi  du  gestionnaire  de
       signal  si l'attribut SA_RESTART a été indiqué ; autrement, l'appel échouera avec l'erreur
       EINTR :

       – Appels  read(2),  readv(2),  write(2),  writev(2)  et  ioctl(2)  sur  des  périphériques
         « lents ».  Un  périphérique « lent » est un périphérique où un appel d'E/S peut bloquer
         pendant un temps indéfini, par exemple un terminal, un tube ou un socket.  Si  un  appel
         d'E/S  sur  un  périphérique  lent  a  déjà  transféré  des  données au moment où il est
         interrompu par un gestionnaire de signal, l'appel  renverra  une  indication  de  succès
         (normalement,  le  nombre d'octets transférés). Remarquez que selon cette définition, un
         disque  (local)  n'est  pas  un  périphérique  lent.  Les  opérations  d’E/S   sur   les
         périphériques disque ne sont pas interrompues par des signaux.

       – open  (2),  s'il  peut  bloquer (par exemple, lors de l'ouverture d'une FIFO ; consultez
         fifo(7)).

       – wait(2), wait3(2), wait4(2), waitid(2), et waitpid(2).

       – Interfaces  de  socket :  accept(2),  connect(2),  recv(2),  recvfrom(2),   recvmmsg(2),
         recvmsg(2),  send(2),  sendto(2)  et  sendmsg(2), à moins qu'une temporisation n'ait été
         placée sur le socket (voir ci-dessous).

       – Interfaces de blocage de fichier : flock(2) et les opérations F_SETLKW  et  F_OFD_SETLKW
         de fcntl(2)

       – Interfaces de files de messages POSIX : mq_receive(3), mq_timedreceive(3), mq_send(3) et
         mq_timedsend(3).

       – Opération FUTEX_WAIT  de  futex(2)  (depuis  Linux 2.6.22 ;  auparavant,  elle  échouait
         toujours avec l'erreur EINTR).

       – getrandom(2).

       – pthread_mutex_lock(3), pthread_cond_wait(3) et autres API apparentées.

       – FUTEX_WAIT_BITSET de futex(2.

       – Interfaces  de sémaphores POSIX : sem_wait(3) et sem_timedwait(3) (depuis Linux 2.6.22 ;
         auparavant, elles échouaient toujours avec l'erreur EINTR).

       – read(2) d’un descripteur de fichier d’inotify(7) (depuis  Linux 3.8 ;  auparavant,  elle
         échouait toujours avec l'erreur EINTR).

       Les  interfaces  suivantes  ne  sont  jamais relancées après avoir été interrompues par un
       gestionnaire de signal, quelle que  soit  l'utilisation  de  SA_RESTART ;  elles  échouent
       toujours  avec  l'erreur  EINTR  lorsqu'elles  sont  interrompues  par  un gestionnaire de
       signal :

       – Interfaces de socket « entrée », quand un délai de réception (SO_RCVTIMEO) a été  défini
         sur  le socket en utilisant setsockopt(2) : accept(2), recv(2), recvfrom(2), recvmmsg(2)
         (aussi avec un paramètre timeout non NULL) et recvmsg(2).

       – Interfaces de socket « sortie », quand un délai de réception (SO_RCVTIMEO) a été  défini
         sur le socket en utilisant setsockopt(2) : connect(2), send(2), sendto(2) et sendmsg(2).

       – Interfaces    utilisées   pour   attendre   des   signaux :   pause(2),   sigsuspend(2),
         sigtimedwait(2) et sigwaitinfo(2).

       – Interfaces de multiplexage de descripteurs de fichier :  epoll_wait(2),  epoll_pwait(2),
         poll(2), ppoll(2), select(2) et pselect(2).

       – Interfaces IPC de System V : msgrcv(2), msgsnd(2), semop(2) et semtimedop(2).

       – Interfaces de sommeil : clock_nanosleep(2), nanosleep(2) et usleep(3).

       – io_getevents(2).

       La  fonction  sleep(3)  n'est  également  jamais  relancée  si elle est interrompue par un
       gestionnaire, mais elle renvoie une indication de succès : le nombre de secondes restantes
       pour le sommeil.

   Interruption d’appel et de fonction par des signaux d'arrêt
       Sous  Linux,  même  en  l'absence  de gestionnaire de signal, certaines interfaces en mode
       bloquant peuvent échouer avec l'erreur EINTR après que le processus a été arrêté par  l'un
       des  signaux  d'arrêt et relancé avec le signal SIGCONT. Ce comportement n'est pas ratifié
       par POSIX.1 et n'apparaît pas sur d'autres systèmes.

       Les interfaces Linux qui affichent ce comportement sont :

       – Interfaces de socket « entrée », quand un délai de réception (SO_RCVTIMEO) a été  défini
         sur  le socket en utilisant setsockopt(2) : accept(2), recv(2), recvfrom(2), recvmmsg(2)
         (aussi avec un paramètre timeout non NULL) et recvmsg(2).

       – Les interfaces de socket « sortie », quand un délai de  réception  (SO_RCVTIMEO)  a  été
         défini  sur  le  socket  en  utilisant setsockopt(2) : connect(2), send(2), sendto(2) et
         sendmsg(2), si un délai de transmission (SO_SNDTIMEO) a été défini.

       – epoll_wait(2), epoll_pwait(2).

       – semop(2), semtimedop(2).

       – sigtimedwait(2), sigwaitinfo(2).

       – Linux 3.7 et antérieurs : read(2) sur un descripteur de fichier inotify(7).

       – Linux 2.6.21  et  antérieurs :  opération  FUTEX_WAIT  de  futex(2),   sem_timedwait(3),
         sem_wait(3).

       – Linux 2.6.8 et antérieurs : msgrcv(2), msgsnd(2).

       – Linux 2.4 et antérieurs : nanosleep(2).

CONFORMITÉ

       POSIX.1, sauf indication contraire.

NOTES

       Pour   une   discussion   sur   les   fonctions  sûres  de  signal  asynchrone,  consultez
       signal-safety(7).

       Le fichier /proc/[pid]/task/[tid]/status contient divers champs qui montrent  les  signaux
       qu’un thread bloque (SigBlk), capture (SigCgt) ou ignore (SigIgn). (L’ensemble des signaux
       qui sont capturés ou ignorés sera le même pour  tous  les  threads  d’un  processus.)  Les
       autres champs montrent l’ensemble des signaux en attente qui sont orientés thread (SigPnd)
       ainsi que l’ensemble des signaux qui sont orientés processus dans  leur  entier  (ShdPnd).
       Les  champs  correspondants  dans  /proc/[pid]/status  montrent les informations du thread
       principal. Consultez proc(5) pour d’autres détails.

BOGUES

       Six signaux existent qui peuvent  être  délivrés  à  cause  d’une  exception  matérielle :
       SIGBUS, SIGEMT, SIGFPE, SIGILL, SIGSEGV et SIGTRAP. Lequel de ces signaux est délivré pour
       n’importe quelle exception matérielle n’est pas documenté et semble parfois  ne  pas  être
       logique.

       Par  exemple,  un  accès  mémoire  non  autorisé  qui  provoque l’envoi de SIGSEGV sur une
       architecture peut provoquer l’envoi de SIGBUS sur une autre architecture ou vice versa.

       Comme autre exemple, l’utilisation de l’instruction int de x86 avec un  argument  interdit
       (tout  nombre  autre  que 3 ou 128) provoque l’envoi de SIGSEGV même si SIGILL serait plus
       adapté à cause de la façon dont le CPU rapporte l’opération interdite au noyau.

VOIR AUSSI

       kill(1),  clone(2),  getrlimit(2),  kill(2),   pidfd_send_signal(2),   restart_syscall(2),
       rt_sigqueueinfo(2), setitimer(2), setrlimit(2), sgetmask(2), sigaction(2), sigaltstack(2),
       signal(2),  signalfd(2),  sigpending(2),  sigprocmask(2),   sigreturn(2),   sigsuspend(2),
       sigwaitinfo(2),   abort(3),  bsd_signal(3),  killpg(3),  longjmp(3),  pthread_sigqueue(3),
       raise(3),  sigqueue(3),  sigset(3),  sigsetops(3),  sigvec(3),  sigwait(3),  strsignal(3),
       swapcontext(3), sysv_signal(3), core(5), proc(5), nptl(7), pthreads(7), sigevent(7)

COLOPHON

       Cette  page  fait partie de la publication 5.10 du projet man-pages Linux. Une description
       du projet et des instructions pour signaler des anomalies et la dernière version de  cette
       page peuvent être trouvées à l'adresse https://www.kernel.org/doc/man-pages/.

TRADUCTION

       La  traduction  française  de  cette  page  de  manuel  a  été créée par Christophe Blaess
       <https://www.blaess.fr/christophe/>, Stéphan  Rafin  <stephan.rafin@laposte.net>,  Thierry
       Vignaud  <tvignaud@mandriva.com>,  François Micaux, Alain Portal <aportal@univ-montp2.fr>,
       Jean-Philippe   Guérard   <fevrier@tigreraye.org>,   Jean-Luc   Coulon   (f5ibh)    <jean-
       luc.coulon@wanadoo.fr>,    Julien    Cristau    <jcristau@debian.org>,    Thomas   Huriaux
       <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin
       Duneau  <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis
       Barbier  <barbier@debian.org>,  David  Prévot   <david@tilapin.org>,   Cédric   Boutillier
       <cedric.boutillier@gmail.com>,   Frédéric   Hantrais  <fhantrais@gmail.com>  et  Jean-Paul
       Guillonneau <guillonneau.jeanpaul@free.fr>

       Cette traduction est une documentation libre ; veuillez vous reporter  à  la  GNU  General
       Public   License   version 3  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩  concernant  les
       conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
       message à debian-l10n-french@lists.debian.org ⟨⟩.