Cours Linux / PID et PPID : identifier les processus et leur parent

Le PID (Process ID) est le numéro qui identifie un processus vivant dans un espace de noms donné ; le PPID (Parent Process ID) est celui de son parent actuel. Pour les lire sous Linux, utilisez ps avec les colonnes pid et ppid. Un PID peut être réutilisé après la fin d’un processus et un PPID peut changer : aucun des deux n’est une identité permanente.

Comprendre la relation entre un processus et son parent

Un programme est un ensemble d’instructions ; un processus est une instance en cours d’exécution avec ses ressources et son état. Un shell qui lance une commande peut créer un processus enfant. Par exemple, dans un schéma fictif, Bash porte le PID 4250 et lance sleep avec le PID 4321 : pour sleep, PID vaut 4321 et PPID vaut 4250. Plusieurs enfants peuvent donc partager le même PPID tout en ayant des PID distincts.

Le numéro ne donne ni le propriétaire, ni les privilèges, ni l’état du processus. Il ne correspond pas non plus au numéro de tâche affiché entre crochets par jobs dans un shell. Pour relier ces notions à une manipulation d’arrière-plan et de signaux, consultez le cours sur les processus et les tâches du shell.

Afficher PID et PPID dans un terminal Linux

Ouvrez un terminal Linux utilisant Bash et une version de ps fournie par procps-ng. Les commandes de lecture suivantes ne nécessitent normalement pas sudo ; les règles d’accès à /proc peuvent toutefois limiter la visibilité. Les options du ps de BusyBox ou d’un autre système ne sont pas nécessairement identiques.

ps -p "$$" -o pid,ppid,user,stat,etime,args

Dans ce terminal Bash, $$ désigne le PID du shell. -p sélectionne ce numéro et -o choisit les colonnes. Voici une sortie illustrative, dont les valeurs ne sont pas à recopier :

    PID    PPID USER     STAT     ELAPSED COMMAND
   4250    4200 apprenti Ss         00:42 bash

Pour examiner tous les processus visibles, demandez explicitement les mêmes informations :

ps -eo pid,ppid,user,stat,args

Une liste trop longue peut être parcourue avec ps -eo pid,ppid,user,stat,args | less si less est installé ; q ferme le lecteur. Le guide de la commande ps détaille les sélections et formats. Selon le manuel de ps, il s’agit d’un instantané : un processus peut disparaître immédiatement après la lecture.

Repérer les enfants et distinguer $$ de BASHPID

Dans le même terminal, observez d’abord le shell puis ses enfants directs :

ps -p "$$" -o pid,ppid,user,lstart,args
ps --ppid "$$" -o pid,ppid,stat,args

La deuxième commande sélectionne les processus dont le PPID correspond au shell, sans rechercher récursivement tous les descendants. Elle peut afficher le ps exécuté pour cette observation. Si le shell n’a pas d’autre enfant actif, l’absence d’une longue liste est normale. Deux lectures successives ne décrivent pas forcément le même ensemble de processus.

Si pstree est disponible, pstree -p "$$" présente les descendants sous forme d’arbre avec leurs numéros. Pour chercher un nom précis, pgrep -a -x sleep affiche les correspondances visibles, éventuellement aucune ou plusieurs. Une correspondance de nom n’est pas nécessairement votre propre commande ; le guide de pgrep explique les limites de cette sélection.

Bash conserve la valeur de $$ dans un sous-shell créé par des parenthèses. Sa variable BASHPID désigne en revanche le processus Bash courant. Vous pouvez observer cette différence sans arrêter ni modifier de service :

printf 'shell : $$=%s BASHPID=%s\n' "$$" "$BASHPID"
( printf 'sous-shell : $$=%s BASHPID=%s\n' "$$" "$BASHPID" )

Les deux lignes doivent conserver le même $$, tandis que BASHPID change dans le sous-shell. Les numéros exacts dépendent de la session. Cette particularité explique pourquoi ps -p "$$" à l’intérieur de parenthèses ne sélectionne pas nécessairement le sous-shell observateur. Les définitions figurent dans les paramètres spéciaux de Bash et les variables de Bash.

Pourquoi le parent peut changer et ce qu’est un zombie

La fin du parent ne signifie pas systématiquement la fin de tous ses enfants. Sous Linux, un enfant devenu orphelin est rattaché au sous-récolteur compétent le plus proche, s’il existe, ou au processus init de son espace de noms. Un sous-récolteur est un processus désigné pour reprendre la surveillance de descendants orphelins. Le PPID observé peut donc différer du numéro du créateur initial. Les signaux, le terminal et le gestionnaire de services influencent aussi la survie des commandes : ne fermez pas une session de production pour tester cette relation.

Un zombie est déjà terminé, mais son état de fin n’a pas encore été collecté par le parent ou le processus chargé de le reprendre. ps le signale avec Z et peut afficher <defunct>. Il n’exécute plus son programme ; envoyer SIGKILL au zombie ne résout pas l’absence de collecte. Le parent utilise une opération de la famille wait pour récupérer l’état et permettre la libération des ressources restantes. La documentation de wait et waitpid décrit ce mécanisme.

Un zombie isolé peut être transitoire. Des zombies qui persistent ou s’accumulent justifient l’examen du parent et de ses journaux. Ne tuez pas le parent sans identifier son rôle, ses autres enfants et les conséquences pour les utilisateurs.

Comprendre les numéros dans les conteneurs

Les espaces de noms PID isolent la numérotation. Un processus d’un conteneur peut avoir le PID 1 dans son espace et un autre numéro visible depuis un espace ancêtre. Le PID 1 vu dans un conteneur n’est donc pas nécessairement le PID 1 de l’hôte. De même, un parent extérieur à l’espace visible peut être présenté avec le PPID 0 ; cela ne prouve pas une absence réelle de parent.

Sur Linux avec /proc accessible, ces lectures donnent des indications sur le shell du terminal :

readlink "/proc/$$/ns/pid"
grep -E '^(NStgid|NSpid):' "/proc/$$/status"

readlink affiche une référence de type pid:[…], utile pour comparer des espaces, pas un numéro de processus. NStgid décrit les numéros de groupe de threads, correspondant aux PID de processus usuels ; NSpid décrit les identifiants de thread. Pour le thread principal du shell, ces valeurs coïncident normalement. Les colonnes partent de l’espace de noms associé au montage de /proc puis progressent vers les espaces imbriqués : elles ne garantissent pas que le PID de l’hôte soit exposé.

Une seule valeur n’est pas une erreur ; les droits, le montage de /proc et le noyau peuvent limiter les informations. Pour comparer une observation sur l’hôte et dans un conteneur, identifiez d’abord l’endroit où chaque commande s’exécute. Les références sur les espaces de noms PID et les champs de /proc/PID/status expliquent ces différences.

Vérifier la cible avant une action d’administration

Avant d’utiliser un numéro relevé dans une ancienne sortie, recherchez de nouveau le processus et vérifiez au minimum le propriétaire, la commande et l’heure de démarrage. La colonne lstart utilisée plus haut aide à distinguer deux instances ; un PID libéré peut être attribué à un autre programme. Une lecture ps ne réserve pas le numéro et n’élimine pas la course entre vérification et action.

Pour un service géré par systemd, raisonnez avec son unité plutôt qu’avec un numéro conservé dans vos notes. Sur une machine où nginx.service existe, la commande de lecture suivante montre l’état connu du gestionnaire :

systemctl status nginx.service

Un redémarrage du service peut modifier ses PID et interrompre des connexions. N’effectuez cette action qu’après avoir choisi la bonne unité et une intervention adaptée. Le cours sur les services systemd explique la vérification des unités et des journaux. Pour cette leçon de lecture, aucune modification n’est à annuler : l’objectif est d’identifier les processus et leurs relations avant d’agir.