Provided by:
manpages-fr_2.80.1-1_all 
NOM
signal - Liste des signaux disponibles.
DESCRIPTION
Linux supporte supporte à 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 (voir
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 (de façon moins portable) signal(2). 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 reçu.
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.
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 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.
Signaux standards
Linux supporte 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, PPC 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 » (Système V).
Synonyme de SIGIO.
SIGPROF 27,27,29 Term Expiration de la temporisation
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 (Système 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 systèmes 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). 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 (voir 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).
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
Une fonction configurée par sigaction(2) ou signal(2) pour la gestion
d’un signal doit prendre beaucoup de précautions, puisqu’elle 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-2003 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()
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()
CONFORMITÉ
POSIX.1
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), kill(2), killpg(2), setitimer(2), setrlimit(2), sgetmask(2),
sigaction(2), signal(2), signalfd(2), sigpending(2), sigprocmask(2),
sigqueue(2), sigsuspend(2), sigwaitinfo(2), bsd_signal(3), raise(3),
sigvec(3), sigset(3), strsignal(3), sysv_signal(3), core(5), proc(5),
pthreads(7)
COLOPHON
Cette page fait partie de la publication 2.80 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent être trouvées à l’adresse
http://www.kernel.org/doc/man-pages/.
TRADUCTION
Cette page de manuel a été traduite et mise à jour par Christophe
Blaess <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis par
Alain Portal <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et mise Ã
disposition sur http://manpagesfr.free.fr/.
Les mises à jour et corrections de la version présente dans Debian sont
directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
francophone de traduction de Debian.
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> ».