Pour communiquer entre eux, les processus utilisent des messages et des signaux que le système d’exploitation se charge de délivrer par le biais de tubes. Les signaux peuvent être directement envoyés à l’aide de la commande kill qui peut s’avérer très utile lorsqu’un processus se comporte de manière inattendue.
Un processus peut cependant choisir de ne pas répondre à certains signaux, ce refus dépend du niveau critique de la tâche en cours qui peut parfois modifier l’état du processus, le rendant temporairement hermétique à toutes demandes externes.
La commande kill
La commande kill en elle même est simple d’utilisation, elle permet d’envoyer un signal à un processus. Le manuel nous renseigne sur son utilisation :
kill [options] <pid> |
De façon plus précise, lorsque la commande kill est utilisée, elle envoie un signal particulier au processus ciblé, ce dernier l’examine et exécute en se référant au fichier signal.h. (Le fichier signal.h fait partie de la bibliothèque C et est utilisé pour traiter les signaux).
La liste des signaux disponibles est accessible avec l’option -l de la commande kill.
kill -l |
Pour plus de détails sur les signaux vous pouvez vous référer à la section 7 du manuel de signal : man 7 signal.
Parmi ces signaux nous avons par exemple :
- SIGHUP (signal n°1) qui indique au processus qu’il doit relire sa configuration.
- SIGTERM (signal n°15) qui demande au processus de s’arrêter proprement et d’en informer ses éventuels fils.
- SIGCHLD (signal n°17) qui est envoyé au processus père pour l’informer de la mort de son fils.
- SIGSTOP (signal n°19) qui met en pause l’exécution du processus.
- SIGKILL (signal n°9) qui termine le processus brutalement.
Les signaux SIGKILL et SIGSTOP ont une particularité, ils ne sont pas envoyés au processus mais directement adressés au système qui se chargera de stopper ou d’arrêter le processus.
Si rien n’est précisé dans la commande kill, le signal par défaut sera SIGTERM, kill est donc équivalent à kill -15 et le processus s’arrêtera donc proprement.
SIGTERM contre SIGKILL
L’envoi des signaux SIGTERM ou SIGKILL par le biais des commande kill et kill -9 sur des processus ont des effets très différents.
Le signal SIGTERM est couramment utilisé pour simplement mettre fin à une application. SIGKILL quand à lui permet de forcer un arrêt mais l’effectue de façon brutale.
Le signal SIGTERM
Les commandes ci-dessous sont équivalentes et permettent toutes de mettre fin au processus n° 1337 en envoyant le signal SIGTERM, signal n°15.
# kill 1337 |
Après avoir reçu un tel signal le processus s’arrête immédiatement (ou après un bref délais, le temps de libérer les ressources et d’arrêter les processus fils).
Ce signal permet au processus de lui laisser la possibilité d’informer ses processus fils qu’il va se terminer, de finir sa tâche, de permettre au processus fils de finir la leur, d’informer leur père le cas échéant et d’enfin libérer les ressources. Il s’agit là donc d’un arrêt tout à fait normal pour un processus.
Il existe cependant des cas ou le processus semble ignorer ce signal et continue quand même de s’exécuter car il effectue une tâche qui ne doit pas être interrompue.
Lorsqu’un processus ne répond pas au signal SIGTERM et qu’il est nécessaire d’y mettre un terme, il est possible d’utiliser le signal SIGKILL.
Le signal SIGKILL
Les commandes ci-dessous sont équivalentes et permettent toutes de mettre fin au** processus n° 1337** en envoyant le signal SIGKILL, signal n°9.
# Kill -9 1337 |
Le signal SIGKILL, contrairement au signal SIGTERM, est directement envoyé au noyau, c’est donc le système qui va stopper le processus et ce signal ne peut être ignoré.
L’utilisation du signal SIGKILL peut entraîner des problèmes car l’arrêt est brutal, le processus ne pourra pas terminer sa tâche en cours, libérer correctement les ressources et informer ses processus fils de son arrêt qui, devenus orphelins, seront alors adoptés par init.
L’envoi d’un signal SIGKILL devrait suffire à stopper un processus puisqu’il est directement géré par le noyau, cependant il existe toutefois un cas (plutôt rare) où SIGKILL est malheureusement sans effet. Le dernier recours sera alors le redémarrage du système.
Le redémarrage système
Lorsqu’un processus est en attente d’une ressource matérielle il passe en sommeil ininterruptible (état D), cet état qui ne peut être interrompu permet au processus de gérer les accès au ressources matérielles en toute sécurité. Le processus sera de nouveau réceptif aux signaux dès que la ressource demandée sera de nouveau disponible ou après un time-out si ce dernier a été spécifié avant son sommeil.
Il est parfois possible, suite à un bug matériel ou à une erreur de conception, qu’un processus ne puisse jamais accéder à cette ressource et reste bloqué dans l’état D. Si de tels processus doivent malgré tout être arrêtés, il reste un dernier recours : le redémarrage du système.
C’est le seul rare cas où il est nécessaire de redémarrer un système Linux. Ce choix des développeurs s’explique par soucis de stabilité, pouvoir stopper un processus en lien direct avec des échanges d’informations entre le processeur et les périphériques est trop compromettant pour le système.