signal

SIGNAL(7)                 Manuel du programmeur Linux                SIGNAL(7)



NOM
       signal - Panorama des signaux

DESCRIPTION
       Linux prend en charge à la fois les signaux POSIX classiques
       (« signaux standards ») et les signaux POSIX temps-réel.

   Dispositions de signaux
       Chaque signal a une disposition courante, qui détermine le
       comportement du processus lorsqu'il reçoit ce signal.

       Les symboles 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, créer un fichier core et terminer le processus
              (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 la disposition d'un signal avec sigaction(2)
       ou signal(2) (la deuxième option est moins portable quand on définit
       un gestionnaire de signal ; 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 ce signal :
       effectuer l'action par défaut, ignorer le signal, ou rattraper 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 distribué. (Par défaut, le gestionnaire de signaux est
       appelé sur la pile normale des processus. Il est possible de
       s'arranger pour que le gestionnaire de signaux utilise une autre pile ;
       consultez sigaltstack(2) pour une discussion sur comment faire ceci et
       quand ça peut être utile.)

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

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

   Envoyer un signal
       Les appels système suivants permettent à l'appelant d'envoyer un
       signal :

       raise(3)        Envoie un signal au thread appelant.

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

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

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

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

       sigqueue(3)     Envoie 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 processus ou du
       thread appelant jusqu'à ce qu'un signal soit attrapé (ou qu'un signal
       non pris en charge termine le processus) :

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

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

   Accepter un signal de façon synchrone
       Au lieu de rattraper un signal de façon asynchrone avec un
       gestionnaire de signal, il est possible accepter un signal de façon
       synchrone, c'est-à -dire de bloquer l'exécution jusqu'à ce qu'un
       signal soit distribué. à ce moment, le noyau renvoie des informations
       concernant le signal à l'appelant. Il y a deux façon générale 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 des informations concernant les signaux qui sont distribué
         Ã  l'appelant. Chaque read(2) dans ce descripteur de fichier est
         bloquant jusqu'Ã  ce que des signaux de l'ensemble fournit Ã
         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 reçu
       par le processus avant d'être débloqué. Entre sa création et sa
       réception, 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 fils créé avec fork(2) hérite d'une copie du masque de
       signaux de son père ; le masque de signaux est conservé au travers
       d'un execve(2).

       Un signal peut être créé (et donc mis en attente) pour un processus
       dans son ensemble (par exemple avec kill(2)), ou pour un thread en
       particulier (par exemple, certains signaux comme SIGSEGV et SIGFPE sont
       générés suite à une instruction particulière en langage machine,
       et sont dirigés vers un thread, de même que les signaux envoyés avec
       pthread_kill(3)). Un signal envoyé à un processus peut être traité
       par n'importe lequel des threads qui ne le bloquent pas. Si plus d'un
       thread ne bloque pas le signal, le noyau choisit l'un de ces threads
       arbitrairement, et lui envoie le signal.

       Un thread peut obtenir l'ensemble des signaux en attente avec
       sigpending(2). Cet ensemble est l'union des signaux en attente envoyés
       au processus, et de ceux en attente pour le thread appelant.

       Un fils créé avec fork(2) démarre avec un ensemble de signaux en
       attente vide ; l'ensemble de signaux en attente est conservé au
       travers d'un execve(2).

   Signaux standards
       Linux prend en charge les signaux standards indiqués ci-dessous.
       Plusieurs d'entre eux dépendent de l'architecture, comme on le voit
       dans la colonne « Valeur ». Lorsque trois valeurs sont indiquées, la
       première correspond normalement aux architectures Alpha et Sparc, la
       seconde aux architectures x86, Arm, ainsi que la majorité des autres
       architectures, et la dernière aux Mips. (Les valeurs pour
       l'architecture Parisc ne sont pas indiquées ; consultez les sources du
       noyau Linux pour la numérotation des signaux sur cette architecture.)
       Un « - » dénote un signal absent pour l'architecture correspondante.

       Voici tout d'abord les signaux décrits dans le standard POSIX.1-1990
       original :

       Signal     Valeur    Action   Commentaire
       ──────────────────────────────────────────────────────────────────────────
       SIGHUP        1       Term    Déconnexion détectée sur le terminal
                                     de contrôle ou mort du processus de
                                     contrôle.
       SIGINT        2       Term    Interruption depuis le clavier.
       SIGQUIT       3       Core    Demande « Quitter » depuis le clavier.
       SIGILL        4       Core    Instruction illégale.
       SIGABRT       6       Core    Signal d'arrêt depuis abort(3).
       SIGFPE        8       Core    Erreur mathématique virgule flottante.
       SIGKILL       9       Term    Signal « KILL ».
       SIGSEGV      11       Core    Référence mémoire invalide.
       SIGPIPE      13       Term    Ãcriture dans un tube sans
                                     lecteur.
       SIGALRM      14       Term    Temporisation alarm(2) écoulée.
       SIGTERM      15       Term    Signal de fin.
       SIGUSR1   30,10,16    Term    Signal utilisateur 1.
       SIGUSR2   31,12,17    Term    Signal utilisateur 2.
       SIGCHLD   20,17,18    Ign     Fils arrêté ou terminé.
       SIGCONT   19,18,25    Cont    Continuer si arrêté.
       SIGSTOP   17,19,23    Stop    Arrêt du processus.
       SIGTSTP   18,20,24    Stop    Stop invoqué depuis le terminal.
       SIGTTIN   21,21,26    Stop    Lecture sur le terminal en arrière-plan.
       SIGTTOU   22,22,27    Stop    Ãcriture dans le terminal en arrière-plan.

       Les signaux SIGKILL et SIGSTOP ne peuvent ni capturés ni ignorés.

       Ensuite, les signaux non décrits par POSIX.1-1990, mais présents dans
       les spécifications SUSv2 et POSIX.1-2001 :

       Signal       Valeur    Action   Commentaire
       ──────────────────────────────────────────────────────────────────────────
       SIGBUS      10,7,10     Core    Erreur de bus (mauvais accès mémoire).
       SIGPOLL                 Term    Ãvénement « pollable » (System V).
                                       Synonyme de SIGIO.
       SIGPROF     27,27,29    Term    Expiration de la temporisation
                                       pour le suivi.
       SIGSYS      12,31,12    Core    Mauvais argument de fonction (SVr4).
       SIGTRAP        5        Core    Point d'arrêt rencontré.
       SIGURG      16,23,21    Ign     Condition urgente sur socket (BSD 4.2).
       SIGVTALRM   26,26,28    Term    Alarme virtuelle (BSD 4.2).
       SIGXCPU     24,24,30    Core    Limite de temps CPU dépassée (BSD 4.2).

       SIGXFSZ     25,25,31    Core    Taille de fichier excessive (BSD 4.2).

       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 core. (Sur
       certains UNIX, l'action par défaut pour SIGXCPU et SIGXFSZ est de
       finir le processus sans fichier core). Linux 2.4 se conforme Ã
       POSIX.1-2001 pour ces signaux et termine le processus avec un fichier
       core.

       Puis quelques signaux divers :

       Signal       Valeur    Action   Commentaire
       ─────────────────────────────────────────────────────────────────────────
       SIGIOT         6        Core    Arrêt IOT. Un synonyme de SIGABRT.
       SIGEMT       7,-,7      Term
       SIGSTKFLT    -,16,-     Term    Erreur de pile sur coprocesseur
                                       (inutilisé).
       SIGIO       23,29,22    Term    E/S Ã  nouveau possible(BSD 4.2).
       SIGCLD       -,-,18     Ign     Synonyme de SIGCHLD.
       SIGPWR      29,30,19    Term    Chute d'alimentation (System V).
       SIGINFO      29,-,-             Synonyme de SIGPWR.
       SIGLOST      -,-,-      Term    Perte de verrou de fichier (inusité).
       SIGWINCH    28,28,20    Ign     Fenêtre redimensionnée (BSD 4.3, Sun).
       SIGUNUSED    -,31,-     Core    Synonyme de SIGSYS

       (Le signal 29 est SIGINFO / SIGPWR sur Alpha mais SIGLOST sur Sparc).

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

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

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

       Si défini, SIGUNUSED est synonyme de SIGSYS sur la plupart des
       architectures.

   Signaux temps-réel
       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'intervalle des signaux
       temps-réels 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éels.

       Le noyau Linux gère une gamme de 32 signaux temps-réel, numérotés
       de 33 à 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, mais
       devraient toujours à la place utiliser des signaux temps-réel avec la
       notation SIGRTMIN+n en vérifiant à l'exécution que SIGRTMIN+n ne
       dépasse pas SIGRTMAX.

       Contrairement aux signaux standards, 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 capturé est de
       terminer le processus récepteur.

       Les signaux temps-réel se distinguent de leurs homologues classiques
       ainsi :

       1.  Plusieurs instances d'un signal temps-réel peuvent être
           empilées. Au contraire, si plusieurs instances d'un signal
           standard arrivent alors qu'il est bloqué, une seule instance sera
           mémorisée.

       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 en utilisant
           l'attribut SA_SIGINFO de 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.

       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é (le signal de plus fort
           numéro est celui de priorité la plus faible). Par contre, si
           plusieurs signaux standards sont en attente dans un processus,
           l'ordre dans lequel ils sont délivrés n'est pas défini.

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

       D'après POSIX, une implémentation doit permettre l'empilement 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 empilés
       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 empilés. 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 empilés ; voir
       setrlimit(2) pour plus de détails.

   Fonctions pour signaux sûr asynchrones
       Un gestionnaire de signal doit prendre beaucoup de précautions,
       puisqu'il peut interrompre à n'importe quel endroit l'exécution du
       programme. POSIX possède la notion de « fonctions sûres ». Si un
       signal interrompt l'exécution d'une fonction non sûre, et que le
       gestionnaire appelle une fonction non sûre, alors le comportement du
       programme n'est pas défini.

       POSIX.1-2004 (également appelée « POSIX.1-2001 Technical Corrigendum
       2 ») impose qu'une implémentation garantisse que les fonctions
       suivantes puissent être appelée sans risque à l'intérieur d'un
       gestionnaire de signal :

           _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()

       POSIX.1-2008 supprime fpathconf(), pathconf() et sysconf() de la liste
       ci-dessus et ajoute les fonctions suivantes :

           execl()
           execv()
           faccessat()
           fchmodat()
           fchownat()
           fexecve()
           fstatat()
           futimens()
           linkat()
           mkdirat()
           mkfifoat()
           mknod()
           mknodat()
           openat()
           readlinkat()
           renameat()
           symlinkat()
           unlinkat()
           utimensat()
           utimes()

   Interruption des appels système et des fonctions de bibliothèque par des
       gestionnaires 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 retour 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 bloqué à l'une des interfaces suivantes est interrompu
       par un gestionnaire de signal, l'appel sera automatiquement redémarré
       après le retour du gestionnaire de signal si l'attribut SA_RESTART a
       été indiqué ; autrement, l'appel échouera avec l'erreur EINTR :

           * Les 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'entrées-sorties peut bloquer
             pendant un temps infini, par exemple un terminal, un tube ou une
             socket. (Selon cette définition, un disque n'est pas un
             périphérique lent.) Si un appel d'entrées-sorties 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 un code de succès (normalement, le nombre d'octets
             transférés).

           * 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 sockets : accept(2), connect(2), recv(2),
             recvfrom(2), recvmmsg(2), recvmsg(2), send(2), sendto(2) et
             sendmsg(2), à moins qu'une temporisation n'ai été placée sur
             la socket (voir ci-dessous).

           * Interfaces de verrouillage de fichiers : opération F_SETLKW de
             flock(2) et 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, échouait toujours avec l'erreur EINTR).

           * Interfaces de sémaphores POSIX : sem_wait(3) et sem_timedwait(3)
             (depuis Linux 2.6.22 ; auparavant, é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 :

           * Les interfaces de socket d'entrée, quand un délai de réception
             (SO_RCVTIMEO) a été défini sur la 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 de sortie, quand un délai de réception
             (SO_RCVTIMEO) a été défini sur la 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).

           * read(2) sur un descripteur de fichier inotify(7).

           * io_getevents(2).

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

   Interruption des appels système et des fonctions de bibliothèque par des
       signaux d'arrêt
       Sous Linux, même en l'absence de gestionnaires 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 :

           * Les interfaces de socket d'entrée, quand un délai de réception
             (SO_RCVTIMEO) a été défini sur la 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 de sortie, quand un délai de réception
             (SO_RCVTIMEO) a été défini sur la 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).

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

VOIR AUSSI
       kill(1), getrlimit(2), kill(2), killpg(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), sigsuspend(2), sigwaitinfo(2), abort(3), bsd_signal(3),
       longjmp(3), raise(3), pthread_sigqueue(3), sigqueue(3), sigset(3),
       sigsetops(3), sigvec(3), sigwait(3), strsignal(3), sysv_signal(3),
       core(5), proc(5), pthreads(7), sigevent(7)

COLOPHON
       Cette page fait partie de la publication 3.70 du projet man-pages
       Linux. Une description du projet et des instructions pour signaler des
       anomalies peuvent être trouvées à l'adresse
       http://www.kernel.org/doc/man-pages/.

TRADUCTION
       Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a
       <http://po4a.alioth.debian.org/> par l'équipe de traduction
       francophone au sein du projet perkamon
       <http://perkamon.alioth.debian.org/>.

       Christophe Blaess <http://www.blaess.fr/christophe/> (1996-2003), Alain
       Portal <http://manpagesfr.free.fr/> (2003-2006).  Julien Cristau et
       l'équipe francophone de traduction de Debian (2006-2009).

       Veuillez signaler toute erreur de traduction en écrivant Ã
       <perkamon-fr@traduc.org>.

       Vous pouvez toujours avoir accès à la version anglaise de ce document
       en utilisant la commande « LC_ALL=C man <section> <page_de_man> ».



Linux                            13 juin 2014                        SIGNAL(7)