Observer les processus

Objectifs

À la fin de cette leçon, vous saurez :

• lister les processus de la machine et lire les colonnes de ps aux ;
• surveiller en continu avec top ;
• retrouver le PID d'un processus précis avec pgrep ;
• arrêter un processus proprement, comprendre pourquoi on commence toujours par là, et connaître la force de secours.

🔗 Pour vous rafraîchir la mémoire : du programme au processus · redirections et pipes

Créer nos cobayes

La théorie dit : un processus est une instance vivante d'un programme. Vérifions-le en créant des processus inoffensifs à observer :

$ sleep 300 &
[1] 4217

sleep 300 demande au système d'attendre 300 secondes sans rien faire — un processus parfait pour l'observation : vivant mais inactif. Le & final lance la commande en arrière-plan : elle tourne sans bloquer votre terminal.

Le shell répond deux informations : [1] est son numéro de tâche (utile seulement dans ce terminal) et 4217 est le PID — l'identifiant que le noyau vient d'attribuer à ce nouveau processus. Chaque processus lancé reçoit un numéro unique ; c'est lui qu'on utilise pour désigner précisément « cette exécution-là ».

Lancez-en un deuxième :

$ sleep 300 &
[2] 4231

Deux PIDs différents (ici 4217 et 4231), un seul programme sur disque : vous voyez vivre la distinction du cours précédent.

Lister : ps

$ ps
    PID TTY          TIME CMD
   4100 pts/0    00:00:00 bash
   4217 pts/0    00:00:00 sleep 300
   4231 pts/0    00:00:00 sleep 300

Sans option, ps montre uniquement les processus attachés à votre terminal : votre shell (bash), vos sleep. Déjà utile, mais limité.

Pour voir toute la machine, la forme classique :

ps aux

Sortie (tronquée) :

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.3  16736 10240 ?        Ss   09:00   0:02 /sbin/init
root       512  0.0  0.5  28672 15360 ?        Ss   09:00   0:00 /usr/sbin/cron
cours     1234  0.3  2.1 612345 45678 pts/0   Sl   09:14   0:05 node server.js
cours     4217  0.0  0.0   8320  1280 pts/0   S    10:01   0:00 sleep 300

Les colonnes qui comptent au quotidien :

Colonne	Sens	Pourquoi ça compte
USER	qui a lancé le processus	vos droits s'y appliquent : on ne tue pas les processus des autres
PID	identifiant unique du moment	la clé utilisée par kill, pgrep, etc.
%CPU	part du processeur consommée	repérer ce qui chauffe
%MEM	part de la RAM occupée	repérer ce qui gonfle
TIME	temps CPU réellement utilisé	distinguer « lancé depuis longtemps » et « travaille beaucoup »
COMMAND	commande complète de départ	identifier de quoi il s'agit

Détail instructif : la première ligne montre souvent PID 1, ancêtre de tous les processus du système — le premier créé au démarrage. Et notez que vos deux sleep apparaissent séparément : la liste est plate, un processus = une ligne.

Combinons avec le chapitre 1 pour chercher dedans :

ps aux | grep node

Attention au piège amusant : la sortie contient parfois une ligne grep node — c'est le processus grep lui-même, capturé par son propre filtre au moment où il démarre. Vous n'êtes pas fous : c'est normal.

Surveiller en continu : top

ps est une photo. top est la vidéo :

top

Écran rafraîchi toutes les trois secondes. Lecture des premières lignes :

top - 10:07:12 up  1:07,  1 user,  load average: 0.02, 0.05, 0.01
Tasks: 112 total,   1 running, 111 sleeping
%Cpu(s):  1.2 us,  0.4 sy, 98.4 id
MiB Mem :   3912.0 total,   2456.3 free,    812.4 used
    PID USER      PR  NI    VIRT    RES  %CPU  %MEM     TIME+ COMMAND
   1234 cours     20   0  612345  45678   0.7   2.1   0:05.11 node server.js
      1 root      20   0   16736  10240   0.0   0.3   0:02.03 /sbin/init

Ce qu'il faut savoir lire :

• load average : la file d'attente du CPU, moyennée sur 1, 5 et 15 minutes. Autour de 1,0 = un cœur constamment occupé ; bien plus haut que le nombre de cœurs = machine saturée ;
• %Cpu(s) : ici 98.4 id signifie 98,4 % idle — le processeur ne fait presque rien, machine tranquille ;
• MiB Mem : RAM totale/libre/utilisée ;
• la liste des processus, triée par défaut du plus gourmand en CPU au plus paisible.

Touches utiles dans top : Espace force un rafraîchissement, M trie par mémoire, P revient au tri CPU, q quitte.

Il existe aussi top -u cours pour ne suivre qu'un utilisateur. Et si votre VM propose htop (sinon sudo apt install htop), c'est le même concept en plus lisible — barres colorées, flèches pour naviguer, F9 pour arrêter un processus. Tout ce que vous apprenez ici se transpose directement.

Retrouver un PID : pgrep

Chercher à la main dans ps aux fonctionne, mais il y a mieux :

$ pgrep sleep
4217
4231

pgrep motif ne répond que les PID dont le nom correspond. Et pour voir les commandes complètes plutôt que les seuls numéros :

$ pgrep -a sleep
4217 sleep 300
4231 sleep 300

Arrêter un processus : kill, et pourquoi « proprement » d'abord

Un processus peut être invité à s'arrêter. Le mécanisme réel est élégant : kill n'« tue » rien directement — il envoie un signal, un message du noyau que le processus reçoit et traite.

Le signal poli (par défaut) :

kill 4217
pgrep sleep          # ne liste plus que 4231
[1]   Terminated     sleep 300

Le signal par défaut (SIGTERM) dit au processus : « merci de te terminer ». Le processus a alors la possibilité de ranger avant de partir : écrire ses données non sauvegardées, fermer proprement ses fichiers, couper ses connexions réseau. C'est crucial pour un vrai serveur : tuer brutalement un processus qui écrit en base peut corrompre des données.

Le signal brutal (en dernier recours) :

kill -9 4231

SIGKILL ne peut être ni intercepté ni ignoré : le noyau supprime le processus immédiatement, sans lui laisser la parole. Aucun nettoyage. On ne l'utilise que si le signal poli est resté sans effet (processus figé). Ordre professionnel systématique : kill d'abord, vérifier, kill -9 ensuite si vraiment nécessaire.

Par nom, quand on connaît le programme :

killall sleep

Envoie le signal poli à tous les processus correspondants. Pratique, à condition d'être sûr du nom : killall node toucherait tous les processus node de votre utilisateur, pas un seul.

Vérification finale, réflexe complet :

$ pgrep sleep
$

Réponse vide : plus aucun processus. Un arrêt, ça se vérifie.

Exercice

1. Lancez sleep 300 & trois fois. Notez les trois PIDs affichés.
2. Retrouvez ces PIDs avec pgrep, puis retrouvez la ligne complète du premier dans ps aux.
3. Arrêtez le second sleep par son PID avec kill. Vérifiez sa disparition.
4. Arrêtez les deux restants d'une seule commande.
5. Ouvrez top, notez la charge moyenne et la mémoire libre, puis trouvez le processus consommant le plus. Quittez avec q.
6. Question de réflexion : pourquoi kill envoie-t-il d'abord SIGTERM plutôt que SIGKILL directement ?

Résumé

• & lance en arrière-plan ; chaque processus reçoit un PID unique.
• ps photographie (votre terminal seul, ou ps aux toute la machine) ; top filme en continu (q pour sortir).
• pgrep [-a] nom trouve les PID ; la ligne grep dans ses propres résultats est normale.
• kill PID invite poliment (SIGTERM : nettoyage possible) ; kill -9 supprime sans discussion (SIGKILL, dernier recours) ; killall nom vise large.
• Toujours vérifier après l'arrêt : pgrep doit répondre vide.

$ sleep 300 &
[1] 4301
$ sleep 300 &
[2] 4302
$ sleep 300 &
[3] 4303
$ pgrep sleep
4301
4302
4303
$ ps aux | grep "sleep 300" | head -n 1
cours     4301  0.0  0.0   8320  1280 pts/0   S    10:15   0:00 sleep 300
$ kill 4302
$ pgrep sleep
4301
4303
$ killall sleep
$ pgrep sleep
$