Le mécanisme de signalisation du noyau Linux permet aux applications en cours d'exécution de notifier le système de manière asynchrone lorsqu'un nouvel événement se produit. En raison de sa nature, ce mécanisme de signalisation est généralement connu sous le nom d'interruptions logicielles. Tout comme les interruptions matérielles, les signaux interrompent le flux normal d'une application et il est imprévisible quand une application recevra un signal.
Plongeons-nous profondément dans le mécanisme de signalisation de Linux et comprenons ce qui se passe dans les coulisses.
Concepts de base des signaux sous Linux
Sous Linux, les processus génèrent des signaux dans trois situations de base :
- Lorsqu'une situation exceptionnelle se produit côté matériel. Par exemple, vous pouvez penser à des événements tels que l'application essayant d'accéder à une région en dehors du espace d'adressage autorisé (défaut de segmentation) ou génération de code machine incluant une division par zéro opération.
- Des situations telles que l'utilisation de combinaisons de touches comme Ctrl + C ou Ctrl + Z sur la console par l'utilisateur, en redimensionnant l'écran de la console ou en envoyant un signal d'arrêt.
- Le temporisateur défini dans l'application expire, la limite CPU donnée à l'application est élevée, les données arrivent dans un descripteur de fichier ouvert, etc.
Le concept de signaux existe depuis les premières versions d'Unix. Auparavant, il existait plusieurs différences entre les versions d'Unix concernant le traitement du signal. Plus tard, avec la normalisation POSIX conçu pour la gestion du signal, Linux et d'autres dérivés d'Unix ont commencé à suivre ces normes. Pour cette raison, les concepts de signaux Unix et de signaux POSIX, que vous pouvez rencontrer dans certains documents, indiquent les différences.
Numéros de signaux
Les signaux ont différentes valeurs numériques, en commençant par un. Par exemple, le signal 1 est un HUP signal dans presque tous les systèmes, ou le signal 9 est un TUER signal.
Cependant, l'utilisation de ces numéros est fortement déconseillée lorsque vous utilisez des signaux dans vos applications. Pour les signaux POSIX, signal.h le fichier doit être dans l'application et le développeur doit utiliser les définitions constantes des nombres associés tels que SIGHUP, SIGKILL, etc. Au lieu.
Si vous examinez le /usr/include/signal.h fichier sur votre système, vous pouvez voir les opérations supplémentaires et les autres fichiers inclus en consultant les définitions de valeurs telles que __USE_POSIX, __USE_XOPEN, __USE_POSIX199309, etc. dans le fichier. Vous pouvez trouver les numéros de signaux disponibles sur les systèmes Linux dans le /usr/include/asm-generic/signal.h fichier, que vous n'avez pas besoin d'inclure directement dans votre code d'application.
Génération et envoi de signaux
La génération de signal se produit en raison d'un événement. Cependant, l'envoi (délivrance) du signal à l'application concernée ne se produit pas simultanément avec la génération du signal.
Pour que le signal soit envoyé à l'application, l'application doit être en cours d'exécution et disposer de ressources CPU. Par conséquent, l'envoi d'un signal à une application spécifique se produit lorsque l'application concernée recommence à fonctionner après le changement de contexte.
Le concept de signal en attente
Pendant le temps allant de la génération à la transmission du signal, les signaux sont dans un état d'attente. Vous pouvez accéder au nombre de signaux en attente et au nombre de signaux en attente autorisés pour un processus à partir du /proc/PID/status dossier.
# Pour un process avec PID: 2299
chat /proc/2299/statut
# Production
...
SigQ: 2/31630
...
Masques de signal et blocage
L'heure exacte à laquelle les signaux arriveront est souvent imprévisible par l'application. Par conséquent, certaines interruptions critiques peuvent se produire au cours de n'importe quelle opération. Cela peut causer des problèmes majeurs pour une application à grande échelle.
Pour éviter certaines situations indésirables comme celle-ci, il est nécessaire d'utiliser des masques de signal. Ainsi il est possible de bloquer certains signaux avant une opération critique. A ce stade, il est important de terminer la partie critique et de supprimer les blocs définis. Ce processus est quelque chose auquel le développeur de l'application doit prêter attention.
Lorsque l'application bloque un signal, les autres signaux du même type générés seront dans un état d'attente jusqu'à ce qu'ils soient débloqués. Dans l'application, l'envoi des signaux en attente est également prévu dès que le blocage est supprimé.
De cette façon, les mêmes types de signaux mis en attente au moment du blocage ne sont envoyés à l'application qu'une seule fois après la suppression du blocage en utilisation normale. La situation est différente pour les signaux en temps réel.
Types de signaux Linux
Les actions par défaut peuvent varier selon les types de signaux. Si l'application qui reçoit le signal correspondant n'a pas de fonction de gestionnaire de signal, l'action par défaut a lieu. Parfois, cela signifie mettre fin à l'application et parfois ignorer le signal.
Certains signaux ne peuvent pas être capturés au niveau de la couche application, ces signaux exécutent toujours l'action par défaut (comme le signal KILL).
En plus de certaines actions qui provoquent l'arrêt d'une application, un fichier de vidage de mémoire est également produit. Les fichiers de vidage de mémoire, créés en écrivant la table de mémoire virtuelle du processus associé sur le disque, aident le l'utilisateur d'examiner les informations d'état avant la fin du processus avec des outils de débogage dans les étapes suivantes.
Les valeurs suivantes sont basées sur un architecture MIPS exemplaire:
Signal | Numéro | Action par défaut | Peut-il être attrapé? |
---|---|---|---|
SIGHUP | 1 | Terminer l'application | Oui |
SIGINT | 2 | Terminer l'application | Oui |
SIGQUITTER | 3 | Terminer l'application (vidage mémoire) | Oui |
SIGILLE | 4 | Terminer l'application (vidage mémoire) | Oui |
SIGTRAP | 5 | Terminer l'application (vidage mémoire) | Oui |
SIGABRT | 6 | Terminer l'application (vidage mémoire) | Oui |
SIGFPE | 8 | Terminer l'application (vidage mémoire) | Oui |
SIGKILL | 9 | Terminer l'application | Non |
SIGBUS | 10 | Terminer l'application (vidage mémoire) | Oui |
SIGSEGV | 11 | Terminer l'application (vidage mémoire) | Oui |
SIGSYS | 12 | Terminer l'application (vidage mémoire) | Oui |
SIGPIPE | 13 | Terminer l'application | Oui |
SIGALRM | 14 | Terminer l'application | Oui |
SIGTERME | 15 | Terminer l'application | Oui |
SIGUSR1 | 16 | Terminer l'application | Oui |
SIGUSR2 | 17 | Terminer l'application | Oui |
SIGCHLD | 18 | Ignorer | Oui |
SIGTSTP | 20 | Arrêt | Oui |
SIGURG | 21 | Ignorer | Oui |
SIGPOLL | 22 | Terminer l'application | Oui |
SIGSTOP | 23 | Arrêt | Non |
CONT SIG | 25 | Continuer si arrêté | Oui |
SIGTIN | 26 | Arrêt | Oui |
SIGTTOU | 27 | Arrêt | Oui |
SIGVTALRM | 28 | Terminer l'application | Oui |
SIGPROF | 29 | Terminer l'application | Oui |
SIGXCPU | 30 | Terminer l'application (vidage mémoire) | Oui |
SIGXFSZ | 31 | Terminer l'application (vidage mémoire) | Oui |
Cycle de vie des signaux sous Linux
Les signaux passent par trois étapes. Ils sont produits principalement dans la phase de production, par le noyau ou tout processus, et sont représentés par un nombre. Ils travaillent légèrement et rapidement, car ils n'ont aucune charge supplémentaire sur eux. Mais si vous regardez du côté POSIX, vous verrez que les signaux en temps réel peuvent transmettre des données supplémentaires.
La phase de livraison des signaux vient après la phase de production. Normalement, les signaux atteignent l'application depuis le noyau aussi rapidement que possible. Cependant, les applications peuvent parfois bloquer les signaux lors d'opérations critiques. Dans de tels cas, le signal reste en attente jusqu'à ce que la transaction ait lieu.
Comme les signaux, les processus font également partie intégrante de l'écosystème Linux. Comprendre ce que sont les processus et comment ils fonctionnent est crucial si vous envisagez de devenir administrateur système Linux.
Qu'est-ce qu'un processus sous Linux ?
Lire la suite
Rubriques connexes
- Linux
- Noyau Linux
- L'administration du système
A propos de l'auteur
Un ingénieur et développeur de logiciels passionné de mathématiques et de technologie. Il a toujours aimé les ordinateurs, les mathématiques et la physique. Il a développé des projets de moteurs de jeux ainsi que des bibliothèques d'apprentissage automatique, de réseaux de neurones artificiels et d'algèbre linéaire. De plus continue à travailler sur l'apprentissage automatique et les matrices linéaires.
Abonnez-vous à notre newsletter
Rejoignez notre newsletter pour des conseils techniques, des critiques, des ebooks gratuits et des offres exclusives !
Cliquez ici pour vous abonner