Gérer les processus sous Linux

Cinq commandes suffisent pour maîtriser les processus Linux : ps, top, kill, nice et renice. Avec elles, vous identifierez le processus qui monopolise un CPU, ajusterez sa priorité, et l'arrêterez proprement, sans jamais redémarrer le serveur.

Ce que vous allez apprendre

• Lister tous les processus actifs avec ps aux et ps -eo
• Trouver un PID par nom avec pgrep et pidof
• Lire les codes STAT (R, S, D, Z, T) et comprendre ce qu'ils signalent
• Surveiller en temps réel avec top
• Ajuster la priorité au lancement (nice) et sur un processus existant (renice)
• Arrêter proprement : séquence SIGTERM → attente → SIGKILL
• Explorer /proc/$PID/status et lsof pour diagnostiquer

LFCS / RHCSA

Le référentiel RHCSA (EX200, sur RHEL 10) demande « Identify CPU/memory intensive processes and kill processes » et « Adjust process scheduling ». Le LFCS place dans son domaine Operations Deployment « Diagnose, identify, manage, and troubleshoot processes and services ». Aucun des deux ne dresse la liste des commandes : ps, top, kill, nice et renice sont les outils qui répondent à ces objectifs.

Dans quel contexte ?

Vous en avez besoin dès qu'un serveur se comporte anormalement :

• un processus utilise 100 % d'un CPU depuis plusieurs minutes,
• un service figure plusieurs fois dans ps aux (fuite de processus),
• une tâche est bloquée en état D (I/O wait) et ne répond plus,
• un zombie Z s'accumule sans disparaître,
• vous devez tuer proprement un service avant une maintenance.

Lister les processus avec ps

Afficher tous les processus

ps aux photographie tous les processus du système à un instant donné, ceux des autres utilisateurs compris. C'est le premier geste d'un diagnostic, avant de filtrer ou de trier.

ps aux

Colonnes clés :

Colonne	Signification
USER	Propriétaire
PID	Identifiant unique
%CPU	Pourcentage CPU utilisé
%MEM	Pourcentage mémoire
STAT	État (voir plus bas)
COMMAND	Commande lancée

Glissez pour voir

Choisir les colonnes avec ps -eo

ps -eo pid,ppid,user,ni,stat,comm --sort=-%cpu | head -n 11

--sort=-%cpu trie par consommation décroissante, le signe moins portant l'inversion. head -n 11 conserve la ligne d'en-tête plus les dix premiers processus : avec head -n 10 vous n'en obtiendriez que neuf, l'en-tête comptant pour une ligne. Le pourcentage affiché est une moyenne depuis le démarrage du processus (le manuel de ps parle d'un ratio « cputime/realtime »), pas une mesure instantanée. Mesuré sur un processus qui a calculé cinq secondes puis dort : ps affiche encore 55 %, top affiche 0,0 %. Pour l'instantané, top reste l'outil adapté.

Lire les états STAT

La colonne STAT est la première à regarder quand un processus « ne fait rien ». Elle combine une lettre majuscule donnant l'état du noyau, puis des caractères d'attribut optionnels. Deux valeurs demandent une réaction : D signale une attente d'entrée-sortie qu'aucun signal n'interrompt, et Z un processus déjà terminé que son parent n'a pas récupéré. Les autres sont le fonctionnement normal, S étant de loin le plus fréquent sur un serveur au repos.

Code	Signification
R	En cours d'exécution (running)
S	En attente (sleeping, réveillable)
D	Bloqué sur I/O (non interruptible)
Z	Zombie (terminé, parent n'a pas lu le code retour)
T	Stoppé (Ctrl+Z ou SIGSTOP)
s	Leader de session
+	Processus de premier plan (foreground)
l	Multi-thread
<	Haute priorité (valeur nice négative)
N	Basse priorité (valeur nice positive)

Glissez pour voir

État D persistant

Un processus bloqué en état D (I/O wait) ne peut pas être tué avec kill -9. Il faut diagnostiquer la cause racine : disque défaillant, NFS non répondant, locks kernel.

Trouver un processus par nom

pgrep cherche un motif dans le nom des processus, pas un nom exact : pgrep lee trouve un sleep (mesuré). Ajoutez -x pour exiger le nom complet, et -a pour afficher la ligne de commande. pidof, lui, attend le nom exact du programme.

# Par motif dans le nom (-x pour le nom exact)
pgrep nginx

# Plusieurs PIDs (plusieurs instances)
pidof bash

# Pattern dans ps avec filtre auto-excluant
ps aux | grep '[n]ginx'

L'astuce [n]ginx exclut la ligne du grep lui-même : le motif entre crochets correspond bien à la chaîne nginx, mais la ligne de commande de grep contient les crochets et ne correspond donc pas à son propre motif. Sans cette précaution, vous voyez toujours au moins un résultat, même quand le service est arrêté.

Visualiser l'arbre des processus

pstree dessine la hiérarchie parent-enfant des processus ; l'option -p ajoute les PID. Il appartient au paquet psmisc, présent dans l'image Debian 13 mesurée mais absent des images Ubuntu 24.04 et AlmaLinux 10 : installez ce paquet si la commande manque.

pstree -p

Utile pour comprendre les relations parent-enfant, identifier un processus orphelin, ou voir les threads d'un service.

Surveiller en temps réel avec top

Là où ps fige un instantané, top rafraîchit son affichage toutes les trois secondes par défaut (deux trames en 3,2 s, mesuré sur Debian 13). C'est la différence qui compte pour un diagnostic : la colonne %CPU de top mesure l'intervalle écoulé depuis le rafraîchissement précédent, elle reflète donc l'activité courante et non la moyenne de vie du processus. Mesuré avec procps-ng 4.0.4, c'est vrai dès la première trame : un processus endormi après cinq secondes de calcul y affiche 0,0 %, là où ps garde 55 %.

top

Touches interactives utiles :

Touche	Action
P	Trier par CPU
M	Trier par mémoire
k	Envoyer un signal à un processus
r	Changer la priorité (renice)
q	Quitter

Glissez pour voir

Astuce

htop offre une interface plus lisible que top avec filtrage et couleurs, mais n'est pas toujours disponible sur les systèmes minimaux. Voir htop pour plus de détails.

Priorité d'exécution : nice et renice

Chaque processus a une valeur nice de −20 (haute priorité) à +19 (basse priorité). La valeur par défaut est 0. Plus on monte, moins le processus est prioritaire.

Lancer un processus avec une priorité réduite

nice -n 15 tar czf archive.tar.gz /data

Pratique pour des tâches longues (sauvegardes, compilations) qui ne doivent pas perturber les autres services.

Attention

Seul root peut baisser la valeur nice, donc augmenter la priorité. Un utilisateur standard peut uniquement l'augmenter, et il ne peut pas revenir en arrière : mesuré sur les trois distributions, un compte ordinaire qui a passé son processus à 10 se voit refuser le retour à 5 (Permission denied).

Modifier la priorité d'un processus en cours

renice agit sur un processus déjà lancé, sans le redémarrer : c'est ce qui sauve une sauvegarde partie sans nice un jour de forte charge. Sa sortie donne l'ancienne et la nouvelle valeur (old priority 3, new priority 5), et un refus s'affiche clairement : renice: failed to set priority for 1234 (process ID): Permission denied, avec un code retour 1. Encadrez tout de même la commande de deux lectures de la colonne NI : c'est la preuve que la priorité a changé.

# Vérifier la valeur actuelle
ps -o pid,ni,comm -p 1234

# Changer la priorité
renice -n 10 -p 1234

# Vérifier après
ps -o pid,ni,comm -p 1234

Attention à un piège de syntaxe : avec la version util-linux présente sur Debian, Ubuntu et RHEL (2.39 à 2.41), -n fixe une valeur absolue. Elle ne s'ajoute pas à la valeur courante : mesuré, renice -n 5 sur un processus à 3 donne 5, et renice --relative 2 le fait ensuite passer à 7. Le comportement bascule aussi en relatif si la variable POSIXLY_CORRECT est présente dans l'environnement.

Envoyer des signaux à un processus

Signaux courants

Un signal est une notification envoyée à un processus par le noyau. La plupart peuvent être interceptés par le programme, qui décide alors quoi en faire : c'est exactement ce qui permet à nginx de recharger sa configuration sur SIGHUP sans couper les connexions en cours. Deux exceptions dans le tableau ci-dessous, SIGKILL et SIGSTOP, que le noyau applique sans laisser au programme la moindre chance de réagir. Retenez les noms plutôt que les numéros : kill -TERM fonctionne partout, alors que la numérotation varie selon l'architecture matérielle.

Numéro	Nom	Effet
1	SIGHUP	Rechargement de configuration
2	SIGINT	Interruption clavier (Ctrl+C)
15	SIGTERM	Demande d'arrêt propre (défaut)
9	SIGKILL	Arrêt forcé immédiat (non interceptable)
19	SIGSTOP	Pause (non interceptable)
18	SIGCONT	Reprise après pause

Glissez pour voir

Séquence recommandée pour arrêter un processus

# 1. Demande d'arrêt propre
kill -TERM 1234

# 2. Attendre quelques secondes, puis vérifier
sleep 3 && ps -p 1234

# 3. Forcer seulement si le processus ne répond toujours pas
kill -9 1234

kill -9 en dernier recours

SIGKILL ne laisse pas le processus nettoyer ses ressources (fichiers, verrous, connexions DB). Toujours préférer SIGTERM en premier.

Tuer par nom avec pkill et killall

Travailler par nom évite l'aller-retour par pgrep pour récupérer un PID, mais la contrepartie est réelle : la commande frappe tous les processus qui correspondent, y compris ceux des autres utilisateurs. Prenez le réflexe de lancer d'abord pgrep -a <nom> pour voir la liste exacte des cibles avant d'envoyer quoi que ce soit. Sans privilèges, chaque processus hors de votre portée produit pkill: killing pid … failed: Operation not permitted. Mesuré : le code retour reste 0 si au moins un processus a reçu le signal, il passe à 1 si tous ont été refusés.

# Voir d'abord ce qui va être touché, avec la ligne de commande complète
pgrep -a nginx

# Envoyer SIGTERM à tous les processus nommés "nginx"
pkill -TERM nginx

# Se limiter à ses propres processus
pkill -u "$USER" -TERM nginx

# Demander à nginx de relire sa configuration (PID du processus maître)
kill -HUP "$(cat /run/nginx.pid)"

# Tuer tous les processus d'un nom (killall)
killall -SIGTERM firefox

pkill cherche un motif dans le nom, killall exige par défaut le nom complet de la commande. Conséquence pratique : pkill ngin atteint nginx, killall ngin ne trouve rien. Les deux appartiennent à des paquets différents, procps pour pkill et psmisc pour killall, et killall n'est pas toujours installé : mesuré, il manque aux images Ubuntu 24.04 et AlmaLinux 10. Pour un service géré par systemd, préférez systemctl reload à un kill -HUP : systemd sait quel processus viser.

Explorer /proc pour diagnostiquer

Linux expose les informations de chaque processus dans /proc/<PID>/ :

# Fiche du processus courant
cat /proc/$$/status

# Extraire les champs utiles
grep -E "^(Name|Pid|PPid|State|VmRSS)" /proc/1234/status

Exemple de sortie :

Name:   nginx
State:  S (sleeping)
Pid:    1234
PPid:   1
VmRSS:  8560 kB

Lister les fichiers ouverts par un processus

lsof (list open files) liste les fichiers, sockets et bibliothèques qu'un processus tient ouverts. Il n'était installé dans aucune des trois images mesurées : le paquet s'appelle lsof partout. Sans lui, ls -l /proc/1234/fd donne déjà la liste des descripteurs ouverts.

lsof -p 1234

Ou pour trouver quel processus utilise un port, avec ss en alternative (paquet iproute2, installé sur tout serveur) :

lsof -i :80
sudo ss -tlnp 'sport = :80'

Dépannage

Les six situations ci-dessous couvrent la quasi-totalité des appels reçus sur ce sujet. Lisez-les dans le sens symptôme puis cause avant d'appliquer la solution : les deux premières lignes se ressemblent à l'écran mais n'ont rien à voir. Un processus que kill -9 n'atteint pas est un problème matériel ou de montage réseau, pas un problème de signal ; s'obstiner à renvoyer le signal ne changera rien.

Symptôme	Cause probable	Solution
kill -9 1234 ne tue pas le processus	État D (I/O bloqué, non interruptible)	Diagnostiquer le sous-système I/O (disque, NFS)
pkill nginx ne trouve rien	Nom de commande différent du binaire	Utiliser pgrep pour confirmer le nom exact
renice refusé avec Permission denied	Utilisateur non root qui baisse la valeur nice, même de 10 à 5	Utiliser sudo renice
pstree ou killall introuvable	Paquet psmisc absent	Installer psmisc
Zombie Z qui ne disparaît pas	Processus parent n'a pas appelé wait()	Identifier le parent avec ps -o ppid -p $ZOMBIE, tuer le parent si possible
top ne rafraîchit plus	Terminal gelé	q ou Ctrl+C, puis relancer

Glissez pour voir

À retenir

• ps aux liste tous les processus ; ps -eo choisit les colonnes.
• pgrep <motif> (ou pgrep -x <nom> pour le nom exact) et ps aux | grep '[n]om' trouvent un PID par nom.
• Les codes STAT (R, S, D, Z, T) indiquent l'état, D et Z méritent attention.
• nice -n N commande (priorité au lancement) ; renice -n N -p PID (après démarrage, valeur absolue).
• Toujours SIGTERM d'abord, attendre, puis SIGKILL seulement si nécessaire.
• /proc/$PID/status diagnostique sans aucun outil à installer ; lsof -p $PID complète, une fois le paquet lsof installé.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →