Qu'est-ce qu'un processus zombie ?
Les processus zombies sont les processus qui ont terminé leur tâche, mais le processus parent (le plus probable) est mort ou s'est écrasé de manière inattendue. Ils peuvent également indiquer un code bogué. La plupart des utilisateurs ne comprennent pas bien ce que sont les processus zombies et comment ils affectent un hôte Linux. Tout d'abord, un petit nombre (disons dix, par exemple) de processus zombies ne contribuent pas à la charge du système. En fait, des milliers de zombies ne contribueraient pas à la charge du système.
Par définition, les processus zombies ne consomment pas de ressources, pour la plupart. Chaque processus zombie se voit toujours attribuer un numéro d'identification de processus, ou PID. Sur les systèmes 32 bits, le nombre maximal de PID disponibles est de 32 767. Pour les systèmes 64 bits, ce nombre augmente de manière exponentielle jusqu'à plus de 4 millions.
Il y a aussi une petite quantité de mémoire utilisée pour chaque processus zombie. Techniquement, il faudrait des dizaines de milliers, voire des centaines de milliers de processus zombies pour épuiser considérablement les ressources système.
Il y a 2 scénarios que je vais discuter ici. Le premier est un processus qui génère de nombreux PID enfants, puis le PID parent se bloque ou meurt sans récolter les PID enfants. Normalement, ce problème indiquerait un bogue possible avec le programme ou le code. Lorsque cela se produit, le PID 1 (ou le processus d'initialisation) en prend possession. Aux fins de ce tutoriel, le chemin le plus rapide pour se débarrasser de ces zombies est de redémarrer. Il est également possible de créer un processus factice et de transmettre la propriété de ces processus zombies au PID factice pour le nettoyer. C'est hors de portée ici. Redémarrez et finissons-en !
Le deuxième scénario est lorsqu'un processus est bloqué à un point tel que le système d'exploitation le considère comme en cours d'exécution, mais le processus ne fait rien. L'exemple que j'utilise pour cette discussion est le démon de l'outil de rapport de bogue automatique (abrtd ) fourni avec Red Hat Enterprise Linux et certaines autres distributions. C'est un excellent outil, et j'aime le faire fonctionner sur un système car cela me donne, en tant qu'administrateur système, une meilleure vue de ce qui se passe ou se bloque, mais sans appeler le noyau de plantage.
Dans mon environnement, ce démon est aussi un peu un talon d'Achille. Par défaut, abrtd crée uniquement des informations pour les applications signées. Toute application peut être signée pour générer un bogue, mais si une application non signée déclenche abrtd , le démon procède à la création d'un rapport de bogue, puis supprime tout ce qu'il a créé. Ce comportement peut entraîner des problèmes avec une action suspendue pour une application non signée.
Prenons un exemple. Un utilisateur soumet un rapport d'incident indiquant que le système était lent en raison de six processus zombies. Il y a des cadeaux morts sur un système qui abrtd a des problèmes. Lorsque vous su - pour rooter, vous verrez ce qui suit :
'abrt-cli status' timed out
Si nous vérifions le abrtd processus nous pouvons voir qu'il est toujours en cours d'exécution, mais un processus enfant est en cours d'exécution depuis le 30 mai.
[root@$HOSTNAME ~]# systemctl status abrtd
● abrtd.service - ABRT Automated Bug Reporting Tool
Loaded: loaded (/usr/lib/systemd/system/abrtd.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2019-04-27 08:36:47 EDT; 2 months 13 days ago
Main PID: 1161 (abrtd)
Tasks: 12
Memory: 34.0M
CGroup: /system.slice/abrtd.service
├─ 1161 /usr/sbin/abrtd -d -s
├─60777 abrt-server -s
├─60867 /usr/libexec/abrt-handle-event -i -e post-create -- /var/spool/abrt/unsigned-app-2019-05-30-01:48:24-57451
├─64714 abrt-server -s
├─68157 abrt-server -s
├─70725 abrt-server -s
├─74101 abrt-server -s
├─77136 abrt-server -s
├─81417 abrt-server -s
├─84637 abrt-server -s
├─88183 abrt-server -s
└─90022 abrt-server -s
Alors abrtd est toujours techniquement en cours d'exécution, mais ce processus de post-création a créé un état dans lequel certains nouveaux rapports d'erreur ABRT ont essayé de s'exécuter, mais sont devenus des zombies. À ce stade, vous pouvez redémarrer le abrtd service, et cette action effacera tous les processus zombies.
Mais, si vous ne saviez pas que c'était le cas, voici comment vous recherchez quel PID est le parent des zombies en utilisant le ps -xal commande. Cette commande génère un lot d'informations, je vais donc vous montrer les colonnes dont nous avons besoin :
[root@$HOSTNAME ~]# ps -xal | awk '{ print $4 " " $10 " " $13 }' | sort -n
1739 Ssl+ java
1903 S bin/rscd
1903 S bin/rscd
2391 Ssl+ node
2816 Ssl+ java
2889 Ssl+ java
3785 Ss appcollect
3785 Ss appconfigcollect
3926 Ssl+ java
4696 Ss /bin/sh
4731 S bin/bash
4827 Sl /myappbinaries/jre/bin/java
7074 Ss+ httpd
7095 S+ httpd
La quatrième colonne est le PID du parent, la dixième colonne est le statut du processus enfant (évidemment, vous chercheriez des PID dans un état Z), et la treizième colonne est le processus enfant. En utilisant le PID parent dans la colonne quatre, vous pouvez maintenant tuer ce processus parent et ses enfants zombies disparaîtront également. Sauf si ce PID parent est 1, auquel cas un redémarrage sera nécessaire.
Étant en opération, nous n'avons pas toujours le luxe de redémarrer à tout moment. Personnellement, je pense que le redémarrage devrait être le dernier recours. Les redémarrages cachent une multitude de péchés et laissent ces péchés se présenter au moment le plus inopportun, généralement tard le soir ou les week-ends de vacances !
Oh, et la charge sur ce système n'a pas baissé d'un bit après le redémarrage de abrtd et éliminer ces 6 zombies.