SIGINT, SIGTERM et SIGKILL –

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 quelques-uns se démarquent et sont importants à comprendre et à connaître: SIGINT, SIGTERM et SIGKILL. Voici comment 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. De même, dans les systèmes Linux et Unix, on peut passer un signal à un programme ou service en cours d’exécution pour interagir avec lui. Par exemple, on pourrait envoyer un panneau de signalisation rouge à un programme en émettant simplement un SIGTERM signal.

Tout 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, une SIGTERM le signal envoyé à un processus fera exactement cela; le processus / programme peut choisir d’ignorer un tel signal.

Les signaux Linux de base ont tous un numéro (1-30 +). Après un certain temps, un utilisateur Linux compétent en connaîtra généralement un ou plusieurs. Par exemple, le SIGTERM le signal correspond au numéro 15 et au signal 9 (SIGKILL) est probablement la plus connue car elle permet de mettre fin de force à un processus, contrairement à notre SIGTERM exemple de lumière rouge.

Ici, nous voyons l’écran principal de htop (vous pouvez installer cet utilitaire pratique en tapant sudo apt install htop sur Ubuntu / Mint, ou sudo yum install htop sur RedHat / Centos / Fedora) avec un certain nombre de terminaisons et d’autres signaux (plus bas dans la liste; il y en a 37 au total) qui peuvent être envoyés à un processus préalablement sélectionné à droite. On peut sélectionner un processus en appuyant sur le curseur haut / bas, puis envoyer un signal en utilisant F9.

SIGKILL ET SIGTERM

Bien que le nom puisse sembler un peu sinistre, le jargon Linux commun pour la terminaison de processus est que l’on «tue» un processus. De manière générale, nous ne voulons mettre fin à un processus qu’avec un -9 (SIGKILL) signalent si un tel processus / programme est suspendu. Notez que chaque fois que nous parlons de processus ou de programme, les mots peuvent être interchangés à volonté. Fondamentalement, un processus est tout programme (ou service) en cours d’exécution auquel un PID (un identifiant de processus).

Regardons un exemple de fin d’un processus d’arrière-plan en cours à l’aide d’un SIGKILL signal au processus en cours. Notez que comme expliqué SIGKILL est plutôt destructif et mettra fin au processus, peu importe ce que le processus voudrait faire avec le signal. Un certain nombre de signaux peuvent être capturés et redirigés par le processus, tandis que d’autres ne le peuvent pas.

Ici, nous avons commencé un sleep 1800 en arrière-plan (en utilisant & à la fin de la commande), qui a été lancée comme le premier ([1]) processus d’arrière-plan avec PID 574660. Nous avons ensuite tué ce processus d’arrière-plan en utilisant kill -9 574660, où le -9 signifie SIGKILL.

Bien que le processus se termine immédiatement, nous ne voyons pas le message de fin (processus d’arrière-plan 1 tué, c’est-à-dire [1]+ Killed) comme l’invite de commande retourne avant que le message ne soit affiché, c’est-à-dire que le retour de la ligne de commande était une opération plus rapide que la fin du processus, ou similaire.

Nous vérifions la liste des processus en recherchant le PID ps -ef | grep 574660. Bien qu’il y ait une sortie, la sortie affichée est uniquement pour notre exécution grep commander; les sleep le processus est déjà terminé.

Évaluons la même chose avec SIGTERM, c’est à dire kill -15 ${PID} où ${PID} est le processus que nous voulons mettre fin.

Nous avons dû appuyer sur Entrée pour déclencher / afficher le message de terminaison (comme expliqué ci-dessus). Nous pouvons voir que le programme s’est à nouveau terminé correctement. Cependant, cette fois, bien qu’invisible pour cet exemple particulier (lisez la suite!), En interne à l’intérieur du sleep code du programme, les choses sont allées un peu différemment.

Dans ce cas (en utilisant -15 c’est à dire SIGTERM pour terminer le processus), le sleep processus a été notifié et a eu la possibilité de gérer le signal en interne. Il pourrait ensuite répondre en s’auto-terminant, en ignorant le signal, ou par toute autre action développée dans le code. Nous pouvons également prouver que cela est vrai en vérifiant le signal de sortie et / ou la sortie:

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

Nous remarquons immédiatement comment la sortie retourne Killed en premier (kill -9 action). Pour la deuxième tentative (en utilisant kill -15), nous voyons la sortie Terminated plutôt; le programme s’est terminé automatiquement. Après les terminaisons 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 ce cas, nous étions juste en train de terminer un simple sleep commander. Il n’y avait aucune donnée en cours de traitement, pas de trafic envoyé / retour, etc. Mais que se passerait-il si nous envoyions un kill -9 commande à notre serveur de base de données (cela nécessiterait généralement des privilèges sudo / racine)?

Cela déclencherait la base de données pour passer en mode de récupération après incident au prochain démarrage car, pour autant que le logiciel de base de données le sache, tout ce qui s’est passé était «était là» suivi de «rien». En d’autres termes, il s’est écrasé. Si nous avions plutôt émis un kill -15 commande, le logiciel de base de données aurait pu effectuer un arrêt contrôlé, par exemple, en bloquant d’abord les nouveaux utilisateurs de se connecter, puis en déconnectant / en mettant fin aux utilisateurs existants, puis en finissant d’écrire des données, etc. avant de finalement s’auto-terminer.

Envoi de signaux Linux avec des séquences de clavier

Saviez-vous que chaque fois que vous envoyez un CTRL+c séquence de touches à un programme en cours d’exécution, par exemple dans un terminal, qui à la place SIGINT est envoyé? Revenons à notre confiance sleep commande et testez ceci:

Ici nous avons commencé sleep à nouveau, puis appuyez sur la combinaison de touches CTRL+c. Le programme s’est terminé, ou mieux a été interrompu par le 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.

Notez que ce code de sortie, pour le sommeil, sera toujours mis en correspondance avec le signal envoyé, bien que potentiellement tous les signaux ne soient pas couverts. En d’autres termes, lors de l’utilisation CTRL+c en ligne de commande, le code de sortie sera toujours 130, 137 une fois tué avec kill -9, et 143 lorsque kill -15 a été utilisé.

Vous pouvez tester les codes de sortie des commandes en interrogeant le $? variable, qui contient le code de sortie de la commande précédente (tant que vous n’avez pas commencé une nouvelle commande). 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 l’écriture de solutions qui gèrent d’autres processus, etc. (ce qui est le cas pour de nombreux scripts shell, en particulier lors de la gestion de serveurs ou d’environnements automatisés).

Une autre séquence de clavier souvent utilisée est CTRL+z. Cela enverra un SIGTSTP signal, un suspend signal qui met immédiatement un processus en suspension jusqu’à ce que (par exemple) un 'fg' La commande est émise pour le même processus qui le ramènera au premier plan.

Pour en savoir plus sur la gestion des processus, consultez Hacks de terminaison de processus Bash.

Emballer

Dans cet article, nous avons examiné les signaux Linux les plus importants et comment nous pouvons les utiliser pratiquement dans un environnement Linux ou Unix. Connaître les signaux Linux de base facilite l’utilisation et la gestion quotidiennes de Linux, par exemple, lorsqu’un processus est suspendu et doit être terminé avec kill -9. Dans un prochain article, nous pourrions envisager de capturer un signal à l’aide du trap commande depuis l’intérieur d’un script Bash, permettant de définir une procédure personnalisée à exécuter lorsqu’un tel signal est émis.

Si vous avez aimé lire cet article, jetez un œil à notre série d’automatisation Bash en commençant par Bash Automation & Scripting Basics. Dans le troisième article de cette série, nous abordons également la gestion des processus d’arrière-plan, évoquée plus haut dans cet article.