📍 Article principal du programme : Linux fondamentaux 2026 — commandes, services, dépannage
Ce tutoriel fait partie du programme « Linux fondamentaux ». Pour la vue d’ensemble, lisez d’abord le guide principal.

Introduction

Tout ce qui s’exécute sur un serveur Linux est un processus. Comprendre comment ils naissent, vivent, communiquent et meurent est l’un des plus grands gains de productivité d’un administrateur ou d’un développeur. Quand un VPS rame à 22 h, quand une API répond avec une latence de huit secondes, quand le journal annonce qu’« un processus a été tué », la cause se trouve toujours dans le comportement d’un processus précis. Ce tutoriel vous donne le vocabulaire et les outils pour observer, contraindre et terminer proprement n’importe quel processus, en huit étapes appliquées sur un Linux moderne (Ubuntu 24.04/26.04 LTS, Debian 13, AlmaLinux 9, Rocky Linux 9).

Prérequis

Un Linux et un compte avec accès sudo.
Connaissance de base de la ligne de commande.
Les bases de systemd recommandées mais pas obligatoires.
Niveau attendu : intermédiaire débutant.
Temps estimé : 80 minutes.

Étape 1 — Le vocabulaire de base

Chaque processus a un identifiant unique entier appelé PID (Process IDentifier), attribué par le noyau au moment de la création. Le PID 1 est spécial : c’est le premier processus lancé par le noyau et l’ancêtre de tous les autres. Sur un Linux moderne, c’est systemd qui occupe ce PID 1. Quand un processus en lance un autre (via fork() puis execve()), le second devient son enfant, et hérite par défaut de l’environnement, du répertoire courant, de l’utilisateur effectif et du groupe du parent.

Trois autres notions valent d’être connues immédiatement. L’utilisateur effectif (EUID) détermine quels droits le processus utilise pour accéder aux fichiers — ce n’est pas forcément l’utilisateur qui a lancé le processus, à cause du bit setuid. La hiérarchie cgroups, mécanique du noyau Linux qui regroupe les processus pour leur appliquer des limites de ressources, est au cœur de systemd et des conteneurs modernes. Les signaux sont les messages courts que le noyau envoie aux processus pour leur demander de se terminer, de se figer, ou de se relancer — sujet de l’étape 5.

Étape 2 — Lister les processus avec ps

La commande ps existe depuis les premières heures d’Unix et expose une centaine d’options. Trois invocations canoniques couvrent l’essentiel.

ps -ef                                # tous les processus, format complet
ps auxf                               # tous, avec %CPU/%MEM, en arborescence
ps -eo pid,user,%cpu,%mem,command --sort=-%mem | head -20    # top 20 par RAM

La sortie de ps -ef liste pour chaque processus son utilisateur, son PID, son PID parent (PPID), l’heure de démarrage et la commande complète. ps auxf trace l’arborescence parent-enfant avec une indentation visuelle, ce qui rend immédiatement lisible la généalogie des processus : par exemple nginx qui lance plusieurs nginx: worker, ou systemd qui orchestre les services. La construction ps -eo permet de personnaliser les colonnes affichées — utile pour les diagnostics ciblés. Mémorisez en particulier ps -eo pid,user,%cpu,%mem,command --sort=-%cpu qui pointe instantanément le processus le plus gourmand en CPU.

Étape 3 — Observer en temps réel avec top, htop, btop

Pour un suivi en direct, trois outils interactifs se partagent le marché. top est universellement disponible et minimaliste. htop apporte couleurs, défilement horizontal et vertical, et raccourcis clavier confortables — il s’installe avec sudo apt install htop ou sudo dnf install htop. btop, plus récent, offre des graphiques ASCII riches et fonctionne très bien sur les terminaux modernes ; sudo apt install btop.

top                                  # par défaut, trié par %CPU
top -o %MEM                          # trié par %MEM
htop                                 # version améliorée (préférée pour usage quotidien)
btop                                 # version graphique ASCII

Dans htop, quelques touches débloquent énormément de productivité : F2 ouvre les préférences, F3 filtre par nom, F4 recherche, F5 bascule en arborescence, F6 change la colonne de tri, F9 envoie un signal au processus sélectionné, F10 quitte. La ligne du haut affiche la charge moyenne sur 1, 5 et 15 minutes, l’occupation RAM et swap. Une charge supérieure au nombre de cœurs CPU pendant la période de 15 minutes indique une saturation durable, ce qui appelle un diagnostic plus poussé.

Étape 4 — Comprendre les états et les ressources

La colonne S (state) de ps ou top renseigne l’état dans lequel se trouve le processus à l’instant T. Cinq états méritent d’être connus : R (Running), en train d’utiliser le CPU ; S (Sleeping), en attente d’événement (le cas le plus fréquent en moyenne) ; D (Disk sleep), bloqué sur une opération disque ininterruptible ; Z (Zombie), terminé mais pas encore moissonné par son parent ; T (sTopped), suspendu par un signal SIGSTOP.

Les processus à l’état D sont l’un des indicateurs les plus parlants d’un problème de performance : si plusieurs processus stagnent en D, le disque ou le système de fichiers est en surcharge. iostat -xz 1 du paquet sysstat confirme avec les colonnes r/s et w/s (requêtes par seconde) et surtout %util (pourcentage de temps où le disque est occupé). Au-delà de 80 % d’utilisation soutenue, un disque devient un goulet. Les processus zombies sont rarement un problème en eux-mêmes — ils n’occupent qu’une entrée dans la table des processus — mais une accumulation peut révéler un parent qui ne fait pas wait() correctement.

Étape 5 — Envoyer des signaux avec kill

Sous Linux, on n’arrête pas un processus, on lui demande de s’arrêter. La demande prend la forme d’un signal, un message court identifié par un numéro et un nom symbolique. La commande kill envoie un signal à un PID donné.

kill PID                             # SIGTERM par défaut, demande poliment
kill -9 PID                          # SIGKILL, coupe net (le noyau, pas le processus)
kill -SIGHUP PID                     # SIGHUP, demande au démon de relire sa config
kill -l                              # liste les signaux supportés
pkill nom                            # cherche par nom et envoie SIGTERM
pkill -9 -f "node.*server.js"        # cherche par ligne de commande complète
killall -SIGTERM nginx               # tue tous les processus du nom donné

La règle d’or de la terminaison propre : commencer par SIGTERM, attendre quelques secondes, escalader vers SIGKILL uniquement si nécessaire. SIGTERM (numéro 15) demande poliment au processus de se terminer ; le code applicatif a la possibilité de fermer ses fichiers, vider ses tampons, prévenir ses clients. SIGKILL (numéro 9) est traité directement par le noyau sans que le processus ait son mot à dire — c’est l’équivalent d’arracher la prise. Si vous tuez systématiquement avec -9, vous corrompez tôt ou tard une base SQLite, un fichier en cours d’écriture, ou un état applicatif. SIGHUP (numéro 1) sert traditionnellement à demander à un démon long-running (Nginx, sshd, postfix) de relire sa configuration sans redémarrer.

Étape 6 — Le OOM Killer et les limites mémoire

Quand la mémoire libre du système approche zéro et que le swap ne suffit plus, le noyau Linux active son OOM Killer (Out-Of-Memory Killer), un mécanisme qui choisit un processus et le tue brutalement (équivalent SIGKILL) pour libérer la RAM et préserver le système. Cet événement est fréquent sur les VPS modestes mal dimensionnés, et il est particulièrement perturbant parce qu’il survient sans préavis applicatif.

# Voir si l'OOM Killer a frappé récemment
journalctl -k -b | grep -i "out of memory\|killed process"
dmesg | grep -i "Killed process"

# Voir le score OOM d'un processus (plus haut = plus susceptible d'être tué)
cat /proc/PID/oom_score
cat /proc/PID/oom_score_adj         # ajustement, entre -1000 (immunisé) et +1000

# Limiter explicitement un service via systemd
sudo systemctl edit mon-app
# [Service]
# MemoryMax=512M
# MemoryHigh=400M

Le oom_score est calculé par le noyau à partir de la consommation mémoire et de quelques heuristiques. Un processus que vous voulez protéger (par exemple votre démon SSH pour ne pas perdre l’accès au serveur) peut recevoir oom_score_adj=-1000, ce qui le rend immunisé. À l’inverse, un service de cache facilement redémarrable peut recevoir +500 pour devenir cible préférentielle. Ces ajustements vivent dans les fichiers d’unité systemd via OOMScoreAdjust=-100. La meilleure défense reste évidemment de dimensionner correctement les limites MemoryMax sur les services applicatifs pour éviter que la fuite d’un seul processus n’entraîne tout le système.

Étape 7 — La méthode USE pour diagnostiquer

Brendan Gregg, ingénieur de performance célèbre pour son travail chez Netflix puis Intel, a popularisé dès 2012 la USE method (Utilization, Saturation, Errors) — un cadre de diagnostic toujours pertinent en 2026 pour caractériser une saturation de ressource. Pour chaque ressource (CPU, mémoire, disque, réseau), on mesure trois choses : son taux d’utilisation, sa saturation (file d’attente), et le nombre d’erreurs.

# CPU
uptime                               # charge moyenne 1/5/15 min
mpstat -P ALL 1                      # par cœur (paquet sysstat)
vmstat 1                             # colonnes r (run queue), us, sy, id, wa

# Mémoire
free -h                              # libre/utilisée/cache
vmstat 1                             # colonnes si/so (swap in/out, doit rester à 0)

# Disque
iostat -xz 1                         # %util, await, rrqm/s, wrqm/s
df -h                                # remplissage des partitions
df -i                                # inodes (saturation invisible sinon)

# Réseau
ss -s                                # statistiques sockets
ip -s link show eth0                 # paquets, erreurs, drops

L’enchaînement diagnostic suit la même logique que pour le réseau : on mesure d’abord utilisation, puis saturation, puis erreurs, et on remonte à la cause. Une charge à 8 sur un serveur 4 cœurs avec %iowait à 70 % dans vmstat et %util à 100 % dans iostat raconte une histoire claire : le système attend le disque. Le coupable est probablement un processus en état D — visible dans top. Cette discipline est plus fiable que les tableaux de bord de monitoring qui agrègent et masquent les pics.

Étape 8 — Vérification et bonnes habitudes

Pour valider votre maîtrise, lancez la séquence suivante sur un serveur de test. Elle reproduit ce que tape un administrateur expérimenté à l’arrivée sur une machine inconnue qui se comporte mal.

# 1. Vue panoramique
uptime
free -h
df -h /

# 2. Top consommateurs
ps -eo pid,user,%cpu,%mem,command --sort=-%cpu | head -10
ps -eo pid,user,%cpu,%mem,command --sort=-%mem | head -10

# 3. Saturation disque ?
vmstat 1 5
iostat -xz 1 5

# 4. États suspects (D, Z)
ps -eo pid,user,stat,command | awk '$3 ~ /^[DZ]/'

# 5. OOM récents
journalctl -k -b | grep -iE "oom|killed process" | tail -10

echo "✓ diagnostic terminé"

Sur un serveur sain, vous voyez une charge alignée sur le nombre de cœurs ou inférieure, une RAM utilisée mais avec du cache, un disque en dessous de 80 %, aucun processus en D persistant, aucun zombie en accumulation, aucune trace d’OOM récent. Toute déviation par rapport à cette norme est une piste à creuser. L’habitude de courir cette routine en moins de soixante secondes à chaque connexion sur un serveur en panne est ce qui distingue un dépannage en quelques minutes d’une recherche aveugle de plusieurs heures.

Erreurs fréquentes

Erreur	Cause	Solution
« No such process » sur un kill	PID inexistant ou déjà terminé	Re-lister avec `ps aux \| grep`, vérifier le PID
kill SIGTERM sans effet	Le processus ignore le signal ou est en état D ininterruptible	Diagnostiquer avec `strace -p PID`, n’utiliser SIGKILL qu’en dernier recours
Zombie persistant	Le parent ne fait pas `wait()`	Tuer le parent ; le PID 1 adoptera et nettoiera
Charge élevée sans CPU saturé	Processus en D bloqués sur disque	`iostat -xz 1`, identifier le disque saturé
OOM Killer répétitif	Fuite mémoire applicative ou limite trop basse	Ajouter `MemoryMax` systemd, profiler l’appli
`htop` n’est pas installé	Paquet absent	`sudo apt install htop` ou `sudo dnf install htop`

Tutoriels associés

Lectures complémentaires

🔝 Retour au guide principal : Linux fondamentaux 2026
Pages de manuel : man ps, man top, man kill, man signal(7), man proc(5).
Brendan Gregg — méthode USE : brendangregg.com/usemethod.html
Systems Performance, Brendan Gregg, 2e édition 2020 — référence sur l’observation et l’optimisation Linux.
Documentation cgroups v2 : kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

FAQ

Quelle différence entre kill et killall et pkill ?
kill PID envoie un signal à un PID précis. killall nom envoie un signal à tous les processus dont la commande est exactement nom. pkill est plus puissant : il accepte des expressions, peut filtrer par utilisateur, par parent, par durée d’exécution, et son option -f matche la ligne de commande complète au lieu du nom seul. Pour un usage quotidien, pkill -f motif est le plus polyvalent.

Comment lancer un processus en arrière-plan qui survit à la déconnexion ?
Trois options. nohup commande & détache le processus du terminal et redirige sa sortie dans nohup.out ; il survit à la fermeture de la session SSH. tmux ou screen ouvrent une session persistante que vous pouvez quitter et retrouver intacte plus tard. Pour un service durable, écrivez plutôt un fichier d’unité systemd — c’est la solution propre, qui survit aux reboots et bénéficie de la journalisation, du redémarrage automatique et du sandboxing.

Comment savoir quels fichiers un processus a ouverts ?
lsof -p PID liste les descripteurs de fichiers ouverts par un processus : fichiers réguliers, sockets, tubes, terminaux. Cette commande révèle souvent ce qu’un processus est réellement en train de faire — par exemple, un Nginx qui détient un fichier de log supprimé l’empêche d’être réellement libéré sur le disque (cas classique « du dit X, df dit Y »). Pour les sockets précisément, ss -tnp | grep PID est plus rapide.

Comment limiter le CPU d’un processus sans systemd ?
L’outil nice ajuste la priorité d’un processus (de -20, le plus prioritaire, à +19, le moins) — utile pour empêcher un script lourd de gêner le reste. cpulimit du paquet du même nom plafonne explicitement le pourcentage CPU consommé, par exemple cpulimit -l 50 -p PID limite à 50 %. chrt manipule la classe de scheduling pour le temps réel mou. Mais en 2026, sur Linux moderne, la voie propre passe par cgroups v2 et systemd, qui offrent des limites plus fines et persistantes.

Comment voir l’historique d’utilisation CPU d’un processus dans le temps ?
top et htop sont instantanés. Pour un suivi historique, le paquet sysstat avec son démon sadc collecte les statistiques toutes les dix minutes par défaut, et sar les replay : sar -u -s 09:00:00 -e 11:00:00 affiche l’usage CPU global entre 9 h et 11 h. Pour un suivi par processus, pidstat 1 rafraîchit chaque seconde et écrit les valeurs par PID.

Mon processus consomme 100 % CPU, comment savoir où il est bloqué ?
Quatre outils, par ordre d’invasivité croissante. strace -p PID -c pendant dix secondes affiche un résumé des appels système ; un processus qui tourne dans une boucle de read() infructueux saute aux yeux. perf top -p PID profile en temps réel les fonctions consommatrices de CPU. py-spy (Python) ou node --prof (Node) profilent au niveau langage. Enfin, un flamegraph généré par perf record + FlameGraph de Brendan Gregg donne la visualisation ultime, à condition d’avoir les symboles de débogage.

Processus Linux : ps, top, htop, kill, signaux — tutoriel pas-à-pas