Provided by:
manpages-fr_3.32d0.2p4-1_all 
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> >>.