Comment tuer un processus sous Linux : guide complet (kill, SysRq, OOM Killer)

Un processus qui consomme 100% du CPU, une application qui ne répond plus, un Linux complètement figé… Ces situations arrivent à tout le monde, y compris aux administrateurs système expérimentés. Savoir tuer un processus sous Linux est une compétence essentielle que tout utilisateur devrait maîtriser.

Dans ce guide complet, nous verrons tout ce qu’il faut savoir : identifier le processus responsable, le stopper proprement, réagir quand Linux est bloqué, comprendre l’OOM Killer, gérer les zombies à distance et surtout : prévenir ces problèmes.

1. Identifier un processus qui pose problème

Avant de tuer quoi que ce soit, il faut savoir quel processus est responsable du ralentissement ou du blocage. Linux offre plusieurs outils pour ça.

top : L’outil de base

top est installé par défaut sur pratiquement toutes les distributions Linux. Il affiche les processus en temps réel, triés par consommation CPU :

top

Les colonnes importantes :

htop : Version améliorée

htop est une version plus conviviale de top avec une interface colorée et interactive :

# Installation sur Debian/Ubuntu
sudo apt install htop

# Installation sur RHEL/Fedora
sudo dnf install htop

# Lancement
htop

ps : Requête ciblée

Pour chercher un processus spécifique, ps est plus adapté :

# Trouver tous les processus liés à Firefox
ps aux | grep firefox

# Afficher les 10 processus les plus gourmands en CPU
ps aux --sort=-%cpu | head -10

# Afficher les 10 processus les plus gourmands en mémoire
ps aux --sort=-%mem | head -10

gnome-system-monitor : Interface graphique

Si vous préférez une interface graphique (GNOME, KDE, XFCE), le moniteur système fait le travail :

# Installation
sudo apt install gnome-system-monitor

# Lancement (ou cherchez "Moniteur système" dans le menu)
gnome-system-monitor

Depuis l’interface, faites un clic droit sur un processus et choisissez « Tuer » ou « Arrêter ».

2. Tuer un processus : kill, kill -9, pkill, killall

Une fois le PID (Process ID) identifié, plusieurs commandes permettent de stopper un processus. Chacune a ses spécificités.

kill : Le signal SIGTERM

kill envoie un signal au processus. Par défaut, il envoie SIGTERM (signal 15), qui demande au processus de se terminer proprement :

# Terminer proprement le processus 1234
kill 1234

# Équivalent explicite
kill -15 1234

# Lui laisser 5 secondes, puis vérifier s'il est toujours là
kill 1234 && sleep 5 && ps -p 1234

Le processus a la possibilité de :

• Sauvegarder son état
• Fermer les fichiers ouverts
• Libérer les ressources
• Se terminer proprement

kill -9 (SIGKILL) : La force brute

# Tuer immédiatement le processus 1234
kill -9 1234

Tableau comparatif : Quand utiliser quoi

pkill et killall : Tuer par nom

# Tuer tous les processus Firefox
pkill -f firefox

# Tuer tous les processus python3
killall python3

# Tuer proprement (SIGTERM) tous les processus d'un utilisateur
pkill -u nom_utilisateur

# Vérifier ce qu'on va tuer avant (dry run)
pgrep -f firefox

sudo et permissions

Pour tuer un processus qui appartient à un autre utilisateur (ou un processus système), vous avez besoin des permissions appropriées :

# Tuer un processus système
sudo kill -9 1234

# Tuer tous les processus d'un autre utilisateur
sudo pkill -u nom_utilisateur

3. Linux figé / ne répond plus : que faire étape par étape

Quand Linux ne répond plus du tout : souris figée, clavier inactif, écran gelé : il faut procéder par ordre de sévérité :

Étape 1 : Essayer le terminal (Ctrl + Alt + F2/F3)

Les terminaux virtuels (TTY) fonctionnent souvent même quand l’interface graphique est bloquée :

# Basculer sur un terminal virtuel
Ctrl + Alt + F2

# Se connecter, puis identifier et tuer le processus
top
kill -9 PID_DU_PROCESSUS

# Revenir à l'interface graphique
Ctrl + Alt + F1  # ou F7 selon la configuration

Étape 2 : Tuer l’interface graphique

Si c’est le serveur d’affichage qui est bloqué :

# Avec Wayland (GNOME par défaut sur Ubuntu 22.04+)
sudo systemctl restart gdm3

# Avec X11
sudo systemctl restart gdm        # GNOME
sudo systemctl restart lightdm    # LightDM
sudo systemctl restart sddm       # KDE

# Alternative : tuer la session graphique
sudo pkill -9 Xorg
sudo pkill -9 wayland

Étape 3 : REISUB via SysRq (voir section suivante)

Étape 4 : Reset matériel (dernier recours)

4. SysRq REISUB : le dernier recours expliqué simplement

Magic SysRq est une combinaison de touches qui envoie des commandes directement au noyau Linux, même quand le système est complètement figé. C’est l’équivalent propre d’un force restart Linux.

Comment activer SysRq

# Vérifier si SysRq est actif
cat /proc/sys/kernel/sysrq

# L'activer (1 = toutes les commandes activées)
sudo sysctl -w kernel.sysrq=1

# Le rendre permanent
echo "kernel.sysrq = 1" | sudo tee -a /etc/sysctl.d/99-sysrq.conf

La séquence REISUB

Tapez ces touches lentement, une par une, en maintenant Alt + SysRq enfoncés :

Alternative sur certains claviers

Sur les claviers sans touche SysRq :

# Via SSH si vous avez un accès distant
echo b | sudo tee /proc/sysrq-trigger

# Séquence complète via SSH
for key in r e i s u b; do echo $key | sudo tee /proc/sysrq-trigger; sleep 1; done

5. OOM Killer : pourquoi Linux tue des processus tout seul

Vous avez peut-être vu ce message dans dmesg ou /var/log/syslog :

Out of memory: Killed process 12345 (java) total-vm:2048000kB

C’est l’OOM Killer (Out-Of-Memory Killer). Quand la mémoire vive est saturée et que le système ne peut plus allouer de RAM, le noyau Linux tue automatiquement le processus le plus « coûteux » pour éviter un crash complet.

Comment fonctionne l’OOM Killer

Chaque processus reçoit un score oom_score (de 0 à 1000). Plus le score est élevé, plus le processus est susceptible d’être tué :

# Voir le score OOM de tous les processus
sudo cat /proc/*/oom_score | sort -rn | head

# Voir le score d'un processus spécifique
cat /proc/1234/oom_score

# Protéger un processus critique (score à -1000, ne sera jamais tué)
echo -1000 | sudo tee /proc/1234/oom_score_adj

Surveiller la mémoire

# Mémoire disponible (version lisible)
free -h

# Détail de l'utilisation mémoire
vmstat 1 5

# Swappiness (tendance à utiliser le swap, 0-100)
cat /proc/sys/vm/swappiness

# Réduire le swappiness pour préférer garder les données en RAM
sudo sysctl -w vm.swappiness=10

6. SSH à distance : tuer un processus depuis une autre machine

Quand un serveur est inaccessible localement mais que le réseau fonctionne, SSH est votre meilleure option :

# Connexion au serveur distant
ssh utilisateur@192.168.1.100

# Identifier les processus gourmands
top -b -n 1 | head -20

# Tuer un processus distant
ssh utilisateur@192.168.1.100 "kill -9 1234"

# Tuer tous les processus d'une application distante
ssh utilisateur@192.168.1.100 "pkill -9 nginx"

# Vérifier l'état mémoire à distance
ssh utilisateur@192.168.1.100 "free -h && df -h"

Quand le serveur est très lent à répondre en SSH

# SSH avec timeout pour ne pas attendre indéfiniment
ssh -o ConnectTimeout=10 utilisateur@serveur

# Si la connexion est très lente (compression activée)
ssh -C utilisateur@serveur

# Exécuter une commande directement sans shell interactif
ssh -o ConnectTimeout=10 utilisateur@serveur "ps aux --sort=-%cpu | head -5"

7. Processus zombies : les identifier et les nettoyer

Un processus zombie (noté Z dans top) est un processus qui a terminé son exécution mais dont l’entrée dans la table des processus subsiste parce que le processus parent n’a pas lu son code de sortie.

Identifier les zombies

# Compter les processus zombies
ps aux | awk '{if ($8 ~ /Z/) print}' | wc -l

# Lister les zombies avec leur PID parent
ps aux | awk '{if ($8 ~ /Z/) print $2, $11}' 

# Afficher les zombies avec leur parent
ps -eo pid,ppid,stat,cmd | grep Z

Les tuer

On ne peut pas tuer un zombie directement avec kill -9 : il est déjà mort. La solution est de tuer le processus parent :

# 1. Trouver le PID parent (PPID) du zombie
ps -eo pid,ppid,stat,cmd | grep Z

# 2. Tuer le processus parent (remplacer PID_PARENT)
sudo kill -9 PID_PARENT

# 3. Le zombie est adopté par init/systemd et nettoyé automatiquement

# Alternative : envoyer SIGCHLD au parent pour qu'il nettoie ses enfants
sudo kill -s SIGCHLD PID_PARENT

8. Prévention : limites de ressources, cgroups et monitoring

Mieux vaut prévenir que guérir. Voici comment éviter que des processus ne bloquent votre système.

ulimit : Limiter les ressources par utilisateur

# Voir les limites actuelles
ulimit -a

# Limiter la mémoire par processus à 4 Go
ulimit -v 4194304

# Limiter le temps CPU à 300 secondes (5 min)
ulimit -t 300

# Limiter le nombre de processus par utilisateur
ulimit -u 500

# Appliquer de façon permanente (éditer limits.conf)
sudo nano /etc/security/limits.d/90-custom.conf
# Contenu :
# *    hard    rss     4194304
# *    hard    nproc   500

cgroups : Isoler et limiter des groupes de processus

# Créer un cgroup avec systemd-run (limite mémoire à 512 Mo)
sudo systemd-run --user --scope -p MemoryMax=512M commande

# Lancer un navigateur avec une limite de 2 Go
sudo systemd-run --user --scope -p MemoryMax=2G firefox

# Vérifier la consommation d'un cgroup
systemctl status systemd-run-XXXX.scope

# Lister les cgroups actifs
systemctl list-units --type=scope --state=running

Monitoring proactif

# Surveillance en temps réel avec watch
watch -n 2 "free -h && echo '---' && ps aux --sort=-%cpu | head -6"

# Alertes avec les notifications systemd
# Exemple : notifier quand la mémoire dépasse 90%
sudo apt install libnotify-bin
watch -n 10 "MEM=$(free | awk '/Mem/{printf(\"%.0f\", \$3/\$2*100)}'); [ \$MEM -gt 90 ] && notify-send 'Alerte mémoire' 'Utilisation: '\$MEM'%'"

# Vérifier les logs OOM
sudo dmesg | grep -i "out of memory"
sudo journalctl -k | grep -i "oom"

FAQ : Questions fréquentes

# Vérifier les logs noyau
sudo dmesg | grep -i "oom\|killed process"
sudo journalctl -k --since "1 hour ago" | grep -i oom