.\" -*- coding: UTF-8 -*- '\" t .\" Copyright (c) 1993 by Thomas Koenig (ig25@rz.uni-karlsruhe.de) .\" and Copyright (c) 2002, 2006, 2020 by Michael Kerrisk .\" and Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk .\" .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" Modified Sat Jul 24 17:34:08 1993 by Rik Faith (faith@cs.unc.edu) .\" Modified Sun Jan 7 01:41:27 1996 by Andries Brouwer (aeb@cwi.nl) .\" Modified Sun Apr 14 12:02:29 1996 by Andries Brouwer (aeb@cwi.nl) .\" Modified Sat Nov 13 16:28:23 1999 by Andries Brouwer (aeb@cwi.nl) .\" Modified 10 Apr 2002, by Michael Kerrisk .\" Modified 7 Jun 2002, by Michael Kerrisk .\" Added information on real-time signals .\" Modified 13 Jun 2002, by Michael Kerrisk .\" Noted that SIGSTKFLT is in fact unused .\" 2004-12-03, Modified mtk, added notes on RLIMIT_SIGPENDING .\" 2006-04-24, mtk, Added text on changing signal dispositions, .\" signal mask, and pending signals. .\" 2008-07-04, mtk: .\" Added section on system call restarting (SA_RESTART) .\" Added section on stop/cont signals interrupting syscalls. .\" 2008-10-05, mtk: various additions .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH signal 7 "3 avril 2023" "Pages du manuel de Linux 6.05.01" .SH NOM signal – Panorama des signaux .SH DESCRIPTION Linux prend en charge à la fois les signaux POSIX classiques («\ ci\-après signaux standard\ ») et les signaux POSIX temps réel. .SS "Action des signaux" Chaque signal a une \fIaction\fP en vigueur qui détermine le comportement du processus lorsqu'il reçoit ce signal. .PP Les éléments de la colonne «\ Action\ » indiquent l'action par défaut pour chaque signal, avec la signification suivante\ : .TP Term Par défaut, terminer le processus. .TP Ign Par défaut, ignorer le signal. .TP Core Par défaut, terminer le processus et créer un fichier d'image mémoire (consultez \fBcore\fP(5)). .TP Stop Par défaut, arrêter le processus. .TP Cont Par défaut, continuer le processus s'il est actuellement arrêté. .PP Un processus peut changer l’action d'un signal avec \fBsigaction\fP(2) ou \fBsignal\fP(2) (la deuxième option est moins portable quand un gestionnaire de signal est défini\ ; consultez \fBsignal\fP(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 un signal\ : effectuer l'action par défaut, ignorer le signal ou intercepter le signal avec un \fIgestionnaire de signal\fP, c'est\-à\-dire une fonction définie par le programme qui est invoquée automatiquement lorsque le signal est transmis. .PP Par défaut, le gestionnaire de signal est appelé sur la pile normale des processus. Il est possible de prévoir que le gestionnaire de signal utilise une autre pile\ ; consultez \fBsigaltstack\fP(2) pour une discussion sur comment faire cela et quand cela pourrait être utile. .PP L’action d'un signal est un attribut du processus\ : dans une application multithreadée, l’action d'un signal particulier est la même pour tous les threads. .PP Un enfant créé par \fBfork\fP(2) hérite d'une copie des actions des signaux de son parent. Lors d'un \fBexecve\fP(2), les actions des signaux pris en charge sont remises aux valeurs par défaut\ ; les actions des signaux ignorés ne sont pas modifiées. .SS "Envoyer un signal" Les appels système et les fonctions de bibliothèque qui suivent permettent à l'appelant d'envoyer un signal\ : .TP \fBraise\fP(3) Envoyer un signal au thread appelant. .TP \fBkill\fP(2) Envoyer un signal au processus indiqué, à tous les membres du groupe de processus indiqué ou à tous les processus du système. .TP \fBpidfd_send_signal\fP(2) Envoyer un signal à un processus identifié par un descripteur de fichier de PID. .TP \fBkillpg\fP(3) Envoyer un signal à tous les membres du groupe de processus indiqué. .TP \fBpthread_kill\fP(3) Envoyer un signal au thread POSIX indiqué dans le même processus que l'appelant. .TP \fBtgkill\fP(2) Envoyer un signal au thread indiqué à l'intérieur d'un processus donné (c'est l'appel système utilisé pour implémenter \fBpthread_kill\fP(3)). .TP \fBsigqueue\fP(3) Envoyer un signal temps réel, avec ses données jointes, au processus indiqué. .SS "Attente de la capture d'un signal" Les appels système suivants suspendent l'exécution du thread appelant jusqu'à ce qu'un signal soit reçu (ou qu'un signal non pris en charge termine le processus)\ : .TP \fBpause\fP(2) Suspendre l'exécution jusqu'à ce que n'importe quel signal soit reçu. .TP \fBsigsuspend\fP(2) .\" Changer temporairement le masque de signaux (voir ci\-dessous) et suspendre l'exécution jusqu'à ce qu'un des signaux non masqué soit reçu. .SS "Accepter un signal de façon synchrone" Au lieu d’intercepter un signal de façon asynchrone avec un gestionnaire de signal, il est possible de l’accepter de façon synchrone, c'est\-à\-dire de bloquer l'exécution jusqu'à ce que le signal soit distribué. À ce moment, le noyau renvoie des informations concernant le signal à l'appelant. Il y a deux façons générales pour faire cela\ : .IP \- 3 \fBsigwaitinfo\fP(2), \fBsigtimedwait\fP(2) et \fBsigwait\fP(3) suspendent l'exécution jusqu'à ce qu'un des signaux dans l'ensemble indiqué soit distribué. Chacun de ces appels renvoie des informations concernant le signal distribué. .IP \- \fBsignalfd\fP(2) renvoie un descripteur de fichier qui peut être utilisé pour lire les informations concernant les signaux qui sont distribués à l'appelant. Chaque \fBread\fP(2) dans ce descripteur de fichier est bloquant jusqu'à ce que un des signaux de l'ensemble indiqué dans l’appel \fBsignalfd\fP(2) soit distribué à l'appelant. Le tampon renvoyé par \fBread\fP(2) contient une structure qui décrit le signal. .SS "Masque de signaux et signaux en attente" Un signal peut être \fIbloqué\fP, ce qui signifie qu'il ne sera pas envoyé avant d'être débloqué. Entre le moment de sa création et celui de son envoi, le signal est dit \fIen\ attente\fP. .PP Chaque thread d'un processus a un \fImasque de signaux\fP indépendant qui indique l'ensemble des signaux bloqués par le thread. Un thread peut modifier son masque de signaux avec \fBpthread_sigmask\fP(3). Dans une application traditionnelle à un seul thread, \fBsigprocmask\fP(2) peut être utilisée pour modifier le masque de signaux. .PP Un processus enfant créé avec \fBfork\fP(2) hérite d'une copie du masque de signaux de son parent. Le masque de signaux est conservé au travers d'un \fBexecve\fP(2). .PP Un signal peut être «\ orienté processus\ » ou «\ orienté thread\ ». Un signal orienté processus est un signal qui cible (et par conséquent en attente pour) le processus dans son entier. Il peut l’être parce qu’il a été généré par le noyau pour des raisons autres qu’une exception matérielle ou parce qu’il a été envoyé en utilisant \fBkill\fP(2) ou \fBsigqueue\fP(3). Un signal orienté thread est destiné à un thread particulier. Un tel signal peut l’être parce qu’il a été généré en conséquence de l’exécution d’une instruction spécifique de code machine qui est déclenchée par une exception matérielle (par exemple, \fBSIGSEGV\fP pour un accès mémoire non autorisé ou \fBSIGFPE\fP pour une erreur mathématique) ou parce qu’il visait un thread particulier en utilisant une interface telle que \fBtgkill\fP(2) ou \fBpthread_kill\fP(3). .PP .\" Joseph C. Sible notes: .\" On Linux, if the main thread has the signal unblocked, then the kernel .\" will always deliver the signal there, citing this kernel code .\" .\" Per this comment in kernel/signal.c since time immemorial: .\" .\" /* .\" * Now find a thread we can wake up to take the signal off the queue. .\" * .\" * If the main thread wants the signal, it gets first crack. .\" * Probably the least surprising to the average bear. .\" */ .\" .\" But this does not mean the signal will be delivered only in the .\" main thread, since if a handler is already executing in the main thread .\" (and thus the signal is blocked in that thread), then a further .\" might be delivered in a different thread. .\" Un signal orienté processus peut être délivré à n’importe quel des threads qui n’ont pas présentement le signal bloqué. Si plus d’un des threads a le signal non bloqué, alors le noyau choisit un thread arbitraire auquel délivrer le signal. .PP Un thread peut obtenir l'ensemble des signaux actuellement en attente en utilisant \fBsigpending\fP(2). Cet ensemble est l'union de l’ensemble des signaux en attente orientés processus et l’ensemble des signaux en attente pour le thread appelant. .PP .\" Un enfant créé avec \fBfork\fP(2) débute avec un ensemble de signaux en attente vide. L'ensemble de signaux en attente est conservé au travers d'un \fBexecve\fP(2). .SS "Exécution des gestionnaires de signal" À chaque transition d’une exécution en mode noyau vers une en mode utilisateur (par exemple, lors du retour d’un appel système ou l’ordonnancement d’un thread sur le CPU), le noyau vérifie s’il existe un signal en attente non bloqué pour lequel le processus a établi un gestionnaire de signal. Si un tel signal est en attente, les étapes suivantes se déroulent\ : .IP (1) 5 Le noyau réalise les étapes préparatoires nécessaires pour l’exécution du gestionnaire de signal\ : .RS .IP (1.1) 7 Le signal est supprimé de l’ensemble des signaux en attente. .IP (1.2) Si le gestionnaire de signal a été installé par un appel à \fBsigaction\fP(2) qui est précisé par l’indicateur \fBSA_ONSTACK\fP et que le thread a défini une pile de signaux de remplacement (en utilisant \fBsigaltstack\fP(2)), alors cette pile est installée. .IP (1.3) Diverses pièces du contexte relatif au signal sont enregistrées dans une structure spéciale qui est créée dans la pile. Les informations enregistrées comprennent\ : .RS .IP \- 3 le registre de compteur du programme (c’est\-à\-dire l’adresse de la prochaine instruction dans le programme principal qui devrait être exécutée lors du renvoi du gestionnaire de signal)\ ; .IP \- l’état du registre spécifique à l’architecture nécessaire pour reprendre le programme interrompu\ ; .IP \- le masque de signaux du thread actuel\ ; .IP \- les paramètres de la pile de signaux de remplacement du thread. .RE .IP (Si le gestionnaire de signal a été installé en utilisant l’indicateur \fBSA_SIGINFO\fP de \fBsigaction\fP(2), alors les informations ci\-dessus sont accessibles à l’aide de l’objet \fIucontext_t\fP qui est pointé par le troisième argument du gestionnaire de signal.) .IP (1.4) Tout signal précisé dans \fIact\->sa_mask\fP lors de l’enregistrement du gestionnaire avec \fBsigprocmask\fP(2) est ajouté au masque de signaux du thread. Le signal à transmettre est aussi ajouté au masque de signaux à moins que \fBSA_NODEFER\fP ait été précisé lors de l’enregistrement du gestionnaire. Ces signaux sont alors bloqués pendant que le gestionnaire réalise l’exécution. .RE .IP (2) Le noyau construit une structure pour le gestionnaire de signal sur la pile. Le noyau règle le compteur du programme pour le thread pour pointer à la première instruction de la fonction du gestionnaire de signal et configure l’adresse de retour pour cette fonction pour pointer vers un élément du code de l’espace utilisateur connu comme «\ trampoline de signal\ » (décrit dans \fBsigreturn\fP(2)). .IP (3) Le noyau repasse le contrôle à l’espace utilisateur où l’exécution commence au début de la fonction du gestionnaire de signal. .IP (4) Au renvoi du gestionnaire de signal, le contrôle passe au trampoline de signal. .IP (5) Le trampoline de signal appelle \fBsigreturn\fP(2), un appel système qui utilise les informations dans la structure de la pile créée à la première étape pour restaurer le thread dans son état avant que le gestionnaire de signal ait été appelé. Les paramètres du masque de signaux du thread et de la pile de signaux de remplacement sont restaurés dans le cadre de cette procédure. À la fin de l’appel à \fBsigreturn\fP(2), le noyau transfère le contrôle à l’espace utilisateur et le thread recommence l’exécution à partir du point où elle a été interrompue par le gestionnaire de signal. .PP Remarquez que si le gestionnaire de signal ne renvoie pas (par exemple, le contrôle est transféré en dehors du gestionnaire en utilisant \fBsiglongjmp\fP(3) ou le gestionnaire exécute un nouveau programme avec \fBexecve\fP(2)), alors l’étape finale n’est par réalisée. En particulier, dans de tels scénarios, c’est la responsabilité du programmeur de restaurer l’état du masque de signaux (en utilisant \fBsigprocmask\fP(2)) si le déblocage des signaux, qui étaient bloqués par une entrée dans le gestionnaire de signal, est désiré. (Notez que \fBsiglongjmp\fP(3) peut ou ne peut pas restaurer le masque de signaux en fonction de la valeur \fIsavesigs\fP qui était indiquée dans l’appel correspondant à \fBsigsetjmp\fP(3).) .PP .\" Du point de vue du noyau, l’exécution du code du gestionnaire de signal est exactement la même que celle n’importe quel code de l’espace utilisateur. C’est\-à\-dire que le noyau n’enregistre aucune information spéciale d’état indiquant que le thread est actuellement en exécution à l’intérieur d’un gestionnaire de signal. Toutes les informations d’état nécessaires sont entretenues dans des registres de l’espace utilisateur et la pile de l’espace utilisateur. La profondeur à laquelle les gestionnaires de signaux imbriqués peuvent être invoqués est donc limitée seulement par la pile de l’espace utilisateur (et une conception logicielle raisonnable). .SS "Signaux standard" Linux prend en charge les signaux standard listés ci\-dessous. La seconde colonne du tableau indique quelle norme (si elle existe) décrit le signal\ : «\ P1990\ » indique que le signal est décrit dans la norme POSIX.1\-1990 originelle. «\ P2001\ » indique que le signal a été ajouté dans SUSv2 et POSIX.1\-2001. .TS l c c l ____ lB c c l. Signal Norme Action Commentaire SIGABRT P1990 Core Signal d'arrêt d’\fBabort\fP(3) SIGALRM P1990 Term Signal de temporisation d’\fBalarm\fP(2) SIGBUS P2001 Core Erreur de bus (mauvais accès mémoire) SIGCHLD P1990 Ign Enfant arrêté ou terminé SIGCLD \- Ign Synonyme pour \fBSIGCHLD\fP SIGCONT P1990 Cont Continuer si arrêté SIGEMT \- Term Interception (trap) d’émulateur SIGFPE P1990 Core Exception de virgule flottante SIGHUP P1990 Term Déconnexion détectée sur le terminal de contrôle ou mort du processus de contrôle SIGILL P1990 Core Instruction illégale SIGINFO \- Synonyme pour \fBSIGPWR\fP SIGINT P1990 Term Interruption depuis le clavier SIGIO \- Term E/S maintenant possible (4.2BSD) SIGIOT \- Core Interception IOT – synonyme pour \fBSIGABRT\fP SIGKILL P1990 Term Signal d’arrêt SIGLOST \- Term Perte de verrou de fichier (inutilisé) SIGPIPE P1990 Term Tube brisé : écriture dans un tube sans lecteur – voir \fBpipe\fP(7) SIGPOLL P2001 Term Événement scrutable (System V) – synonyme pour \fBSIGIO\fP 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 Référence mémoire non valable SIGSTKFLT \- Term Erreur de pile sur coprocesseur (inutilisé) SIGSTOP P1990 Stop Processus d’arrêt SIGTSTP P1990 Stop Stop saisi sur le terminal SIGSYS P2001 Core Mauvais appel système (SVr4) – voir aussi \fBseccomp\fP(2) SIGTERM P1990 Term Signal de fin SIGTRAP P2001 Core Interception pour trace ou pour point d’arrêt SIGTTIN P1990 Stop Entrée du terminal pour processus en arrière\-plan SIGTTOU P1990 Stop Sortie du terminal pour processus en arrière\-plan SIGUNUSED \- Core Synonyme pour \fBSIGSYS\fP 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 dépassée (4.2BSD) Consultez \fBsetrlimit\fP(2) SIGXFSZ P2001 Core Taille de fichier excessive (4.2BSD) Consultez \fBsetrlimit\fP(2) SIGWINCH \- Ign Fenêtre redimensionnée (4.3BSD, Sun) .TE .PP Les signaux \fBSIGKILL\fP et \fBSIGSTOP\fP ne peuvent être ni capturés, ni bloqués, ni ignorés. .PP Jusqu'à Linux\ 2.2 inclus, l'action par défaut pour \fBSIGSYS\fP, \fBSIGXCPU\fP, \fBSIGXFSZ\fP et (sur les architectures autres que SPARC ou MIPS) \fBSIGBUS\fP était de terminer simplement le processus, sans fichier image mémoire. (Sur certains UNIX, l'action par défaut pour \fBSIGXCPU\fP et \fBSIGXFSZ\fP est de finir le processus sans fichier image mémoire.) Linux\ 2.4 se conforme à POSIX.1\-2001 pour ces signaux et termine le processus avec un fichier image mémoire. .PP \fBSIGEMT\fP 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 image mémoire. .PP \fBSIGPWR\fP (non spécifié dans POSIX.1\-2001) est typiquement ignoré sur les autres UNIX où il apparaît. .PP .\" \fBSIGIO\fP (non spécifié par POSIX.1\-2001) est ignoré par défaut sur plusieurs autres systèmes UNIX. .SS "Sémantiques 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 distribués n’est pas précisé. .PP .\" Les signaux standard ne sont pas mis en file d’attente. Si plusieurs instances d’un signal standard sont générées pendant que ce signal est bloqué, alors une seule instance du signal est marquée comme en attente (et le signal sera distribué une seule fois une fois débloqué). Dans le cas ou un signal standard est déjà en attente, la structure \fIsiginfo_t\fP (consultez \fBsigaction\fP(2)) associée à ce signal n’est pas écrasée lors de l’arrivée d’instances suivantes du même signal. Par conséquent, le processus recevra les informations associées à la première instance du signal. .SS "Numérotation pour les signaux standard" La valeur numérique de chaque signal est donnée dans la table ci\-dessous. Comme montrés dans cette table, plusieurs signaux ont des valeurs numériques différentes sur des architectures différentes. La première valeur dans chaque ligne indique le numéro de signal sur x86, ARM et la plupart des autres architectures. La seconde valeur indique celui pour Alpha et SPARC. La troisième indique celui de MIPS et la dernière celui de PA\-RISC. Un tiret (\-) indique que le signal est absent sur l’architecture correspondante. .TS l c c c c l l c c c c l ______ lB c c c c l. Signal x86/ARM et la Alpha/ MIPS PA\-RISC Notes plupart des arch. SPARC SIGHUP \01 \01 \01 \01 SIGINT \02 \02 \02 \02 SIGQUIT \03 \03 \03 \03 SIGILL \04 \04 \04 \04 SIGTRAP \05 \05 \05 \05 SIGABRT \06 \06 \06 \06 SIGIOT \06 \06 \06 \06 SIGBUS \07 10 10 10 SIGEMT \- \07 \07 \- SIGFPE \08 \08 \08 \08 SIGKILL \09 \09 \09 \09 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 \- \- \07 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 à SIGIO SIGPWR 30 29/\- 19 19 SIGINFO \- 29/\- \- \- SIGLOST \- \-/29 \- \- SIGSYS 31 12 12 31 SIGUNUSED 31 \- \- 31 .TE .PP Il est à noter que\ : .IP \- 3 si défini, \fBSIGUNUSED\fP est synonyme de \fBSIGSYS\fP. Depuis la glibc\ 2.26, \fBSIGUNUSED\fP n’est plus défini sur toutes les architectures\ ; .IP \- .\" le signal 29 est \fBSIGINFO\fP/\fBSIGPWR\fP (synonymes pour la même valeur) sur Alpha mais \fBSIGLOST\fP sur SPARC. .SS "Signaux temps réel" 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 \fBSIGRTMIN\fP and \fBSIGRTMAX\fP. POSIX.1\-2001 requires that an implementation support at least \fB_POSIX_RTSIG_MAX\fP (8) real\-time signals. .PP Le noyau Linux gère une gamme de 33\ signaux temps réel différents, numérotés de 32 à 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 \fBpthreads\fP(7)) et ajuste la valeur de \fBSIGRTMIN\fP 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 \fIjamais faire référence à des signaux temps réel en utilisant des numéros codés en dur\fP, mais devraient toujours à la place utiliser des signaux temps réel avec la notation \fBSIGRTMIN\fP+n avec des vérifications adéquates (lors de l'exécution) que \fBSIGRTMIN\fP+n ne dépasse pas \fBSIGRTMAX\fP. .PP 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é à des fins spécifiques à l'application. .PP L'action par défaut pour un signal temps réel non géré est de terminer le processus récepteur. .PP Les signaux temps réel se distinguent de la façon suivante\ : .IP \- 3 Plusieurs instances d'un signal temps réel peuvent être mises en file d’attente. Au contraire, si plusieurs instances d'un signal standard arrivent alors qu'il est présentement bloqué, une seule instance sera mise en file d’attente. .IP \- Si le signal est envoyé en utilisant \fBsigqueue\fP(3), il peut être accompagné d'une valeur (un entier ou un pointeur). Si le processus récepteur positionne un gestionnaire pour ce signal en utilisant l'attribut \fBSA_SIGINFO\fP pour l'appel \fBsigaction\fP(2), alors il peut accéder à la valeur transmise dans le champ \fIsi_value\fP de la structure \fIsiginfo_t\fP passée en second argument au gestionnaire. De plus, les champs \fIsi_pid\fP et \fIsi_uid\fP de cette structure fournissent le PID et l'UID réel du processus émetteur du signal. .IP \- 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é (c’est\-à\-dire le signal de plus fort numéro est celui de priorité la plus faible). Par contre, si plusieurs signaux standard sont en attente pour un processus, l'ordre dans lequel ils sont délivrés n'est pas défini. .PP Si des signaux standard et des signaux temps réel sont simultanément en attente pour un processus, POSIX ne précise pas l'ordre de délivrance. Linux, comme beaucoup d'autres implémentations, donne priorité aux signaux standard dans ce cas. .PP According to POSIX, an implementation should permit at least \fB_POSIX_SIGQUEUE_MAX\fP (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 \fI/proc/sys/kernel/rtsig\-max\fP file. A related file, \fI/proc/sys/kernel/rtsig\-nr\fP, can be used to find out how many real\-time signals are currently queued. In Linux 2.6.8, these \fI/proc\fP interfaces were replaced by the \fBRLIMIT_SIGPENDING\fP resource limit, which specifies a per\-user limit for queued signals; see \fBsetrlimit\fP(2) for further details. .PP L’ajout de signaux temps réel nécessite l’agrandissement de la structure de l’ensemble des signaux (\fIsigset_t\fP) de 32 à 64\ bits. Par conséquent, divers appels système ont été supplantés par de nouveaux appels système qui gèrent des ensembles de signaux plus grands. Les anciens et nouveaux appels système sont les suivants\ : .TS lb lb l l. Linux 2.0 et antérieurs Linux 2.2 et postérieurs \fBsigaction\fP(2) \fBrt_sigaction\fP(2) \fBsigpending\fP(2) \fBrt_sigpending\fP(2) \fBsigprocmask\fP(2) \fBrt_sigprocmask\fP(2) \fBsigreturn\fP(2) \fBrt_sigreturn\fP(2) \fBsigsuspend\fP(2) \fBrt_sigsuspend\fP(2) \fBsigtimedwait\fP(2) \fBrt_sigtimedwait\fP(2) .TE .\" .SS "Interruption d’appel et de fonction par un gestionnaire de signal" Si un gestionnaire de signal est invoqué pendant qu'un appel système ou une fonction de bibliothèque est bloqué, alors\ : .IP \- 3 soit l'appel est automatiquement redémarré après le renvoi du gestionnaire de signal\ ; .IP \- soit l'appel échoue avec l'erreur \fBEINTR\fP. .PP 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 \fBSA_RESTART\fP (consultez \fBsigaction\fP(2)). Les détails varient selon les systèmes UNIX\ ; voici ceux pour Linux. .PP .\" The following system calls use ERESTARTSYS, .\" so that they are restartable Si un appel en attente à l'une des interfaces suivantes est interrompu par un gestionnaire de signal, l'appel sera automatiquement redémarré après le renvoi du gestionnaire de signal si l'attribut \fBSA_RESTART\fP a été indiqué\ ; autrement, l'appel échouera avec l'erreur \fBEINTR\fP\ : .IP \- 3 Appels \fBread\fP(2), \fBreadv\fP(2), \fBwrite\fP(2), \fBwritev\fP(2) et \fBioctl\fP(2) sur des périphériques «\ lents\ ». Un périphérique «\ lent\ » est un périphérique où un appel d'E/S peut bloquer pendant un temps indéfini, par exemple un terminal, un tube ou un socket. Si un appel d'E/S 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 une indication de succès (normalement, le nombre d'octets transférés). Remarquez que selon cette définition, un disque (local) n'est pas un périphérique lent. Les opérations d’E/S sur les périphériques disque ne sont pas interrompues par des signaux. .IP \- \fBopen \fP(2), s'il peut bloquer (par exemple, lors de l'ouverture d'une FIFO\ ; consultez \fBfifo\fP(7)). .IP \- \fBwait\fP(2), \fBwait3\fP(2), \fBwait4\fP(2), \fBwaitid\fP(2), et \fBwaitpid\fP(2). .IP \- .\" If a timeout (setsockopt()) is in effect on the socket, then these .\" system calls switch to using EINTR. Consequently, they and are not .\" automatically restarted, and they show the stop/cont behavior .\" described below. (Verified from Linux 2.6.26 source, and by experiment; mtk) .\" FIXME What about sendmmsg()? Interfaces de socket\ : \fBaccept\fP(2), \fBconnect\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2), \fBrecvmsg\fP(2), \fBsend\fP(2), \fBsendto\fP(2) et \fBsendmsg\fP(2), à moins qu'une temporisation n'ait été placée sur le socket (voir ci\-dessous). .IP \- Interfaces de blocage de fichier\ : \fBflock\fP(2) et les opérations \fBF_SETLKW\fP et \fBF_OFD_SETLKW\fP de \fBfcntl\fP(2) .IP \- Interfaces de files de messages POSIX\ : \fBmq_receive\fP(3), \fBmq_timedreceive\fP(3), \fBmq_send\fP(3) et \fBmq_timedsend\fP(3). .IP \- .\" commit 72c1bbf308c75a136803d2d76d0e18258be14c7a Opération \fBFUTEX_WAIT\fP de \fBfutex\fP(2) (depuis Linux\ 2.6.22\ ; auparavant, elle échouait toujours avec l'erreur \fBEINTR\fP). .IP \- \fBgetrandom\fP(2). .IP \- \fBpthread_mutex_lock\fP(3), \fBpthread_cond_wait\fP(3) et autres API apparentées. .IP \- \fBFUTEX_WAIT_BITSET\fP de \fBfutex\fP(2. .IP \- .\" as a consequence of the 2.6.22 changes in the futex() implementation Interfaces de sémaphores POSIX\ : \fBsem_wait\fP(3) et \fBsem_timedwait\fP(3) (depuis Linux\ 2.6.22\ ; auparavant, elles échouaient toujours avec l'erreur \fBEINTR\fP). .IP \- .\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06 \fBread\fP(2) d’un descripteur de fichier d’\fBinotify\fP(7) (depuis Linux\ 3.8\ ; auparavant, elle échouait toujours avec l'erreur \fBEINTR\fP). .PP .\" These are the system calls that give EINTR or ERESTARTNOHAND .\" on interruption by a signal handler. Les interfaces suivantes ne sont jamais relancées après avoir été interrompues par un gestionnaire de signal, quelle que soit l'utilisation de \fBSA_RESTART\fP\ ; elles échouent toujours avec l'erreur \fBEINTR\fP lorsqu'elles sont interrompues par un gestionnaire de signal\ : .IP \- 3 Interfaces de socket «\ entrée\ », quand un délai de réception (\fBSO_RCVTIMEO\fP) a été défini sur le socket en utilisant \fBsetsockopt\fP(2)\ : \fBaccept\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2) (aussi avec un paramètre \fItimeout\fP non NULL) et \fBrecvmsg\fP(2). .IP \- .\" FIXME What about sendmmsg()? Interfaces de socket «\ sortie\ », quand un délai de réception (\fBSO_RCVTIMEO\fP) a été défini sur le socket en utilisant \fBsetsockopt\fP(2)\ : \fBconnect\fP(2), \fBsend\fP(2), \fBsendto\fP(2) et \fBsendmsg\fP(2). .IP \- Interfaces utilisées pour attendre des signaux\ : \fBpause\fP(2), \fBsigsuspend\fP(2), \fBsigtimedwait\fP(2) et \fBsigwaitinfo\fP(2). .IP \- Interfaces de multiplexage de descripteurs de fichier\ : \fBepoll_wait\fP(2), \fBepoll_pwait\fP(2), \fBpoll\fP(2), \fBppoll\fP(2), \fBselect\fP(2) et \fBpselect\fP(2). .IP \- .\" On some other systems, SA_RESTART does restart these system calls Interfaces IPC de System\ V\ : \fBmsgrcv\fP(2), \fBmsgsnd\fP(2), \fBsemop\fP(2) et \fBsemtimedop\fP(2). .IP \- Interfaces de sommeil\ : \fBclock_nanosleep\fP(2), \fBnanosleep\fP(2) et \fBusleep\fP(3). .IP \- \fBio_getevents\fP(2). .PP La fonction \fBsleep\fP(3) n'est également jamais relancée si elle est interrompue par un gestionnaire, mais elle renvoie une indication de succès\ : le nombre de secondes restantes pour le sommeil. .PP .\" In certain circumstances, the \fBseccomp\fP(2) user\-space notification feature can lead to restarting of system calls that would otherwise never be restarted by \fBSA_RESTART\fP; for details, see \fBseccomp_unotify\fP(2). .SS "Interruption d’appel et de fonction par des signaux d'arrêt" Sous Linux, même en l'absence de gestionnaire de signal, certaines interfaces en mode bloquant peuvent échouer avec l'erreur \fBEINTR\fP après que le processus a été arrêté par l'un des signaux d'arrêt et relancé avec le signal \fBSIGCONT\fP. Ce comportement n'est pas ratifié par POSIX.1 et n'apparaît pas sur d'autres systèmes. .PP Les interfaces Linux qui affichent ce comportement sont\ : .IP \- 3 Interfaces de socket «\ entrée\ », quand un délai de réception (\fBSO_RCVTIMEO\fP) a été défini sur le socket en utilisant \fBsetsockopt\fP(2)\ : \fBaccept\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2) (aussi avec un paramètre \fItimeout\fP non NULL) et \fBrecvmsg\fP(2). .IP \- .\" FIXME What about sendmmsg()? Les interfaces de socket «\ sortie\ », quand un délai de réception (\fBSO_RCVTIMEO\fP) a été défini sur le socket en utilisant \fBsetsockopt\fP(2)\ : \fBconnect\fP(2), \fBsend\fP(2), \fBsendto\fP(2) et \fBsendmsg\fP(2), si un délai de transmission (\fBSO_SNDTIMEO\fP) a été défini. .IP \- \fBepoll_wait\fP(2), \fBepoll_pwait\fP(2). .IP \- \fBsemop\fP(2), \fBsemtimedop\fP(2). .IP \- \fBsigtimedwait\fP(2), \fBsigwaitinfo\fP(2). .IP \- .\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06 Linux\ 3.7 et antérieurs\ : \fBread\fP(2) sur un descripteur de fichier \fBinotify\fP(7). .IP \- Linux\ 2.6.21 et antérieurs\ : opération \fBFUTEX_WAIT\fP de \fBfutex\fP(2), \fBsem_timedwait\fP(3), \fBsem_wait\fP(3). .IP \- Linux\ 2.6.8 et antérieurs\ : \fBmsgrcv\fP(2), \fBmsgsnd\fP(2). .IP \- Linux\ 2.4 et antérieurs\ : \fBnanosleep\fP(2). .SH STANDARDS POSIX.1, sauf indication contraire. .SH NOTES Pour une discussion sur les fonctions sûres de signal asynchrone, consultez \fBsignal\-safety\fP(7). .PP The \fI/proc/\fPpid\fI/task/\fPtid\fI/status\fP file contains various fields that show the signals that a thread is blocking (\fISigBlk\fP), catching (\fISigCgt\fP), or ignoring (\fISigIgn\fP). (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 (\fISigPnd\fP) as well as the set of pending signals that are directed to the process as a whole (\fIShdPnd\fP). The corresponding fields in \fI/proc/\fPpid\fI/status\fP show the information for the main thread. See \fBproc\fP(5) for further details. .SH BOGUES Six signaux existent qui peuvent être délivrés à cause d’une exception matérielle\ : \fBSIGBUS\fP, \fBSIGEMT\fP, \fBSIGFPE\fP, \fBSIGILL\fP, \fBSIGSEGV\fP et \fBSIGTRAP\fP. Lequel de ces signaux est délivré pour n’importe quelle exception matérielle n’est pas documenté et semble parfois ne pas être logique. .PP Par exemple, un accès mémoire non autorisé qui provoque l’envoi de \fBSIGSEGV\fP sur une architecture peut provoquer l’envoi de \fBSIGBUS\fP sur une autre architecture ou vice versa. .PP Comme autre exemple, l’utilisation de l’instruction \fIint\fP de x86 avec un argument interdit (tout nombre autre que 3 ou 128) provoque l’envoi de \fBSIGSEGV\fP même si \fBSIGILL\fP serait plus adapté à cause de la façon dont le CPU rapporte l’opération interdite au noyau. .SH "VOIR AUSSI" \fBkill\fP(1), \fBclone\fP(2), \fBgetrlimit\fP(2), \fBkill\fP(2), \fBpidfd_send_signal\fP(2), \fBrestart_syscall\fP(2), \fBrt_sigqueueinfo\fP(2), \fBsetitimer\fP(2), \fBsetrlimit\fP(2), \fBsgetmask\fP(2), \fBsigaction\fP(2), \fBsigaltstack\fP(2), \fBsignal\fP(2), \fBsignalfd\fP(2), \fBsigpending\fP(2), \fBsigprocmask\fP(2), \fBsigreturn\fP(2), \fBsigsuspend\fP(2), \fBsigwaitinfo\fP(2), \fBabort\fP(3), \fBbsd_signal\fP(3), \fBkillpg\fP(3), \fBlongjmp\fP(3), \fBpthread_sigqueue\fP(3), \fBraise\fP(3), \fBsigqueue\fP(3), \fBsigset\fP(3), \fBsigsetops\fP(3), \fBsigvec\fP(3), \fBsigwait\fP(3), \fBstrsignal\fP(3), \fBswapcontext\fP(3), \fBsysv_signal\fP(3), \fBcore\fP(5), \fBproc\fP(5), \fBnptl\fP(7), \fBpthreads\fP(7), \fBsigevent\fP(7) .PP .SH TRADUCTION La traduction française de cette page de manuel a été créée par Christophe Blaess , Stéphan Rafin , Thierry Vignaud , François Micaux, Alain Portal , Jean-Philippe Guérard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas François , Florentin Duneau , Simon Paillard , Denis Barbier , David Prévot , Cédric Boutillier , Frédéric Hantrais et Jean-Paul Guillonneau . .PP Cette traduction est une documentation libre ; veuillez vous reporter à la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License version 3 .UE concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE. .PP Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à .MT debian-l10n-french@lists.debian.org .ME .