Un processus zombie sous Linux fait référence à ces processus déjà morts mais, d'une manière ou d'une autre, sont toujours présents dans la table des processus du système. La faille est que, pour une raison quelconque, ce processus n'a pas été nettoyé par le parent de la table des processus. Habituellement, cela se produit après la fin du processus d'exécution.
Le mode de fonctionnement habituel sous Linux est qu'après qu'un processus a terminé son exécution, il notifie son parent, qui est responsable de la suppression du processus de la table. Malheureusement, le parent est incapable de supprimer le processus de la mémoire dans les cas où le parent ne peut pas lire le statut de l'enfant. C'est ainsi que nous avons des processus morts dans la table des processus. C'est ce que nous appelons les processus zombies.
Qu'est-ce qui cause les processus Linux Zombie ?
Lorsque le processus enfant est créé, un processus parent mal écrit peut échouer à appeler la fonction wait(). En conséquence, ses enfants zombies resteront dans la mémoire jusqu'à ce qu'ils soient éteints.
Cela signifie que rien ne surveille le processus enfant pour les changements d'état, et le signal SIGCHLD sera ignoré. Peut-être qu'une autre application interfère avec l'exécution du processus parent, soit par une mauvaise programmation, soit par une intention malveillante.
La maintenance appropriée du système ne se produira pas si le processus parent ne surveille pas les changements d'état dans le processus enfant.
Lorsque le processus enfant se termine, le PCB et l'entrée dans la table de processus ne sont pas supprimés. L'état zombie n'est jamais supprimé du PCB à la suite de cela.
Les zombies ont de la mémoire, mais ce n'est généralement pas un problème. Étant donné que les systèmes Linux ont un nombre fini de PID (bien qu'un grand nombre), si suffisamment de PID sont zombies, aucun autre processus ne peut démarrer. Il est peu probable que cela se produise.
Cependant, les processus zombies suggèrent que quelque chose s'est mal passé avec une application et qu'un programme spécifique peut avoir un bogue.
Les bogues logiciels dans les centres de données ne doivent pas être tolérés et doivent être résolus.
Vous devez garder un œil et détruisez les processus zombies jusqu'à ce que la panne soit corrigée.
L'ID de processus ne peut pas être réutilisé tant qu'il n'est pas lancé, donc l'entrée de la table de processus est minuscule.
Comme le PCB est beaucoup plus grand que l'entrée de la table de processus dans un système d'exploitation 64 bits, il est peu probable que cela cause des problèmes. .
La quantité de mémoire disponible pour d'autres processus peut être affectée par un grand nombre de zombies. Cependant, si vous avez autant de zombies, vous avez un grave problème avec l'application mère ou un bogue dans le système d'exploitation.
Alors, que faites-vous lorsqu'une procédure se transforme en zombie ? Vous traquez et éliminez les processus zombies.
Comment trouver un processus zombie ?
L'arrêt initial pour tuer un processus zombie dans le système est d'abord de l'identifier. Étant donné que le processus d'initialisation nettoie régulièrement après les zombies, tout ce que vous avez à faire pour vous en débarrasser est de détruire le processus qui les a créés.
La commande supérieure est un moyen rapide de voir s'il y a des zombies dans votre région. Pour y parvenir, nous allons exécuter la commande suivante.
top
Le nombre de processus zombies dans ce système sera affiché sur la sortie. Dans notre cas ci-dessus, nous avons 0 zombies.
En utilisant la commande ps et en la transmettant à egrep, nous pouvons en obtenir une liste. L'indicateur d'état pour les processus zombies est "Z", et vous verrez parfois "défunt" également.
tuts@fosslinux:~$ ps aux | egrep "Z|defunct"
Décomposons les différentes sections de cette commande.
Z dans la colonne STAT de la sortie identifie un processus zombie.
[défunt] dans la dernière colonne (COMMANDE) de la sortie identifie également un processus zombie.
Idéalement, il n'est pas possible de tuer un processus Zombie car il est mort. Au lieu de cela, nous informons le parent d'essayer de lire l'état du processus de l'enfant et enfin de le nettoyer de la table du système. Pour déclencher ce processus, nous envoyons un signal SIGCHLD au parent du processus. L'identification de l'ID du processus parent ou ce qu'on appelle le PID implique l'exécution de la commande suivante :
tuts@fosslinux:~$ ps -o ppid= <Child PID>
Après avoir obtenu le PID du Zombie, utilisez le signal de commande SIGCHLD vers les processus parents précédemment identifiés.
tuts@fosslinux:~$ kill -s SIGCHLD <Parent PID>
Dans certains cas, cela n'efface pas le processus Zombie. Cela nous appelle à nous engager dans le plan b ou c. Le précédent implique de redémarrer le processus parent ou de tuer les processus parents. D'autre part, ces derniers cas impliquent de redémarrer le système, en particulier lorsque le processus Zombie pourrait provoquer une panne ou une augmentation massive à cause du processus Zombie.
Ci-dessous se trouve la commande pour tuer le processus parent.
tuts@fosslinux:~$ kill -9 <Parent PID>
Dans le cas où un processus parent est tué, par extension, tous les processus enfants du parent donné sont également tués. Dans le cas où l'un des processus enfants est critique à un moment donné, vous devrez peut-être reporter la mise à mort jusqu'à ce qu'il soit sûr. D'un autre côté, une double vérification rapide peut vous dire combien de mémoire ou de puissance de traitement les processus Zombie consomment. Cela aide à déterminer si la meilleure option est de tuer le processeur parent pour effectuer un redémarrage du système dans le cycle suivant de la maintenance du système qui est déjà planifiée.
Sous Linux, comment fonctionnent les états des processus ?
Bien sûr, Linux doit garder une trace de toutes les applications et démons exécutés sur votre ordinateur. La maintenance de la table des processus est l'un des moyens d'y parvenir.
Ceci est une liste des structures de mémoire du noyau. Cette liste comprend une entrée pour chaque processus qui contient des informations à son sujet. Chacune des structures de table de processus contient très peu d'informations.
Ils stockent l'ID de processus, quelques autres informations et un pointeur vers le bloc de contrôle de processus (PCB).
Le PCB est l'endroit où Linux stocke toutes les informations dont il a besoin pour rechercher ou définir pour chaque processus. Lorsqu'un processus est créé, il est modifié, compte tenu du temps de traitement, puis détruit.
Il y a plus de 95 champs sur le PCB Linux. Il est défini dans la structure des tâches, qui compte plus de 700 lignes. Les types d'informations suivants peuvent être trouvés sur le PCB :
Les états du processus sont illustrés ci-dessous
- Numéro de processus :identifiant distinctif du système d'exploitation.
- Compteur de programme :lorsque ce processus aura à nouveau accès au CPU, le système utilisera cette adresse pour localiser la prochaine instruction du processus à exécuter.
- Registres :cette procédure utilise une liste de registres CPU appelés registres. Les accumulateurs, les registres d'index et les pointeurs de pile peuvent être inclus dans la liste.
- Liste des fichiers ouverts :les fichiers associés à cette procédure sont inclus dans la liste des fichiers ouverts.
- Informations de planification du processeur :utilisées pour calculer la fréquence et la durée pendant lesquelles ce processus reçoit le temps de traitement du processeur.
Le PCB doit enregistrer la priorité du processus, les pointeurs vers les files d'attente de planification et d'autres paramètres de planification. - Informations sur la gestion de la mémoire :informations sur la mémoire utilisée par ce processus, telles que les adresses de début et de fin de la mémoire de processus, ainsi que des pointeurs vers des pages de mémoire.
- Informations sur l'état des E/S :tous les appareils que le processus utilise comme entrées ou sorties.
L'un des éléments suivants peut être "l'état du processus" :
- R :un processus en cours d'exécution ou capable de s'exécuter. Il est en cours d'exécution, ce qui signifie qu'il reçoit et exécute des cycles CPU.
Une procédure prête à être exécutée attend un slot CPU. - S :action de dormir.
Le processus attend la fin d'une action, telle qu'une opération d'entrée ou de sortie. Ou la disponibilité d'une ressource. - D :La procédure est dans un état de sommeil non interruptible. Il utilise un appel système bloquant, ce qui signifie qu'il ne se poursuivra pas tant que les appels système ne seront pas terminés. Contrairement à l'état "Veille", un processus dans cet état ne répondra pas aux signaux tant que l'appel système n'est pas terminé et que l'exécution n'est pas revenue au processus.
- T :Parce qu'il a reçu le signal SIGSTOP, le processus est terminé (arrêté).
Il ne répondra qu'aux signaux SIGKILL ou SIGCONT, soit en tuant, soit en demandant au processus de continuer. Lorsque vous passez des tâches de premier plan (fg) aux tâches d'arrière-plan (bg), cela se produit. - Z :signifie Zombie Process. Lorsqu'un processus est terminé, il ne disparaît pas simplement. Au lieu de cela, il libère toute mémoire qu'il utilise actuellement et quitte la mémoire, mais son entrée de table de processus et son PCB restent.
Son état est défini sur EXIT ZOMBIE, et son processus parent est informé que le processus enfant a été terminé via le Signal SIGCHLD.
Conclusion
À moins qu'ils ne fassent partie d'une vaste horde, les zombies ne sont pas si dangereux. Quelques-uns ne sont pas un gros problème, et un redémarrage rapide les effacera. Cependant, il y a un point à considérer.
Les architectures Linux ont un nombre maximum de processus et, par conséquent, un nombre maximum de numéros d'identification de processus. Lorsque le nombre maximum de processus zombies d'un ordinateur est atteint, de nouveaux processus ne peuvent pas être démarrés.
Les processus zombies ne sont pas des processus; ce sont les restes de processus morts que leur processus parent n'a pas correctement nettoyés. Cependant, si vous remarquez qu'une application ou un processus particulier génère constamment des zombies, vous devriez enquêter plus avant.
Très probablement, c'est juste un programme mal écrit; dans ce cas, il existe peut-être une version mise à jour qui se nettoie une fois que son enfant a été correctement traité.