signal(7) Miscellaneous Information Manual signal(7)
NOM
signal - Panorama des signaux
DESCRIPTION
Linux prend en charge a la fois les signaux POSIX classiques
(<< ci-apres signaux standard >>) et les signaux POSIX temps reel.
Action des signaux
Chaque signal a une action en vigueur qui determine le comportement du
processus lorsqu'il recoit ce signal.
Les elements 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, terminer le processus et creer un fichier d'image
memoire (consultez core(5)).
Stop Par defaut, arreter le processus.
Cont Par defaut, continuer le processus s'il est actuellement arrete.
Un processus peut changer l'action d'un signal avec sigaction(2) ou
signal(2) (la deuxieme option est moins portable quand un gestionnaire
de signal est defini ; 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 un signal : effectuer l'action
par defaut, ignorer le signal ou intercepter 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
transmis.
Par defaut, le gestionnaire de signal est appele sur la pile normale
des processus. Il est possible de prevoir que le gestionnaire de signal
utilise une autre pile ; consultez sigaltstack(2) pour une discussion
sur comment faire cela et quand cela pourrait etre utile.
L'action d'un signal est un attribut du processus : dans une
application multithreadee, l'action d'un signal particulier est la meme
pour tous les threads.
Un enfant cree par fork(2) herite d'une copie des actions des signaux
de son parent. Lors d'un execve(2), les actions des signaux pris en
charge sont remises aux valeurs par defaut ; les actions des signaux
ignores ne sont pas modifiees.
Envoyer un signal
Les appels systeme et les fonctions de bibliotheque qui suivent
permettent a l'appelant d'envoyer un signal :
raise(3)
Envoyer un signal au thread appelant.
kill(2)
Envoyer un signal au processus indique, a tous les membres du
groupe de processus indique ou a tous les processus du systeme.
pidfd_send_signal(2)
Envoyer un signal a un processus identifie par un descripteur de
fichier de PID.
killpg(3)
Envoyer un signal a tous les membres du groupe de processus
indique.
pthread_kill(3)
Envoyer un signal au thread POSIX indique dans le meme processus
que l'appelant.
tgkill(2)
Envoyer un signal au thread indique a l'interieur d'un processus
donne (c'est l'appel systeme utilise pour implementer
pthread_kill(3)).
sigqueue(3)
Envoyer 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 thread appelant
jusqu'a ce qu'un signal soit recu (ou qu'un signal non pris en charge
termine le processus) :
pause(2)
Suspendre l'execution jusqu'a ce que n'importe quel signal soit
recu.
sigsuspend(2)
Changer temporairement le masque de signaux (voir ci-dessous) et
suspendre l'execution jusqu'a ce qu'un des signaux non masque
soit recu.
Accepter un signal de facon synchrone
Au lieu d'intercepter un signal de facon asynchrone avec un
gestionnaire de signal, il est possible de l'accepter de facon
synchrone, c'est-a-dire de bloquer l'execution jusqu'a ce que le signal
soit distribue. A ce moment, le noyau renvoie des informations
concernant le signal a l'appelant. Il y a deux facons generales 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 les informations concernant les signaux qui sont
distribues a l'appelant. Chaque read(2) dans ce descripteur de
fichier est bloquant jusqu'a ce que un des signaux de l'ensemble
indique dans l'appel 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 bloque, ce qui signifie qu'il ne sera pas envoye
avant d'etre debloque. Entre le moment de sa creation et celui de son
envoi, 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 enfant cree avec fork(2) herite d'une copie du masque de
signaux de son parent. Le masque de signaux est conserve au travers
d'un execve(2).
Un signal peut etre << oriente processus >> ou << oriente thread >>. Un
signal oriente processus est un signal qui cible (et par consequent en
attente pour) le processus dans son entier. Il peut l'etre parce qu'il
a ete genere par le noyau pour des raisons autres qu'une exception
materielle ou parce qu'il a ete envoye en utilisant kill(2) ou
sigqueue(3). Un signal oriente thread est destine a un thread
particulier. Un tel signal peut l'etre parce qu'il a ete genere en
consequence de l'execution d'une instruction specifique de code machine
qui est declenchee par une exception materielle (par exemple, SIGSEGV
pour un acces memoire non autorise ou SIGFPE pour une erreur
mathematique) ou parce qu'il visait un thread particulier en utilisant
une interface telle que tgkill(2) ou pthread_kill(3).
Un signal oriente processus peut etre delivre a n'importe quel des
threads qui n'ont pas presentement le signal bloque. Si plus d'un des
threads a le signal non bloque, alors le noyau choisit un thread
arbitraire auquel delivrer le signal.
Un thread peut obtenir l'ensemble des signaux actuellement en attente
en utilisant sigpending(2). Cet ensemble est l'union de l'ensemble des
signaux en attente orientes processus et l'ensemble des signaux en
attente pour le thread appelant.
Un enfant cree avec fork(2) debute avec un ensemble de signaux en
attente vide. L'ensemble de signaux en attente est conserve au travers
d'un execve(2).
Execution des gestionnaires de signal
A chaque transition d'une execution en mode noyau vers une en mode
utilisateur (par exemple, lors du retour d'un appel systeme ou
l'ordonnancement d'un thread sur le CPU), le noyau verifie s'il existe
un signal en attente non bloque pour lequel le processus a etabli un
gestionnaire de signal. Si un tel signal est en attente, les etapes
suivantes se deroulent :
(1) Le noyau realise les etapes preparatoires necessaires pour
l'execution du gestionnaire de signal :
(1.1) Le signal est supprime de l'ensemble des signaux en
attente.
(1.2) Si le gestionnaire de signal a ete installe par un appel a
sigaction(2) qui est precise par l'indicateur SA_ONSTACK et
que le thread a defini une pile de signaux de remplacement
(en utilisant sigaltstack(2)), alors cette pile est
installee.
(1.3) Diverses pieces du contexte relatif au signal sont
enregistrees dans une structure speciale qui est creee dans
la pile. Les informations enregistrees comprennent :
- le registre de compteur du programme (c'est-a-dire
l'adresse de la prochaine instruction dans le programme
principal qui devrait etre executee lors du renvoi du
gestionnaire de signal) ;
- l'etat du registre specifique a l'architecture
necessaire pour reprendre le programme interrompu ;
- le masque de signaux du thread actuel ;
- les parametres de la pile de signaux de remplacement du
thread.
(Si le gestionnaire de signal a ete installe en utilisant
l'indicateur SA_SIGINFO de sigaction(2), alors les
informations ci-dessus sont accessibles a l'aide de l'objet
ucontext_t qui est pointe par le troisieme argument du
gestionnaire de signal.)
(1.4) Tout signal precise dans act->sa_mask lors de
l'enregistrement du gestionnaire avec sigprocmask(2) est
ajoute au masque de signaux du thread. Le signal a
transmettre est aussi ajoute au masque de signaux a moins
que SA_NODEFER ait ete precise lors de l'enregistrement du
gestionnaire. Ces signaux sont alors bloques pendant que le
gestionnaire realise l'execution.
(2) Le noyau construit une structure pour le gestionnaire de signal
sur la pile. Le noyau regle le compteur du programme pour le
thread pour pointer a la premiere instruction de la fonction du
gestionnaire de signal et configure l'adresse de retour pour cette
fonction pour pointer vers un element du code de l'espace
utilisateur connu comme << trampoline de signal >> (decrit dans
sigreturn(2)).
(3) Le noyau repasse le controle a l'espace utilisateur ou l'execution
commence au debut de la fonction du gestionnaire de signal.
(4) Au renvoi du gestionnaire de signal, le controle passe au
trampoline de signal.
(5) Le trampoline de signal appelle sigreturn(2), un appel systeme qui
utilise les informations dans la structure de la pile creee a la
premiere etape pour restaurer le thread dans son etat avant que le
gestionnaire de signal ait ete appele. Les parametres du masque de
signaux du thread et de la pile de signaux de remplacement sont
restaures dans le cadre de cette procedure. A la fin de l'appel a
sigreturn(2), le noyau transfere le controle a l'espace
utilisateur et le thread recommence l'execution a partir du point
ou elle a ete interrompue par le gestionnaire de signal.
Remarquez que si le gestionnaire de signal ne renvoie pas (par exemple,
le controle est transfere en dehors du gestionnaire en utilisant
siglongjmp(3) ou le gestionnaire execute un nouveau programme avec
execve(2)), alors l'etape finale n'est par realisee. En particulier,
dans de tels scenarios, c'est la responsabilite du programmeur de
restaurer l'etat du masque de signaux (en utilisant sigprocmask(2)) si
le deblocage des signaux, qui etaient bloques par une entree dans le
gestionnaire de signal, est desire. (Notez que siglongjmp(3) peut ou ne
peut pas restaurer le masque de signaux en fonction de la valeur
savesigs qui etait indiquee dans l'appel correspondant a sigsetjmp(3).)
Du point de vue du noyau, l'execution du code du gestionnaire de signal
est exactement la meme que celle n'importe quel code de l'espace
utilisateur. C'est-a-dire que le noyau n'enregistre aucune information
speciale d'etat indiquant que le thread est actuellement en execution a
l'interieur d'un gestionnaire de signal. Toutes les informations d'etat
necessaires sont entretenues dans des registres de l'espace utilisateur
et la pile de l'espace utilisateur. La profondeur a laquelle les
gestionnaires de signaux imbriques peuvent etre invoques est donc
limitee seulement par la pile de l'espace utilisateur (et une
conception logicielle raisonnable).
Signaux standard
Linux prend en charge les signaux standard listes ci-dessous. La
seconde colonne du tableau indique quelle norme (si elle existe) decrit
le signal : << P1990 >> indique que le signal est decrit dans la norme
POSIX.1-1990 originelle. << P2001 >> indique que le signal a ete ajoute
dans SUSv2 et POSIX.1-2001.
Signal Norme Action Commentaire
-----------------------------------------------------------------------------------
SIGABRT P1990 Core Signal d'arret d'abort(3)
SIGALRM P1990 Term Signal de temporisation d'alarm(2)
SIGBUS P2001 Core Erreur de bus (mauvais acces memoire)
SIGCHLD P1990 Ign Enfant arrete ou termine
SIGCLD - Ign Synonyme pour SIGCHLD
SIGCONT P1990 Cont Continuer si arrete
SIGEMT - Term Interception (trap) d'emulateur
SIGFPE P1990 Core Exception de virgule flottante
SIGHUP P1990 Term Deconnexion detectee sur le terminal de
controle ou mort du processus de controle
SIGILL P1990 Core Instruction illegale
SIGINFO - Synonyme pour SIGPWR
SIGINT P1990 Term Interruption depuis le clavier
SIGIO - Term E/S maintenant possible (4.2BSD)
SIGIOT - Core Interception IOT - synonyme pour SIGABRT
SIGKILL P1990 Term Signal d'arret
SIGLOST - Term Perte de verrou de fichier (inutilise)
SIGPIPE P1990 Term Tube brise : ecriture dans un tube sans
lecteur - voir pipe(7)
SIGPOLL P2001 Term Evenement scrutable (System V)
- synonyme pour SIGIO
SIGPROF P2001 Term Fin d'une temporisation de profilage
SIGPWR - Term Panne d'alimentation (System V)
SIGQUIT P1990 Core Quitter depuis le clavier
SIGSEGV P1990 Core Reference memoire non valable
SIGSTKFLT - Term Erreur de pile sur coprocesseur (inutilise)
SIGSTOP P1990 Stop Processus d'arret
SIGTSTP P1990 Stop Stop saisi sur le terminal
SIGSYS P2001 Core Mauvais appel systeme (SVr4)
- voir aussi seccomp(2)
SIGTERM P1990 Term Signal de fin
SIGTRAP P2001 Core Interception pour trace ou pour point d'arret
SIGTTIN P1990 Stop Entree du terminal pour processus en arriere-plan
SIGTTOU P1990 Stop Sortie du terminal pour processus en arriere-plan
SIGUNUSED - Core Synonyme pour SIGSYS
SIGURG P2001 Ign Condition urgente sur un socket (4.2BSD)
SIGUSR1 P1990 Term Signal utilisateur 1
SIGUSR2 P1990 Term Signal utilisateur 2
SIGVTALRM P2001 Term Horloge virtuelle d'alarme (4.2BSD)
SIGXCPU P2001 Core Limite de temps CPU depassee (4.2BSD)
Consultez setrlimit(2)
SIGXFSZ P2001 Core Taille de fichier excessive (4.2BSD)
Consultez setrlimit(2)
SIGWINCH - Ign Fenetre redimensionnee (4.3BSD, Sun)
Les signaux SIGKILL et SIGSTOP ne peuvent etre ni captures, ni bloques,
ni ignores.
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 image memoire.
(Sur certains UNIX, l'action par defaut pour SIGXCPU et SIGXFSZ est de
finir le processus sans fichier image memoire.) Linux 2.4 se conforme a
POSIX.1-2001 pour ces signaux et termine le processus avec un fichier
image memoire.
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 image memoire.
SIGPWR (non specifie dans POSIX.1-2001) est typiquement ignore sur les
autres UNIX ou il apparait.
SIGIO (non specifie par POSIX.1-2001) est ignore par defaut sur
plusieurs autres systemes UNIX.
Semantiques d'attente et de distribution pour les signaux standard
Si plusieurs signaux standard sont en attente pour un processus,
l'ordre dans lequel les signaux sont distribues n'est pas precise.
Les signaux standard ne sont pas mis en file d'attente. Si plusieurs
instances d'un signal standard sont generees pendant que ce signal est
bloque, alors une seule instance du signal est marquee comme en attente
(et le signal sera distribue une seule fois une fois debloque). Dans le
cas ou un signal standard est deja en attente, la structure siginfo_t
(consultez sigaction(2)) associee a ce signal n'est pas ecrasee lors de
l'arrivee d'instances suivantes du meme signal. Par consequent, le
processus recevra les informations associees a la premiere instance du
signal.
Numerotation pour les signaux standard
La valeur numerique de chaque signal est donnee dans la table
ci-dessous. Comme montres dans cette table, plusieurs signaux ont des
valeurs numeriques differentes sur des architectures differentes. La
premiere valeur dans chaque ligne indique le numero de signal sur x86,
ARM et la plupart des autres architectures. La seconde valeur indique
celui pour Alpha et SPARC. La troisieme indique celui de MIPS et la
derniere celui de PA-RISC. Un tiret (-) indique que le signal est
absent sur l'architecture correspondante.
Signal x86/ARM et la Alpha/ MIPS PA-RISC Notes
plupart des arch. SPARC
-------------------------------------------------------------------------
SIGHUP 1 1 1 1
SIGINT 2 2 2 2
SIGQUIT 3 3 3 3
SIGILL 4 4 4 4
SIGTRAP 5 5 5 5
SIGABRT 6 6 6 6
SIGIOT 6 6 6 6
SIGBUS 7 10 10 10
SIGEMT - 7 7 -
SIGFPE 8 8 8 8
SIGKILL 9 9 9 9
SIGUSR1 10 30 16 16
SIGSEGV 11 11 11 11
SIGUSR2 12 31 17 17
SIGPIPE 13 13 13 13
SIGALRM 14 14 14 14
SIGTERM 15 15 15 15
SIGSTKFLT 16 - - 7
SIGCHLD 17 20 18 18
SIGCLD - - 18 -
SIGCONT 18 19 25 26
SIGSTOP 19 17 23 24
SIGTSTP 20 18 24 25
SIGTTIN 21 21 26 27
SIGTTOU 22 22 27 28
SIGURG 23 16 21 29
SIGXCPU 24 24 30 12
SIGXFSZ 25 25 31 30
SIGVTALRM 26 26 28 20
SIGPROF 27 27 29 21
SIGWINCH 28 28 20 23
SIGIO 29 23 22 22
SIGPOLL Idem a SIGIO
SIGPWR 30 29/- 19 19
SIGINFO - 29/- - -
SIGLOST - -/29 - -
SIGSYS 31 12 12 31
SIGUNUSED 31 - - 31
Il est a noter que :
- si defini, SIGUNUSED est synonyme de SIGSYS. Depuis la glibc 2.26,
SIGUNUSED n'est plus defini sur toutes les architectures ;
- le signal 29 est SIGINFO/SIGPWR (synonymes pour la meme valeur) sur
Alpha mais SIGLOST sur SPARC.
Signaux temps reel
Starting with Linux 2.2, Linux supports real-time signals as originally
defined in the POSIX.1b real-time extensions (and now included in
POSIX.1-2001). The range of supported real-time signals is defined by
the macros SIGRTMIN and SIGRTMAX. POSIX.1-2001 requires that an
implementation support at least _POSIX_RTSIG_MAX (8) real-time signals.
Le noyau Linux gere une gamme de 33 signaux temps reel differents,
numerotes de 32 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 reference a des
signaux temps reel en utilisant des numeros codes en dur, mais
devraient toujours a la place utiliser des signaux temps reel avec la
notation SIGRTMIN+n avec des verifications adequates (lors de
l'execution) que SIGRTMIN+n ne depasse pas SIGRTMAX.
Contrairement aux signaux standard, les signaux temps reel n'ont pas de
signification predefinie : l'ensemble complet de ces signaux peut etre
utilise a des fins specifiques a l'application.
L'action par defaut pour un signal temps reel non gere est de terminer
le processus recepteur.
Les signaux temps reel se distinguent de la facon suivante :
- Plusieurs instances d'un signal temps reel peuvent etre mises en
file d'attente. Au contraire, si plusieurs instances d'un signal
standard arrivent alors qu'il est presentement bloque, une seule
instance sera mise en file d'attente.
- Si le signal est envoye en utilisant sigqueue(3), il peut etre
accompagne d'une valeur (un entier ou un pointeur). Si le processus
recepteur positionne un gestionnaire pour ce signal en utilisant
l'attribut SA_SIGINFO pour 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 du signal.
- 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 (c'est-a-dire le signal de plus fort numero est celui
de priorite la plus faible). Par contre, si plusieurs signaux
standard sont en attente pour un processus, l'ordre dans lequel ils
sont delivres n'est pas defini.
Si des signaux standard et des signaux temps reel sont simultanement en
attente pour un processus, POSIX ne precise pas l'ordre de delivrance.
Linux, comme beaucoup d'autres implementations, donne priorite aux
signaux standard dans ce cas.
According to POSIX, an implementation should permit at least
_POSIX_SIGQUEUE_MAX (32) real-time signals to be queued to a process.
However, Linux does things differently. Up to and including Linux
2.6.7, Linux imposes a system-wide limit on the number of queued
real-time signals for all processes. This limit can be viewed and
(with privilege) changed via the /proc/sys/kernel/rtsig-max file. A
related file, /proc/sys/kernel/rtsig-nr, can be used to find out how
many real-time signals are currently queued. In Linux 2.6.8, these
/proc interfaces were replaced by the RLIMIT_SIGPENDING resource limit,
which specifies a per-user limit for queued signals; see setrlimit(2)
for further details.
L'ajout de signaux temps reel necessite l'agrandissement de la
structure de l'ensemble des signaux (sigset_t) de 32 a 64 bits. Par
consequent, divers appels systeme ont ete supplantes par de nouveaux
appels systeme qui gerent des ensembles de signaux plus grands. Les
anciens et nouveaux appels systeme sont les suivants :
Linux 2.0 et anterieurs Linux 2.2 et posterieurs
sigaction(2) rt_sigaction(2)
sigpending(2) rt_sigpending(2)
sigprocmask(2) rt_sigprocmask(2)
sigreturn(2) rt_sigreturn(2)
sigsuspend(2) rt_sigsuspend(2)
sigtimedwait(2) rt_sigtimedwait(2)
Interruption d'appel et de fonction par un gestionnaire 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 renvoi 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 en attente a l'une des interfaces suivantes est interrompu
par un gestionnaire de signal, l'appel sera automatiquement redemarre
apres le renvoi du gestionnaire de signal si l'attribut SA_RESTART a
ete indique ; autrement, l'appel echouera avec l'erreur EINTR :
- 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'E/S peut bloquer pendant un temps
indefini, par exemple un terminal, un tube ou un socket. Si un appel
d'E/S sur un peripherique lent a deja transfere des donnees au
moment ou il est interrompu par un gestionnaire de signal, l'appel
renverra une indication de succes (normalement, le nombre d'octets
transferes). Remarquez que selon cette definition, un disque (local)
n'est pas un peripherique lent. Les operations d'E/S sur les
peripheriques disque ne sont pas interrompues par des signaux.
- 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 socket : accept(2), connect(2), recv(2), recvfrom(2),
recvmmsg(2), recvmsg(2), send(2), sendto(2) et sendmsg(2), a moins
qu'une temporisation n'ait ete placee sur le socket (voir
ci-dessous).
- Interfaces de blocage de fichier : flock(2) et les operations
F_SETLKW et F_OFD_SETLKW de 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,
elle echouait toujours avec l'erreur EINTR).
- getrandom(2).
- pthread_mutex_lock(3), pthread_cond_wait(3) et autres API
apparentees.
- FUTEX_WAIT_BITSET de futex(2.
- Interfaces de semaphores POSIX : sem_wait(3) et sem_timedwait(3)
(depuis Linux 2.6.22 ; auparavant, elles echouaient toujours avec
l'erreur EINTR).
- read(2) d'un descripteur de fichier d'inotify(7) (depuis Linux 3.8 ;
auparavant, elle 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 :
- Interfaces de socket << entree >>, quand un delai de reception
(SO_RCVTIMEO) a ete defini sur le socket en utilisant
setsockopt(2) : accept(2), recv(2), recvfrom(2), recvmmsg(2) (aussi
avec un parametre timeout non NULL) et recvmsg(2).
- Interfaces de socket << sortie >>, quand un delai de reception
(SO_RCVTIMEO) a ete defini sur le socket en utilisant
setsockopt(2) : connect(2), send(2), sendto(2) et sendmsg(2).
- 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).
- io_getevents(2).
La fonction sleep(3) n'est egalement jamais relancee si elle est
interrompue par un gestionnaire, mais elle renvoie une indication de
succes : le nombre de secondes restantes pour le sommeil.
In certain circumstances, the seccomp(2) user-space notification
feature can lead to restarting of system calls that would otherwise
never be restarted by SA_RESTART; for details, see seccomp_unotify(2).
Interruption d'appel et de fonction par des signaux d'arret
Sous Linux, meme en l'absence de gestionnaire 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 :
- Interfaces de socket << entree >>, quand un delai de reception
(SO_RCVTIMEO) a ete defini sur le socket en utilisant
setsockopt(2) : accept(2), recv(2), recvfrom(2), recvmmsg(2) (aussi
avec un parametre timeout non NULL) et recvmsg(2).
- Les interfaces de socket << sortie >>, quand un delai de reception
(SO_RCVTIMEO) a ete defini sur le socket en utilisant
setsockopt(2) : 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).
- Linux 3.7 et anterieurs : 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).
STANDARDS
POSIX.1, sauf indication contraire.
NOTES
Pour une discussion sur les fonctions sures de signal asynchrone,
consultez signal-safety(7).
The /proc/pid/task/tid/status file contains various fields that show
the signals that a thread is blocking (SigBlk), catching (SigCgt), or
ignoring (SigIgn). (The set of signals that are caught or ignored will
be the same across all threads in a process.) Other fields show the
set of pending signals that are directed to the thread (SigPnd) as well
as the set of pending signals that are directed to the process as a
whole (ShdPnd). The corresponding fields in /proc/pid/status show the
information for the main thread. See proc(5) for further details.
BOGUES
Six signaux existent qui peuvent etre delivres a cause d'une exception
materielle : SIGBUS, SIGEMT, SIGFPE, SIGILL, SIGSEGV et SIGTRAP. Lequel
de ces signaux est delivre pour n'importe quelle exception materielle
n'est pas documente et semble parfois ne pas etre logique.
Par exemple, un acces memoire non autorise qui provoque l'envoi de
SIGSEGV sur une architecture peut provoquer l'envoi de SIGBUS sur une
autre architecture ou vice versa.
Comme autre exemple, l'utilisation de l'instruction int de x86 avec un
argument interdit (tout nombre autre que 3 ou 128) provoque l'envoi de
SIGSEGV meme si SIGILL serait plus adapte a cause de la facon dont le
CPU rapporte l'operation interdite au noyau.
VOIR AUSSI
kill(1), clone(2), getrlimit(2), kill(2), pidfd_send_signal(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), sigreturn(2), sigsuspend(2),
sigwaitinfo(2), abort(3), bsd_signal(3), killpg(3), longjmp(3),
pthread_sigqueue(3), raise(3), sigqueue(3), sigset(3), sigsetops(3),
sigvec(3), sigwait(3), strsignal(3), swapcontext(3), sysv_signal(3),
core(5), proc(5), nptl(7), pthreads(7), sigevent(3type)
TRADUCTION
La traduction francaise de cette page de manuel a ete creee par
Christophe Blaess , Stephan Rafin
, Thierry Vignaud ,
Francois Micaux, Alain Portal , Jean-Philippe
Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas
Huriaux , Nicolas Francois
, Florentin Duneau
, Simon Paillard , Denis Barbier , David Prevot
, Cedric Boutillier ,
Frederic Hantrais et Jean-Paul Guillonneau
Cette traduction est une documentation libre ; veuillez vous reporter a
la GNU General Public License version 3
concernant les conditions
de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE.
Si vous decouvrez un bogue dans la traduction de cette page de manuel,
veuillez envoyer un message a .
Pages du manuel de Linux 6.06 31 octobre 2023 signal(7)