Manpages

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 :

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 :

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

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 :

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 architectures x86, Arm, ainsi que la majorité des autres architectures, et la dernière aux Mips. (Les valeurs pour l’architecture Parisc ne sont pas indiquées ; consultez les sources du noyau Linux pour la numérotation des signaux sur cette architecture.) 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 :

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 :

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 :

(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é à des fins spécifiques à l’application.

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 :

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 :

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

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 :

CONFORMITÉ

POSIX.1, sauf indication contraire.

VOIR AUSSI

kill(1), getrlimit(2), kill(2), killpg(2), restart_syscall(2), rt_sigqueueinfo(2), setitimer(2), setrlimit(2), sgetmask(2), sigaction(2), sigaltstack(2), signal(2), signalfd(2), sigpending(2), sigprocmask(2), sigsuspend(2), sigwaitinfo(2), abort(3), bsd_signal(3), longjmp(3), raise(3), pthread_sigqueue(3), 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.65 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

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

Christophe Blaess <http://www.blaess.fr/christophe/>; (1996-2003), Alain Portal <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 [AT] lists.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> ».