Linux : limites de ressources et processus zombies

Vérifier la limite du processus réel

La recette du wiki changeait limits.conf puis ouvrait une session avec su. Les limites d’une session passée par PAM ne représentent pas forcément celles d’un service lancé par systemd. Les cgroups et les paramètres d’unité peuvent limiter d’autres ressources indépendamment des ulimit.

Inspectez le processus concerné et sa configuration de lancement. L’exemple nécessite de remplacer PID par un identifiant réel. Après un changement, vérifiez la valeur effective sur une nouvelle exécution du service plutôt que supposer l’application immédiate à un processus existant.

cat /proc/PID/limits
systemctl show nom.service -p LimitNOFILE -p TasksMax

Un zombie n’est plus un programme à tuer

Un processus zombie est terminé, mais ses informations de sortie attendent d’être récupérées. Lui envoyer SIGKILL ne le fait pas revenir à une exécution normale ni ne corrige le parent qui ne récolte pas les états de sortie. Identifiez le parent, son comportement et le responsable du service avant une relance.

La fiche Solaris mentionnait preap et affirmait que Solaris était le seul Unix capable de « tuer un zombie ». Cette généralisation est retirée. Un outil Solaris spécifique doit être compris selon sa documentation ; il n’est pas une commande Linux universelle.

Corriger la cause et vérifier la charge

Un plafond atteint peut venir d’un besoin légitime, d’une fuite de descripteurs, d’une multiplication de tâches ou d’un incident applicatif. Mesurez l’évolution dans le temps et fixez une limite compatible avec la capacité du serveur.

Après correction, vérifiez le fonctionnement en charge et la persistance au redémarrage. Documentez l’alerte à déclencher avant épuisement. Relever arbitrairement toutes les limites peut seulement déplacer la panne vers la mémoire ou un service voisin.