Comment fonctionnent les signaux Linux: SIGINT, SIGTERM et SIGKILL

Contenu

symbole de danger

Les interruptions logicielles sur les systèmes Linux et Unix sont effectuées via des signaux. Il existe de nombreux signaux Linux différents, mais certains sont mis en évidence et il est essentiel de les comprendre et de les connaître: SIGINT, SIGTERM et SIGKILL. C'est ainsi qu'ils fonctionnent.

Qu'est-ce qu'un Signal Linux?

Nous comprenons tous qu'un feu rouge signifie que nous devons arrêter de marcher ou de conduire. Équivalent, sur les systèmes Linux et Unix, un signal peut être transmis à un programme ou un service en cours d'exécution pour interagir avec lui. Par exemple, on pourrait envoyer un signal lumineux rouge à un programme simplement en diffusant un SIGTERM signe.

Comme avec un feu rouge, les gens peuvent choisir de continuer à marcher ou à conduire lorsque le feu est rouge. Bien que ce ne soit peut-être pas une idée sûre pour toutes les personnes impliquées, ongle SIGTERM signaler une procédure fera exactement cela; procédure / le programme peut choisir d'ignorer ledit signal.

Tous les signaux Linux de base ont un numéro (1-30 +). Après un certain temps, un utilisateur Linux généralement compétent connaîtra un ou plusieurs de ces. Par exemple, les SIGTERM le signal correspond au nombre 15 et le signal 9 (SIGKILL) est probablement le plus connu, puisqu'il permet de mettre fin de force à une procédure, contrairement à notre SIGTERM exemple de feu rouge.

htop affiche les signaux de programme possibles

Ici, nous voyons l'écran principal de htop (vous pouvez installer cet utilitaire pratique en tapant sudo apt install htop sous Ubuntu / menthe, O sudo yum install htop en RedHat / Centos / Feutre) avec une série de signaux de terminaison et d'autres (plus bas dans la liste; il y a 37 en tout) qui peut être envoyé à une procédure préalablement sélectionnée sur la droite. On peut choisir une procédure en appuyant sur le curseur haut / vers le bas puis envoyer un signal en utilisant F9.

SIGKILL & SIGTERM

Bien que le nom puisse sembler un peu sinistre, le jargon Linux commun pour la terminaison de processus est qu’un “arbuste” Une procédure. En termes générales, on voudra seulement terminer une procédure par un -9 (SIGKILL) signaler si ladite procédure / le programme est bloqué. Gardez à l'esprit que chaque fois que nous parlons de procédure ou de programme, les mots peuvent être échangés à volonté. Simplement, une procédure est n'importe quel programme (ou service) en cours d'exécution qui a reçu un PID (un identifiant de procédure).

Voyons un exemple de la façon de terminer une procédure d'arrière-plan en cours via un SIGKILL signal à la procédure en cours. Notez que, comme expliqué SIGKILL il est assez destructeur et mettra fin à la procédure, peu importe ce que la procédure veut faire avec le signal. La procédure peut capturer et rediriger plusieurs signaux, tandis que d'autres ne le font pas.

Envoi de SIGKILL à un processus de veille s'exécutant en arrière-plan

Ici, nous commençons un sleep 1800 en arrière-plan (à l'aide de & à la fin de la commande), qui a commencé comme le premier ([1]) procédure de fond avec PID 574660. Ensuite, nous tuons cette procédure d'arrière-plan en utilisant kill -9 574660, où il -9 Cela représente SIGKILL.

Bien que la procédure se termine immédiatement, nous ne voyons pas le message d'achèvement (procédure de fond 1 assassiné, En d'autres termes, [1]+ Killed) lorsque l'invite de commande revient avant que le message ne s'affiche, En d'autres termes, le retour de la ligne de commande était une opération plus rapide que l'achèvement de la procédure ou l'équivalent.

Nous vérifions la liste des processus en cherchant le PID ps -ef | grep 574660. Bien qu'il puisse y avoir une issue, la sortie affichée est pour notre exécution uniquement grep commander; Les sleep La procédure est déjà terminée.

Évaluons la même chose avec SIGTERM, En d'autres termes kill -15 ${PID}${PID} est la procédure que nous voulons terminer.

Envoi de SIGTERM à un processus de veille s'exécutant en arrière-plan

Nous avons dû appuyer sur Entrée pour activer / afficher le message d'achèvement (comme expliqué précédemment). On peut voir que le programme s'est à nouveau terminé correctement. Malgré cela, cette fois, même si invisible pour cet exemple particulier (continue de lire!), En interne au sein du sleep code de programme, les choses étaient un peu différentes.

Pour ce cas (à l'aide de -15 En d'autres termes SIGTERM terminer la procédure), les sleep La procédure a été notifiée et avait la possibilité de traiter le signal en interne. Ensuite, pourrait répondre en s'auto-terminant, en ignorant le signal ou par toute autre action développée dans le code. De plus, nous pouvons prouver que cela est vrai en vérifiant le signal de sortie et / ou la sortie:

La différence entre les codes de sortie et de sortie en fonction du signal envoyé

Ici, nous commençons la procédure sleep 2000 deux fois, puis utilisé une autre session shell / terminal pour terminer le programme. La première fois que nous utilisons kill -9 et la deuxième fois que nous utilisons kill -15 pour arrêter le sleep traiter.

Nous remarquons immédiatement comment la sortie revient. Killed en premier (kill -9 action) exemple. Pour le deuxième essai (à l'aide de kill -15), on voit la sortie Terminated au lieu de; le programme s'est terminé automatiquement. Après les résiliations respectives, nous avons également vérifié les signaux de sortie et constaté que les codes de sortie étaient différents.

Pourquoi est-ce important? Envisagez des programmes plus importants; dans cette circonstance, nous venions de terminer un simple sleep commander. Aucune donnée n'a été traitée, aucun trafic n'a été envoyé dans les deux sens, etc. Mais, Et si nous envoyions un kill -9 commande à notre serveur de base de données (cette, en général, nécessiterait des privilèges de niveau racine / sudo)?

Je réveillerais la base de données pour passer en mode de récupération après incident la prochaine fois qu'elle est démarrée car, pour autant que le logiciel de base de données le sache, tout ce qui s’est passé était “était là” suivi de “tout”. En d'autres termes, il s'est écrasé. Si au contraire nous avions émis un kill -15 , le logiciel de base de données peut avoir effectué un arrêt contrôlé, par exemple, bloquer d'abord la connexion des nouveaux utilisateurs, puis déconnecter / mettre fin aux utilisateurs existants, après avoir fini d'écrire les données, etc. avant en bref auto-terminer.

Envoi de signaux Linux avec des séquences de clavier

Saviez-vous qu'à chaque fois que vous envoyiez un CTRL+c séquence de touches à un programme en cours, comme exemple dans un terminal, qu'à la place un SIGINT est envoyé? Revenons à notre confiance sleep commande et essayez ceci:

Un processus de suspension interrompu par un signal SIGINT envoyé via une séquence de touches CTRL + C

Ici, nous commençons sleep de nouveau, puis appuyez sur la combinaison de touches CTRL+c. Le programme s'est terminé, ou mieux a été interrompu pour lui SIGINT signal qui a été envoyé. Nous demandons le code de sortie et confirmons qu'une fois de plus le code de sortie est différent des signaux précédents.

Veuillez noter que ce code de sortie, pour dormir, correspondra toujours au signal envoyé, même si tous les signaux peuvent ne pas être couverts. En d'autres termes, lors de l'utilisation CTRL+c sur la ligne de commande, le code de sortie sera toujours 130, 137 lorsqu'il est tué avec kill -9, et 143 lorsque kill -15 on l'a utilisé.

Vous pouvez tester les codes de sortie de la commande en vous référant à la $? variable, qui contient le code de sortie de la commande ci-dessus (tant qu'une nouvelle commande n'a pas démarré). Connaître le code de sortie d'une commande donnée dans une situation particulière, et / ou à la suite d'un signal particulier envoyé à cette commande, aide lors de la création de scripts de solutions qui gèrent d'autres processus, etc. (ce qui est le cas de nombreux scripts shell, en particulier lors de la gestion de serveurs ou d'environnements automatisés).

Une autre séquence de clavier fréquemment utilisée est CTRL+z. Cela enverra un SIGTSTP signe, ongle suspend signal qui met immédiatement une procédure en attente jusqu'à ce que (par exemple) un 'fg' La commande est émise pour la même procédure qui la ramènera au premier plan.

Pour plus d'informations sur la gestion des processus, consulter Bash Process Termination Hacks.

Fin

Dans ce billet, nous discutons des signaux Linux les plus importants et comment nous pouvons les utiliser pratiquement dans un environnement Linux ou Unix. Connaître les éléments de base de Linux aide à l'utilisation et à la gestion quotidiennes de Linux, par exemple, lorsqu'une procédure se bloque et doit être terminée avec kill -9. Dans un futur post, nous pouvons envisager de capturer un signal en utilisant le trap commande depuis un script bash, qui permet d'établir une procédure personnalisée qui sera exécutée lors de l'émission dudit signal.

Si vous avez aimé lire cet article, jetez un œil à notre série d'automatisation bash à partir de l'automatisation bash & Notions de base sur les scripts. Dans le troisième post de cette série, nous analysons également l'administration des processus en arrière-plan, qui a été mentionné précédemment dans ce post.

Abonnez-vous à notre newsletter

Nous ne vous enverrons pas de courrier SPAM. Nous le détestons autant que vous.