Provided by: manpages-fr_3.32d0.2p4-1_all bug

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(2)     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 ix86, ia64, ppc, s390, arm et sh, et la dernière aux Mips. 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 tty.
       SIGTTIN   21,21,26    Stop    Lecture sur tty en arrière-plan.
       SIGTTOU   22,22,27    Stop    Écriture sur tty 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.
       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ée à des fins spécifiques à
       l'application.  (Notez  quand  même  que  l'implémentation  LinuxThreads utilise les trois
       premiers signaux temps-réel).

       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(2), 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), 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,  quand une temporisation a été définie sur la socket en
             utilisant setsockopt(2) ; accept(2), recv(2), recvfrom(2) et recvmsg(2), si un délai
             de  réception  (SO_RCVTIMEO)  a  été  défini ;  connect(2),  send(2),  sendto(2)  et
             sendmsg(2), si un délai de transmission (SO_SNDTIMEO) a été défini.

           * 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,  quand une temporisation a été définie sur la socket en
             utilisant setsockopt(2) ; accept(2), recv(2), recvfrom(2) et recvmsg(2), si un délai
             de  réception  (SO_RCVTIMEO)  a  été  défini ;  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.

BOGUES

       SIGIO et SIGLOST ont la même valeur, le dernier est mis en commentaire dans les sources du
       noyau, mais certaines applications considèrent encore que le signal 29 est SIGLOST.

VOIR AUSSI

       kill(1),  getrlimit(2),  kill(2),  killpg(2),  setitimer(2),  setrlimit(2),   sgetmask(2),
       sigaction(2),   sigaltstack(2),  signal(2),  signalfd(2),  sigpending(2),  sigprocmask(2),
       sigqueue(2), sigsuspend(2), sigwaitinfo(2), abort(3), bsd_signal(3), longjmp(3), raise(3),
       pthread_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.32 du projet man-pages Linux.  Une  description
       du  projet  et  des  instructions  pour  signaler  des  anomalies  peuvent être trouvées à
       l'adresse <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

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

       Christophe  Blaess  <URL:http://www.blaess.fr/christophe/>   (1996-2003),   Alain   Portal
       <URL: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     à
       <debian-l10n-french@lists.debian.org>   ou   par   un  rapport  de  bogue  sur  le  paquet
       manpages-fr.

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