Phenquestions
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 de processus. Habituellement, cela se produit après la fin du processus d'exécution.
Le mode de fonctionnement habituel sous Linux est qu'une fois 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.
Quelles sont les causes des processus Linux Zombie?
Lorsque le processus enfant est créé, un processus parent mal écrit peut ne pas 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 infantile 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 programmation moche, soit par une intention malveillante.
Le bon entretien 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 infantile se termine, le PCB et l'entrée dans la table de processus ne seront 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 douteux que cela se produise.
Cependant, les processus zombied suggèrent que quelque chose ne va pas 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 sur les processus zombies et les détruire jusqu'à ce que le problème soit corrigé.
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.
Parce que le PCB est beaucoup plus gros 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 parente 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. Parce que le processus d'initialisation nettoie régulièrement 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.
Haut
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 canalisant dans 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|défunt"
Décomposons les différentes sections de cette commande.
Z dans la colonne STAT de la sortie identifie un processus zombie.
[defunct] dans la dernière colonne (COMMAND) 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=
Après avoir obtenu le PID du Zombie, utilisez la commande SIGCHLD signal aux processus parents précédemment identifiés.
tuts@fosslinux:~$ kill -s SIGCHLD
Dans certains cas, cela n'efface pas le processus Zombie. Cela nous appelle à nous engager dans le plan b ou c. Le préalable implique le redémarrage du processus parent ou la suppression des processus parents. D'autre part, ces derniers cas impliquent de faire un redémarrage du système, en particulier lorsque le processus Zombie pourrait provoquer une panne ou une surtension massive à cause du processus Zombie.
Ci-dessous se trouve la commande pour tuer le processus parent.
tuts@fosslinux:~$ kill -9
Dans le cas où un processus parent est tué, par extension, tous les processus enfants du parent donné sont également tués. Si l'un des processus enfants est critique à un moment donné, vous devrez peut-être reporter le meurtre 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 permet de 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 maintenance du système qui est déjà planifié.
Sous Linux, comment fonctionnent les états des processus?
Bien sûr, Linux doit garder une trace de toutes les applications et démons en cours d'exécution sur votre ordinateur. Le maintien de la table de 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 obtient à nouveau l'accès à la 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. Des accumulateurs, des registres d'index et des 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.
- CPU Scheduling Information : utilisé pour calculer à quelle fréquence et pendant combien de temps ce processus reçoit le temps de traitement du CPU.
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 du 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 d'exécuter. Il est en cours d'exécution, ce qui signifie qu'il obtient et exécute des cycles CPU.
Une procédure prête à s'exécuter attend un emplacement CPU. - S : L'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 en état de sommeil non interruptible. Il utilise un appel système bloquant, ce qui signifie qu'il ne continuera 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, en tuant ou en ordonnant au processus de continuer. Lorsque vous passez des tâches de premier plan (fg) à celles 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 la mémoire qu'il utilise actuellement et quitte la mémoire, mais son entrée dans la 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 est 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 maximal de processus et, par conséquent, un nombre maximal de numéros d'identification de processus. Lorsque le nombre maximal de processus zombies d'un ordinateur est atteint, les 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 devez approfondir vos recherches.
Très probablement, c'est juste un programme mal écrit ; dans ce cas, il existe peut-être une version mise à jour qui se nettoie après que son enfant se soit correctement traité.
