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

NOM

       signal - Panorama des signaux

DESCRIPTION

       Linux   prend  en  charge  a  la  fois  les  signaux  POSIX  classiques
       (<< signaux standards >>) et les signaux POSIX temps-reel.

   Dispositions de signaux
       Chaque signal a une disposition courante, qui determine le comportement
       du processus lorsqu'il recoit ce signal.

       Les  symboles  de la colonne << Action >> indiquent l'action par defaut
       pour chaque signal, avec la signification suivante :

       Term   Par defaut, terminer le processus.

       Ign    Par defaut, ignorer le signal.

       Core   Par defaut, creer un  fichier  core  et  terminer  le  processus
              (consultez core(5)).

       Stop   Par defaut, arreter le processus.

       Cont   Par defaut, continuer le processus s'il est actuellement arrete.

       Un  processus peut changer la disposition d'un signal avec sigaction(2)
       ou signal(2) (la deuxieme option est moins portable quand on definit un
       gestionnaire  de  signal ;  consultez signal(2)  pour plus de details).
       Avec ces appels systeme, un processus peut choisir de se  comporter  de
       l'une  des  facons  suivantes  lorsqu'il  recoit  ce signal : effectuer
       l'action par defaut, ignorer le signal, ou rattraper le signal avec  un
       gestionnaire  de  signal,  c'est-a-dire  une  fonction  definie  par le
       programme, qui est  invoquee  automatiquement  lorsque  le  signal  est
       distribue.  (Par  defaut,  le gestionnaire de signaux est appele 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  ca
       peut etre utile.)

       La  disposition  d'un  signal  est  un attribut du processus : dans une
       application multithreadee, la disposition d'un signal  particulier  est
       la meme pour tous les threads.

       Un fils cree par fork(2) herite d'une copie des dispositions de signaux
       de son pere. Lors d'un execve(2), les dispositions des signaux pris  en
       charge  sont  remises  aux  valeurs  par  defaut ; les dispositions des
       signaux ignores ne sont pas modifiees.

   Envoyer un signal
       Les appels  systeme  suivants  permettent  a  l'appelant  d'envoyer  un
       signal :

       raise(3)        Envoie un signal au thread appelant.

       kill(2)         Envoie  un  signal  au  processus  indique,  a tous les
                       membres du groupe de processus indique, ou a  tous  les
                       processus du systeme.

       killpg(2)       Envoie  un  signal  a  tous  les  membres  du groupe de
                       processus indique.

       pthread_kill(3) Envoie un signal au thread POSIX indique, dans le  meme
                       processus que l'appelant.

       tgkill(2)       Envoie  un signal au thread indique, a l'interieur d'un
                       processus  donne.  (C'est  l'appel  systeme  qui  etait
                       utilise pour implementer pthread_kill(3))

       sigqueue(2)     Envoie  un signal temps-reel, avec ses donnees jointes,
                       au processus indique.

   Attente de la capture d'un signal
       Les appels systeme suivants suspendent l'execution du processus  ou  du
       thread  appelant  jusqu'a ce qu'un signal soit attrape (ou qu'un signal
       non pris en charge termine le processus) :

       pause(2)        Suspend  l'execution  jusqu'a  ce  que  n'importe  quel
                       signal soit recu.

       sigsuspend(2)   Change   temporairement  le  masque  de  signaux  (voir
                       ci-dessous) et suspend l'execution jusqu'a ce qu'un des
                       signaux masque soit recu.

   Accepter un signal de fa,con synchrone
       Au lieu de rattraper un signal de facon asynchrone avec un gestionnaire
       de signal, il est possible  accepter  un  signal  de  facon  synchrone,
       c'est-a-dire  de  bloquer  l'execution  jusqu'a  ce  qu'un  signal soit
       distribue. A ce moment, le noyau renvoie des informations concernant le
       signal a l'appelant. Il y a deux facon generale pour faire cela :

       * sigwaitinfo(2),  sigtimedwait(2) et sigwait(3) suspendent l'execution
         jusqu'a ce qu'un des signaux dans l'ensemble indique soit  distribue.
         Chacun  de  ces  appels renvoie des informations concernant le signal
         distribue.

       * signalfd(2) renvoie un descripteur de fichier qui peut  etre  utilise
         pour  lire des informations concernant les signaux qui sont distribue
         a l'appelant. Chaque read(2)  dans  ce  descripteur  de  fichier  est
         bloquant   jusqu'a  ce  que  des  signaux  de  l'ensemble  fournit  a
         signalfd(2) soit  distribue  a  l'appelant.  Le  tampon  renvoye  par
         read(2) contient une structure qui decrit le signal.

   Masque de signaux et signaux en attente
       Un  signal peut etre bloqu'e, ce qui signifie qu'il ne sera pas recu par
       le processus avant d'etre debloque. Entre sa creation et sa  reception,
       le signal est dit en attente.

       Chaque  thread  d'un  processus a un masque de signaux independant, qui
       indique l'ensemble des signaux bloques par le thread.  Un  thread  peut
       modifier  son  masque  de  signaux  avec  pthread_sigmask(3).  Dans une
       application traditionnelle, a un seul thread, sigprocmask(2) peut  etre
       utilisee pour modifier le masque de signaux.

       Un  processus  fils  cree  avec fork(2) herite d'une copie du masque de
       signaux de son pere ; le masque de signaux est conserve au travers d'un
       execve(2).

       Un  signal  peut  etre  cree (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
       generes suite a une instruction particuliere  en  langage  machine,  et
       sont  diriges  vers  un  thread,  de  meme que les signaux envoyes avec
       pthread_kill(3)). Un signal envoye a un processus peut etre traite  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  envoyes
       au processus, et de ceux en attente pour le thread appelant.

       Un  fils  cree  avec  fork(2)  demarre  avec  un ensemble de signaux en
       attente vide ; l'ensemble de signaux en attente est conserve au travers
       d'un execve(2).

   Signaux standards
       Linux  prend  en  charge  les  signaux  standards  indiques ci-dessous.
       Plusieurs d'entre eux dependent de l'architecture,  comme  on  le  voit
       dans  la colonne << Valeur >>. Lorsque trois valeurs sont indiquees, la
       premiere correspond normalement aux architectures Alpha  et  Sparc,  la
       seconde  aux ix86, ia64, ppc, s390, arm et sh, et la derniere aux Mips.
       Un << - >> denote un signal absent pour l'architecture correspondante.

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

       Signal     Valeur    Action   Commentaire
       -----------------------------------------------------------------------
       SIGHUP        1       Term    Deconnexion detectee sur le terminal
                                     de controle ou mort du processus de
                                     controle.
       SIGINT        2       Term    Interruption depuis le clavier.
       SIGQUIT       3       Core    Demande << Quitter >> depuis le clavier.
       SIGILL        4       Core    Instruction illegale.
       SIGABRT       6       Core    Signal d'arret depuis abort(3).
       SIGFPE        8       Core    Erreur mathematique virgule flottante.
       SIGKILL       9       Term    Signal << KILL >>.
       SIGSEGV      11       Core    Reference memoire invalide.
       SIGPIPE      13       Term    Ecriture dans un tube sans
                                     lecteur.
       SIGALRM      14       Term    Temporisation alarm(2) ecoulee.
       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 arrete ou termine.
       SIGCONT   19,18,25    Cont    Continuer si arrete.
       SIGSTOP   17,19,23    Stop    Arret du processus.
       SIGTSTP   18,20,24    Stop    Stop invoque depuis tty.
       SIGTTIN   21,21,26    Stop    Lecture sur tty en arriere-plan.
       SIGTTOU   22,22,27    Stop    Ecriture sur tty en arriere-plan.

       Les signaux SIGKILL et SIGSTOP ne peuvent ni captures ni ignores.

       Ensuite,  les  signaux non decrits par POSIX.1-1990, mais presents dans
       les specifications SUSv2 et POSIX.1-2001 :

       Signal       Valeur    Action   Commentaire
       ------------------------------------------------------------------------
       SIGBUS      10,7,10     Core    Erreur de bus (mauvais acces memoire).
       SIGPOLL                 Term    Evenement << 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'arret rencontre.
       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 depassee (BSD 4.2).
       SIGXFSZ     25,25,31    Core    Taille de fichier excessive (BSD 4.2).

       Jusqu'a Linux 2.2 inclus, l'action par  defaut  pour  SIGSYS,  SIGXCPU,
       SIGXFSZ  et  (sur  les  architectures  autres que Sparc ou Mips) SIGBUS
       etait de terminer simplement le  processus,  sans  fichier  core.  (Sur
       certains UNIX, l'action par defaut pour SIGXCPU et SIGXFSZ est de finir
       le processus sans fichier core). Linux 2.4 se conforme  a  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    Arret IOT. Un synonyme de SIGABRT.
       SIGEMT       7,-,7      Term
       SIGSTKFLT    -,16,-     Term    Erreur   de   pile   sur  coprocesseur
                                       (inutilise).
       SIGIO       23,29,22    Term    E/S a 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     Fenetre redimensionnee (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 specifie par POSIX.1-2001 mais apparait neanmoins  sur
       la plupart des UNIX, avec une action par defaut typique correspondant a
       une fin du processus avec fichier core.

       SIGPWR (non specifie dans POSIX.1-2001) est typiquement ignore sur  les
       autres UNIX ou il apparait.

       SIGIO  (non  secifie  par  POSIX.1-2001)  est  ignore  par  defaut  sur
       plusieurs autres systemes UNIX.

       Si defini,  SIGUNUSED  est  synonyme  de  SIGSYS  sur  la  plupart  des
       architectures.

   Signaux temps-r'eel
       Linux  prend  en  charge  les  signaux  temps-reel  tels qu'ils ont ete
       definis a l'origine dans les extensions temps-reel POSIX.1b (et  inclus
       a  present  dans  POSIX.1-2001).  L'intervalle  des signaux temps-reels
       geres est defini par les  macros  SIGRTMIN  et  SIGRTMAX.  POSIX.1-2001
       exige  qu'une implementation gere au moins _POSIX_RTSIG_MAX (8) signaux
       temps-reels.

       Le noyau Linux gere une gamme de 32 signaux temps-reel, numerotes de 33
       a 64. Cependant, l'implementation des threads POSIX de la glibc utilise
       en  interne  deux  (pour  l'implementation   NPTL)   ou   trois   (pour
       l'implementation    LinuxThreads)    signaux    temps-reel   (consultez
       pthreads(7)) et ajuste la valeur de SIGRTMIN en consequence  (a  34  ou
       35).  Comme  la  gamme  de  signaux  temps-reel  varie  en  fonction de
       l'implementation des threads par la glibc (et cette implementation peut
       changer  a  l'execution  en fonction du noyau et de la glibc) et que la
       gamme de signaux  temps-reel  varie  bien  sur  egalement  suivant  les
       systemes UNIX, les programmes ne devraient jamais faire r'ef'erence `a des
       signaux temps-r'eel en utilisant des num'eros, mais devraient toujours  a
       la place utiliser des signaux temps-reel avec la notation SIGRTMIN+n en
       verifiant a l'execution que SIGRTMIN+n ne depasse pas SIGRTMAX.

       Contrairement aux signaux standards, les signaux temps-reel  n'ont  pas
       de  signification  predefinie :  l'ensemble complet de ces signaux peut
       etre utilisee a des fins specifiques a l'application. (Notez quand meme
       que  l'implementation  LinuxThreads  utilise les trois premiers signaux
       temps-reel).

       L'action par defaut pour  un  signal  temps-reel  non  capture  est  de
       terminer le processus recepteur.

       Les  signaux  temps-reel  se distinguent de leurs homologues classiques
       ainsi :

       1.  Plusieurs instances d'un signal temps-reel peuvent  etre  empilees.
           Au  contraire, si plusieurs instances d'un signal standard arrivent
           alors qu'il est bloque, une seule instance sera memorisee.

       2.  Si le signal est envoye en  utilisant  sigqueue(2),  il  peut  etre
           accompagne d'une valeur (un entier ou un pointeur). Si le processus
           recepteur  positionne  un  gestionnaire  en  utilisant   l'attribut
           SA_SIGINFO  de  l'appel  sigaction(2)  alors  il  peut acceder a la
           valeur transmise dans le champ si_value de la  structure  siginfo_t
           passee  en  second  argument  au  gestionnaire. De plus, les champs
           si_pid et si_uid de cette structure fournissent  le  PID  et  l'UID
           reel du processus emetteur.

       3.  Les  signaux  temps-reel  sont  delivres  dans un ordre precis. Les
           divers signaux temps-reel du meme type sont delivres  dans  l'ordre
           ou  ils ont ete emis. Si differents signaux temps-reel sont envoyes
           au processus, ils sont delivres en  commencant  par  le  signal  de
           numero  le  moins eleve (le signal de plus fort numero est celui de
           priorite  la  plus  faible).  Par  contre,  si  plusieurs   signaux
           standards  sont  en  attente dans un processus, l'ordre dans lequel
           ils sont delivres n'est pas defini.

       Si des signaux standards et des signaux temps-reel  sont  simultanement
       en  attente  pour  un  processus,  Posix  ne  precise  pas  d'ordre  de
       delivrance.  Linux,  comme  beaucoup  d'autres  implementations,  donne
       priorite aux signaux temps-reel dans ce cas.

       D'apres  POSIX,  une  implementation  doit  permettre l'empilement d'au
       moins _POSIX_SIGQUEUE_MAX (32) signaux temps-reel  pour  un  processus.
       Neanmoins,  Linux fonctionne differemment. Jusqu'au noyau 2.6.7 inclus,
       Linux impose une limite pour l'ensemble  des  signaux  empiles  sur  le
       systeme  pour  tous les processus. Cette limite peut etre consultee, et
       modifiee   (avec   les   privileges   adequats)   grace   au    fichier
       /proc/sys/kernel/rtsig-max.         Un         fichier         associe,
       /proc/sys/kernel/rtsig-nr, indique combien de signaux  temps-reel  sont
       actuellement  empiles.  Dans  Linux 2.6.8, ces interfaces /proc ont ete
       remplacees par la limite de ressources RLIMIT_SIGPENDING, qui  specifie
       une limite par utilisateur pour les signaux empiles ; voir setrlimit(2)
       pour plus de details.

   Fonctions pour signaux s^ur asynchrones
       Un  gestionnaire  de  signal  doit  prendre  beaucoup  de  precautions,
       puisqu'il  peut  interrompre  a  n'importe  quel endroit l'execution du
       programme. POSIX possede la notion  de  << fonctions  sures >>.  Si  un
       signal  interrompt  l'execution  d'une  fonction  non  sure,  et que le
       gestionnaire appelle une fonction non sure, alors  le  comportement  du
       programme n'est pas defini.

       POSIX.1-2004  (egalement  appelee << POSIX.1-2001 Technical Corrigendum
       2 >>)  impose  qu'une  implementation  garantisse  que  les   fonctions
       suivantes   puissent  etre  appelee  sans  risque  a  l'interieur  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`eme et des fonctions de biblioth`eque par des
       gestionnaires de signal
       Si un gestionnaire de signal est invoque pendant qu'un appel systeme ou
       une fonction de bibliotheque est bloque, alors :

       * soit  l'appel  est  automatiquement  redemarre  apres  le  retour  du
         gestionnaire de signal ;

       * soit l'appel echoue avec l'erreur EINTR.

       Lequel de ces deux comportements se produira depend de  l'interface  et
       de  si  le  gestionnaire  de  signal a ete mis en place avec l'attribut
       SA_RESTART (consultez sigaction(2)).  Les  details  varient  selon  les
       systemes UNIX ; voici ceux pour Linux.

       Si  un appel bloque a l'une des interfaces suivantes est interrompu par
       un gestionnaire de signal, l'appel sera automatiquement redemarre apres
       le  retour  du  gestionnaire  de  signal si l'attribut SA_RESTART a ete
       indique ; autrement, l'appel echouera avec l'erreur EINTR :

           * Les appels read(2), readv(2), write(2), writev(2) et ioctl(2) sur
             des  peripheriques << lents >>. Un peripherique << lent >> est un
             peripherique ou un appel d'entrees-sorties peut  bloquer  pendant
             un  temps infini, par exemple un terminal, un tube ou une socket.
             (Selon cette definition, un  disque  n'est  pas  un  peripherique
             lent.)  Si  un appel d'entrees-sorties sur un peripherique lent a
             deja transfere des donnees au moment ou il est interrompu par  un
             gestionnaire  de  signal,  l'appel  renverra  un  code  de succes
             (normalement, le nombre d'octets transferes).

           * 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),  a
             moins  qu'une  temporisation  n'ai ete placee sur la socket (voir
             ci-dessous).

           * Interfaces de verrouillage de fichiers :  operation  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).

           * Operation   FUTEX_WAIT   de   futex(2)   (depuis   Linux 2.6.22 ;
             auparavant, echouait toujours avec l'erreur EINTR).

           * Interfaces  de semaphores POSIX : sem_wait(3) et sem_timedwait(3)
             (depuis  Linux 2.6.22 ;  auparavant,   echouait   toujours   avec
             l'erreur EINTR).

       Les  interfaces  suivantes  ne  sont  jamais  relancees apres avoir ete
       interrompues  par  un  gestionnaire  de   signal,   quelle   que   soit
       l'utilisation  de  SA_RESTART ;  elles  echouent toujours avec l'erreur
       EINTR lorsqu'elles sont interrompues par un gestionnaire de signal :

           * Les interfaces de socket, quand une temporisation a  ete  definie
             sur  la  socket  en utilisant setsockopt(2) ; accept(2), recv(2),
             recvfrom(2) et recvmsg(2), si un delai de reception (SO_RCVTIMEO)
             a  ete  defini ; connect(2), send(2), sendto(2) et sendmsg(2), si
             un delai de transmission (SO_SNDTIMEO) a ete defini.

           * Interfaces  utilisees  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  egalement  jamais  relancee  si elle est
       interrompue par un gestionnaire, mais elle renvoie un code de retour de
       succes, le nombre de secondes restantes pour le sommeil.

   Interruption  des  appels  syst`eme et des fonctions de biblioth`eque par des
       signaux d'arr^et
       Sous Linux, meme en l'absence de  gestionnaires  de  signal,  certaines
       interfaces  en  mode bloquant peuvent echouer avec l'erreur EINTR apres
       que le processus a ete arrete par l'un des signaux d'arret  et  relance
       avec  le  signal SIGCONT. Ce comportement n'est pas ratifie par POSIX.1
       et n'apparait pas sur d'autres systemes.

       Les interfaces Linux qui affichent ce comportement sont :

           * Les interfaces de socket, quand une temporisation a  ete  definie
             sur  la  socket  en utilisant setsockopt(2) ; accept(2), recv(2),
             recvfrom(2) et recvmsg(2), si un delai de reception (SO_RCVTIMEO)
             a  ete  defini ; connect(2), send(2), sendto(2) et sendmsg(2), si
             un delai de transmission (SO_SNDTIMEO) a ete defini.

           * 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 anterieurs : operation  FUTEX_WAIT  de  futex(2),
             sem_timedwait(3), sem_wait(3).

           * Linux 2.6.8 et anterieurs : msgrcv(2), msgsnd(2).

           * Linux 2.4 et anterieurs : nanosleep(2).

CONFORMIT'E

       POSIX.1, sauf indication contraire.

BOGUES

       SIGIO  et SIGLOST ont la meme valeur, le dernier est mis en commentaire
       dans les sources du  noyau,  mais  certaines  applications  considerent
       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       etre       trouvees      a      l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis 2010, cette traduction est maintenue a l'aide  de  l'outil  po4a
       <URL:http://po4a.alioth.debian.org/>   par   l'equipe   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'equipe francophone de traduction de Debian (2006-2009).

       Veuillez   signaler   toute   erreur   de   traduction  en  ecrivant  a
       <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
       paquet manpages-fr.

       Vous  pouvez  toujours avoir acces a la version anglaise de ce document
       en utilisant la commande << man -L C <section> <page_de_man> >>.