Identifier les processus zombies sur un serveur de jeu Linux

Un processus zombie Linux n’est plus en train d’exécuter du code, mais son entrée reste visible jusqu’à ce que son processus parent récupère son état de sortie. Sur un serveur VPS, c’est-à-dire un serveur virtuel hébergé dans une infrastructure cloud, quelques zombies isolés ne signifient pas forcément une panne. Une accumulation mérite en revanche un diagnostic méthodique depuis une session SSH.

Comprendre un processus zombie

Un processus devient zombie lorsque son exécution est terminée et que son parent n’a pas encore lu son statut. Il ne consomme normalement plus de temps CPU ni de mémoire utilisateur comme un processus actif. Il conserve toutefois une entrée dans la table des processus, ainsi qu’un identifiant PID. Le phénomène vient souvent d’un programme parent qui ne traite pas correctement la fin de ses enfants.

Il ne faut donc pas confondre zombie, processus bloqué et processus gourmand. Pour un serveur de jeu, regardez séparément la charge CPU, la RAM, les I/O disque, l’espace disque et la bande passante. Retrouvez les bases de l’administration dans notre guide des premiers réglages d’un serveur dédié.

Repérer les zombies avec ps

Connectez-vous au VPS avec SSH, puis observez la liste des processus avec les droits de votre compte :

ps -eo user,pid,ppid,stat,etime,cmd --sort=ppid

Dans la colonne STAT, la lettre Z indique un processus zombie. Les colonnes PID et PPID permettent de relier l’enfant terminé à son parent. Pour filtrer rapidement les lignes concernées :

ps -eo pid,ppid,stat,cmd | awk '$3 ~ /^Z/'

Notez le nombre de lignes, les PID parents et la commande concernée avant toute action. Sur Ubuntu ou Debian, contrôlez aussi le service systemd qui lance le serveur. Sur une installation Pterodactyl, identifiez le conteneur Docker ou le service qui lance le processus. Notre guide des sauvegardes Pterodactyl rappelle pourquoi une intervention doit préserver les données du serveur.

Évaluer l’impact sur le VPS

Un zombie ponctuel peut disparaître lorsque son parent effectue enfin la récupération attendue. Surveillez l’évolution plutôt que de supprimer immédiatement un PID. Rejouez la commande après quelques minutes et comparez le nombre de zombies. Si la liste augmente, recherchez un redémarrage récent, une erreur répétée dans le programme parent ou un script qui lance des sous-processus sans les attendre.

Contrôlez en parallèle les ressources utiles : uptime pour la charge CPU, free -h pour la RAM et la mémoire swap, df -h pour les systèmes de fichiers et df -i pour les inodes. Une saturation du stockage SSD, de la RAM ou du réseau peut provoquer des symptômes distincts. Consultez notre guide Docker sur VPS si le serveur tourne en virtualisation par conteneurs, et notre méthode de diagnostic d’un VPS inaccessible si le problème est en réalité réseau ou lié à l’adresse IP.

Agir sur le processus parent

Un zombie ne se termine pas avec un simple kill comme un processus actif : son code est déjà terminé. L’action doit viser le parent, avec prudence. Avant toute relance, identifiez le service, vérifiez sa configuration et prévenez les joueurs si une interruption est possible. Une relance contrôlée du service parent permet souvent de récupérer les enfants terminés, mais elle peut interrompre le serveur de jeu et ses ports réseau.

N’envoyez pas de signal à un PID dont vous ne connaissez pas le rôle. Utilisez d’abord ps -p PID_PARENT -o pid,ppid,stat,cmd, puis consultez les journaux du service. Pour les unités systemd, journalctl -u nom-du-service aide à retrouver les erreurs autour de l’apparition des zombies. Vérifiez que votre compte root ou votre utilisateur d’administration dispose des droits nécessaires. Notre checklist de sécurisation peut servir de point de départ pour limiter les interventions improvisées.

Prévenir la récurrence

Conservez une mesure simple du nombre de zombies, de la charge du serveur VPS, de l’usage RAM et de l’espace disque. Ajoutez une alerte dans votre outil de monitoring lorsque la valeur augmente de façon continue, puis associez-la aux logs du service parent. Mettez à jour le logiciel concerné selon sa documentation et testez la correction sur un environnement de préproduction quand c’est possible. Une sauvegarde récente, parfois appelée backup, reste indispensable avant une modification du service. Découvrez aussi nos principes de sauvegarde pour serveur dédié.

Le contexte d’hébergement à vérifier

Que vous hébergiez un serveur Minecraft, FiveM ou Rust sur un VPS Linux, vérifiez le système d’exploitation, le processeur, la mémoire RAM et l’espace disque attribués. Un hébergeur fournit parfois un panneau de contrôle ou une solution d’infogérance pour suivre ces ressources, mais la commande SSH et les journaux système restent la référence pour le processus parent. Un firewall n’explique pas un zombie, pas plus qu’un DNS ou un nom de domaine : ces éléments concernent le réseau et l’accès au service, pas la récolte de l’état d’un processus.

Dans une machine virtuelle ou un serveur cloud, les serveurs virtuels partagent une infrastructure, tandis qu’un serveur dédié réserve ses ressources physiques. Pour héberger un jeu, un serveur privé, un serveur dédié virtuel ou un VPS cloud peuvent fournir des environnements différents selon la configuration et l’hyperviseur. Cette différence peut compter lors d’une migration ou d’un changement d’offre VPS, mais elle ne change pas le diagnostic des processus.

Le problème ne dépend pas d’un hébergement mutualisé, d’un serveur web Apache ou d’une base MySQL : il faut isoler la commande réellement responsable et vérifier les journaux du système d’exploitation.