SIGNAL(7)

NOM
signal - Liste des signaux disponibles

DESCRIPTION
Linux supporte supporte à la fois les signaux POSIX classiques (« signaux standard ») et les signaux POSIX temps réel.

  Dispositions de signaux
Chaque signal a une disposition courante qui détermine comment le processus se comporte lorsqu'un signal lui est délivré. Les symboles de la colonne « Action » des tables ci-dessous spécifient la disposition par défaut pour chaque signal :

Term
    Par défaut, terminer le processus.

Ign Par défaut, ignorer le signal.

Core
    Par défaut, terminer le processus et créer un fichier core (voir core(5)).

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

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

Un processus peut modifier la disposition d'un signal avec sigaction(2) ou (moins portable) signal(2). En utilisant ces appels système, un processus peut choisir de faire survenir l'un des comportements suivants à la délivrance d'un signal : effectuer l'action par défaut ; ignorer le signal ; capturer le signal avec un gestionnaire de signaux, une fonction définie par le programmeur qui est automatiquement invoquée lorsque le signal est délivré. La disposition d'un signal est un attribut par proceessus : dans une application multithread, la disposition d'un signal particulier est la même pour tous les threads.

  Masque de signaux et signaux en attente
Un signal peut être bloqué, ce qui signifie qu'il ne sera pas délivré tant qu'il n'aura pas été débloqué. Entre le moment où il est généré et celui où il est délivré, un signal est dit en attente. Chaque thread d'un processus a un masque de signaux indépendant, qui indique l'ensemble de signaux que le thread bloque actuellement. Un thread peut manipuler son masque de signaux avec pthread_sigmask(3). Dans une application traditionnelle simple thread, sigprocmask(2) peut être utilisée pour manipuler le masque de signaux. Un signal peut être généré (et ainsi être mis en attente) pour un processus comme un ensemble (par exemple, lorsqu'il est émis avec kill(2)) ou pour un thread particulier (par exemple, certains signaux, comme SIGSEGV ou SIGFPE, générés comme la conséquence de l'exécution d'une instruction particulière en langage machine, sont adressés à un thread, comme sont les signaux ciblés sur un thread particulier avec pthread_kill(3)). Un signal adressé à un processus peut être délivré à n'importe lequel des threads qui n'a pas de signaux bloqués. Si plus d'un thread a un signal débloqué, le noyau choisit arbitrairement un thread auquel délivrer le signal. Un thread peut obtenir l'ensemble des signaux en attente avec sigpending(2). Cet ensemble consiste en la réunion d l'ensemble des signaux en attente adressés au processus et l'ensemble des signaux en attente du thread appelant.

  Signaux standard
Linux supporte les signaux standard ci-dessous. Plusieurs numéros de signaux sont dépendants de l'architecture, comme indiqué dans la colonne « Valeur ». (Où trois valeurs sont fournies, la première est généralement valide pour alpha et sparc, celle du milieu pour ix386, ia64, ppc, s390, arm et sh, et la dernière pour mips. Un - indique que le signal est absent de 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 | Raccrochement (déconnexion) sur 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 être 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 SUSv3 / POSIX.1-2001 :
Signal | Valeur | Action | Commentaire
SIGBUS | 10,7,10 | Core | Erreur de Bus.
SIGPOLL |  | Term | Synonyme de SIGIO (System V).
SIGPROF | 27,27,29 | Term | Horloge pour le suivi
SIGSYS | 12,-,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,- | Term | Signal inutilisé (sera 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 Unix.

  Signaux temps réel
Linux supporte les signaux temps réel tels qu'ils ont été définis à l'origine dans les extentions temps réel POSIX.1b (et inclus à présent dans POSIX.1-2001). Linux supporte 32 signaux temps réel numérotés de 32 (SIGRTMIN) à 63 (SIGRTMAX). (Les applications doivent toujours se référer aux signaux temps réel en utilisant la notation SIGRTMIN+n, car la plage des numéros des signaux varie suivant les Unix).

Contrairement aux signaux standard, les signaux temps réel n'ont pas de signification prédéfinie : l'ensemble complet de ces signaux peut être utilisé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 standard sont en attente dans un processus, l'ordre dans lequel ils sont délivrés n'est pas défini.

Si des signaux standard et des signaux temps réel sont simultanément en attente pour un processus, POSIX ne précise pas 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 pour un processus. Néanmoins, Linux fait les choses différemment. Dans les noyaux jusqu'au 2.6.7 compris, 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é par la limite de ressources RLIMIT_SIGPENDING, qui indique une limite par utilisateur pour les signaux en file d'attente ; voir setrlimit(2) pour plus de détails.

  Fonctions sûres pour signaux asynchrones

Une routine de gestion de signaux établit par sigaction(2) ou signal(2) doit prendre beaucoup de précautions puisqu'elle peut interrompre n'importe où le programme. POSIX définit le concept de « fonction sûre ». Si un signal interrompt l'exécution d'une fonction non sûre et que le gestionnaire appelle une fonction non sûre, le comportement du programme est indéterminé. POSIX.1-2004 (également appelée « POSIX.1-2001 Technical Corrigendum 2 ») demande qu'une implémentation garantisse que les fonctions suivantes puissent être appelées sans risque à l'intérieur d'un gestionnaire de signaux :
_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()

  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 (voir 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 ; voir 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).

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

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

    *   Intefaces 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 ait é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 :

    *   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), sigset(3), sigsetops(3), sigvec(3), sigwait(3), strsignal(3), sysv_signal(3), core(5), proc(5), pthreads(7)

TRADUCTION

Ce document est une traduction réalisée par Christophe Blaess <http://www.blaess.fr/christophe/> le 19 octobre 1996 et révisée le 17 juillet 2008.

L'équipe de traduction a fait le maximum pour réaliser une adaptation française de qualité. La version anglaise la plus à jour de ce document est toujours consultable via la commande : « LANG=C man 7 signal ». N'hésitez pas à signaler à l'auteur ou au traducteur, selon le cas, toute erreur dans cette page de manuel.