Linux plante ou se bloque : diagnostiquer les causes et trouver l’origine

Un PC ou un serveur Linux qui plante, se bloque, ralentit fortement ou redémarre de manière inattendue peut avoir de nombreuses causes. Le problème peut provenir d’un processus qui monopolise le CPU ou la mémoire RAM, d’un manque de mémoire et de l’OOM Killer, d’un service en échec, d’un disque saturé, d’une erreur du système de fichiers, d’un Kernel Panic ou encore d’une défaillance matérielle.

Linux fournit heureusement de nombreux outils permettant de retrouver l’origine d’un plantage. Les commandes dmesg et journalctl permettent d’examiner les événements du noyau et du système, tandis que top, free, systemctl, coredumpctl ou encore les journaux du démarrage précédent permettent d’identifier une surcharge, un crash d’application ou un redémarrage anormal.

Dans ce guide, découvrez une méthode complète pour diagnostiquer un plantage ou un blocage sous Linux, analyser les journaux, vérifier les ressources du système et déterminer si le problème est logiciel, matériel, lié au stockage, à la mémoire ou au réseau.

Le guide connexe : Diagnostiquer le matériel sous Linux en ligne de commandes

Identifier le type de plantage

Avant de lancer des commandes de diagnostic, commencez par déterminer ce qui s’est réellement produit sur votre système Linux. Un ordinateur complètement figé, un serveur inaccessible en SSH ou une application qui ne répond plus peuvent donner l’impression que Linux a planté alors que les causes sont très différentes.

Par exemple, un serveur peut continuer à fonctionner normalement alors qu’un problème réseau empêche simplement d’y accéder. À l’inverse, un manque de mémoire peut provoquer l’arrêt brutal de certains processus sans entraîner le plantage complet du système.

Le tableau suivant permet d’orienter les premières recherches.

Symptôme	Causes possibles	Vérifications prioritaires
Linux est complètement figé	Kernel Panic, pilote défectueux, problème RAM, GPU ou matériel	`journalctl`, `dmesg`, Kernel Panic, RAM
Le PC ou serveur redémarre brutalement	Kernel Panic, watchdog, surchauffe, alimentation ou panne matérielle	`last -x`, `journalctl -b -1`, températures
Le serveur devient inaccessible en SSH	Réseau, pare-feu, service SSH arrêté, surcharge CPU/RAM ou système réellement bloqué	Ping, SSH, `systemctl`, `top`, journaux
Linux devient extrêmement lent	CPU saturé, manque de RAM, swap intensif, disque lent ou processus bloqués en I/O	`top`, `free -h`, `vmstat`, `iostat`
Une application ou un service s’arrête	Crash, Segmentation Fault, OOM Killer, erreur de configuration	`systemctl status`, `journalctl -u`, `coredumpctl`
Un processus disparaît sans raison apparente	OOM Killer, crash ou arrêt par un autre processus	`journalctl`, recherche de `Killed process` et `Out of memory`
Des erreurs de lecture/écriture apparaissent	Disque défectueux, SSD/NVMe en panne, système de fichiers endommagé	`dmesg`, `journalctl`, `smartctl`
Le système passe en lecture seule	Erreurs du système de fichiers ou du périphérique de stockage	`dmesg`, erreurs EXT4/XFS/Btrfs, SMART
L’interface graphique se fige ou affiche un écran noir	Pilote graphique, GPU, serveur d’affichage ou environnement de bureau	`journalctl`, `dmesg`, journaux graphiques
Le système se bloque sous forte charge	RAM insuffisante, OOM, surchauffe, alimentation ou problème matériel	`free -h`, `top`, `sensors`, journaux kernel

Il est également important de noter le contexte dans lequel le problème apparaît : pendant une sauvegarde, lors d’une forte charge PHP/MySQL, durant une copie importante de fichiers, après une mise à jour du noyau, au démarrage ou de manière totalement aléatoire. Ces informations permettent souvent de réduire considérablement le champ des recherches.

Après un redémarrage consécutif à un plantage, évitez de vous limiter aux journaux du démarrage actuel. Les informations les plus intéressantes se trouvent souvent dans les journaux du démarrage précédent. Nous verrons notamment comment utiliser journalctl -b -1 pour retrouver les événements qui ont précédé le crash.

La première étape consiste toutefois à vérifier si Linux a réellement redémarré et à déterminer depuis combien de temps le système fonctionne.

Vérifier les journaux du noyau avec dmesg

La commande dmesg permet de consulter les messages générés par le noyau Linux depuis le démarrage du système. Elle est particulièrement utile lorsqu’un PC ou un serveur Linux se bloque, devient instable ou rencontre un problème matériel.

Les messages du noyau peuvent notamment révéler des erreurs de disque, des problèmes de système de fichiers, un manque de mémoire, une surchauffe, un pilote défaillant ou encore une erreur matérielle.

Pour afficher les messages du noyau, ouvrez un terminal puis exécutez :

sudo dmesg

La quantité d’informations peut être importante. Pour afficher uniquement les erreurs et avertissements :

sudo dmesg --level=err,warn

Vous pouvez également utiliser l’option -T afin d’obtenir des dates et heures plus faciles à lire :

sudo dmesg -T

Pour rechercher rapidement les messages susceptibles d’indiquer un problème :

sudo dmesg -T | grep -i -E "error|fail|critical|warning"

Le guide complet :

Comment utiliser la commande dmesg sur Linux

Rechercher les erreurs de disque et de système de fichiers

Un problème de disque dur, de SSD ou de système de fichiers peut provoquer des ralentissements importants, des blocages et parfois un plantage complet de Linux.

Pour rechercher ce type d’erreur :

sudo dmesg -T | grep -i -E "i/o error|buffer i/o|nvme|ata|sata|ext4|xfs|btrfs"

Portez notamment attention aux messages contenant I/O error, Buffer I/O error, EXT4-fs error, XFS ou des erreurs associées à un périphérique NVMe/SATA.

Rechercher un manque de mémoire

Lorsque Linux manque de mémoire RAM et de swap, le noyau peut déclencher l’OOM Killer (Out Of Memory Killer) afin de terminer un ou plusieurs processus et récupérer de la mémoire.

Pour rechercher ces événements :

sudo dmesg -T | grep -i -E "oom|out of memory|killed process"

Un message contenant par exemple Out of memory suivi de Killed process indique qu’un processus a probablement été arrêté à cause d’un manque de mémoire.

Nous verrons plus loin comment diagnostiquer précisément les problèmes de RAM, swap et OOM Killer.

Rechercher les erreurs matérielles et les surchauffes

Vous pouvez également rechercher les messages susceptibles d’indiquer une défaillance matérielle :

sudo dmesg -T | grep -i -E "hardware error|mce|edac|thermal|throttling"

Des messages contenant Hardware Error, Machine Check Exception (MCE) ou EDAC peuvent signaler une erreur détectée au niveau du processeur, de la mémoire ou d’un autre composant matériel.

Les mentions thermal ou throttling peuvent quant à elles indiquer un problème de température ou une réduction automatique des performances pour protéger le matériel.

Voici quelques messages importants que vous pouvez rencontrer :

Message	Cause possible
I/O error	Erreur de disque, SSD, contrôleur ou connexion au périphérique
Buffer I/O error	Échec d’une opération de lecture ou d’écriture
EXT4-fs error / XFS / Btrfs error	Problème du système de fichiers
Out of memory	Mémoire disponible insuffisante
Killed process	Processus terminé, notamment par l’OOM Killer
segfault	Plantage d’un processus avec erreur de segmentation
Hardware Error / MCE	Erreur matérielle détectée
EDAC	Erreur liée notamment à la mémoire avec prise en charge EDAC
thermal / throttling	Température élevée ou limitation thermique
NVRM / amdgpu / i915	Message pouvant concerner le GPU ou son pilote
watchdog	Blocage ou absence de réponse détectée

Un message contenant error ou warning ne signifie toutefois pas systématiquement qu’il est responsable du plantage. Il faut surtout rechercher les événements apparus juste avant le problème et les erreurs qui se répètent.

Enfin, dmesg concerne essentiellement les messages du noyau du démarrage en cours. Si Linux a complètement planté puis redémarré, les informations qui ont précédé le crash peuvent ne plus être présentes dans le buffer actuel. Dans ce cas, il faut examiner les journaux persistants du démarrage précédent avec journalctl, notamment avec journalctl -b -1 et journalctl -k -b -1.

Le tutoriel :

dmesg : afficher les messages du noyau Linux

Vérifier les derniers redémarrages et arrêts

Lorsqu’un serveur ou un PC Linux semble avoir planté, il est utile de déterminer s’il a réellement redémarré et si ce redémarrage a été précédé d’un arrêt normal. Un redémarrage brutal peut notamment être provoqué par un Kernel Panic, un watchdog, une coupure d’alimentation, une surchauffe ou un problème matériel.

La commande last permet de consulter l’historique des connexions, mais également des démarrages et arrêts du système grâce à l’option -x.

Exécutez :

last -x

Vous obtenez des lignes contenant notamment :

reboot   system boot  6.8.0-63-generic   Thu Aug  7 08:42   still running
shutdown system down  6.8.0-63-generic   Wed Aug  6 23:15 - 23:16

Vérifier les derniers redémarrages et arrêts de son PC en Linux

Les entrées importantes sont :

Entrée	Signification
reboot	Démarrage du système
shutdown	Arrêt normal de Linux
runlevel	Changement de niveau d’exécution ou de cible systemd
crash	Une session s’est terminée sans arrêt propre enregistré
still running	Le système ou la session concernée est toujours actif

Pour afficher uniquement les redémarrages :

last reboot

Vous pouvez également afficher uniquement les arrêts :

last -x shutdown

Repérer un redémarrage brutal

Ce qui nous intéresse particulièrement lors d’un diagnostic est la succession des événements.

Lors d’un arrêt normal, vous devez généralement retrouver une entrée shutdown avant le démarrage suivant :

shutdown system down ...
reboot   system boot ...

En revanche, si vous observez un nouveau reboot sans événement shutdown correspondant juste avant, le système peut avoir subi un redémarrage non propre.

Cela peut se produire après :

Une coupure électrique ou un problème d’alimentation.
Un appui prolongé sur le bouton Marche/Arrêt.
Un reset matériel.
Un Kernel Panic suivi d’un redémarrage automatique.
Le déclenchement d’un watchdog.
Une défaillance matérielle.

La commande last permet donc de confirmer qu’un redémarrage anormal a eu lieu, mais elle n’en indique généralement pas la cause.

Une fois le redémarrage suspect identifié, notez sa date et son heure puis examinez les événements qui l’ont précédé dans le journal du démarrage précédent :

journalctl -b -1

Pour vous concentrer uniquement sur les messages du noyau :

journalctl -k -b -1

C’est souvent dans les dernières secondes ou minutes précédant le redémarrage que vous trouverez les informations les plus utiles : erreur disque, OOM Killer, Kernel Panic, problème matériel, watchdog ou autre anomalie.

Vérifier les journaux de démarrage de Linux

Examiner les journaux avec journalctl

La commande journalctl permet de consulter les journaux enregistrés par systemd-journald. Lorsqu’un PC ou un serveur Linux plante, redémarre brutalement ou devient instable, c’est l’un des premiers outils à utiliser pour rechercher les événements qui ont précédé le problème.

Contrairement à dmesg, qui permet surtout de consulter les messages du noyau du démarrage actuel, journalctl peut conserver les journaux des démarrages précédents, à condition que la journalisation persistante soit activée.

Pour afficher les événements du démarrage actuel :

sudo journalctl -b

Pour afficher uniquement les erreurs :

sudo journalctl -b -p err

Examiner le démarrage précédent après un plantage

Si Linux a planté puis redémarré, le plus intéressant est généralement d’examiner le démarrage précédent :

sudo journalctl -b -1

Commencez par regarder les dernières lignes du journal, car elles correspondent aux événements enregistrés juste avant l’arrêt ou le plantage :

sudo journalctl -b -1 -e

Pour limiter l’affichage aux erreurs du démarrage précédent :

sudo journalctl -b -1 -p err

Vous pouvez également afficher uniquement les messages du noyau Linux :

sudo journalctl -k -b -1

Cette dernière commande est particulièrement utile pour rechercher une erreur matérielle, un Kernel Panic, un problème de stockage, une erreur de pilote ou un manque de mémoire ayant précédé le plantage.

Rechercher les événements autour de l’heure du plantage

Si vous connaissez approximativement l’heure à laquelle le problème s’est produit, utilisez les options --since et --until afin de réduire considérablement le nombre de messages à analyser.

Par exemple :

sudo journalctl --since "2026-08-07 02:00:00" --until "2026-08-07 02:30:00"

Vous pouvez ainsi examiner uniquement les événements enregistrés dans les minutes précédant le crash.

Portez particulièrement attention aux messages contenant des termes tels que :

Out of memory, OOM ou Killed process : manque de mémoire et intervention de l’OOM Killer.
I/O error : problème d’entrée/sortie, souvent lié au stockage.
EXT4-fs error, XFS ou Btrfs : erreur du système de fichiers.
segfault : plantage d’un processus.
kernel panic : erreur fatale du noyau.
watchdog : système ou composant devenu non réactif.
thermal ou throttling : problème de température.
Hardware Error, MCE ou EDAC : erreur matérielle.

Enfin, ne vous focalisez pas uniquement sur la dernière erreur affichée. Un message d’erreur peut être la conséquence du plantage et non sa cause. Examinez plutôt la chronologie des événements dans les secondes ou minutes précédant le problème.

Les guides à consulter :

Rechercher un Kernel Panic

Un Kernel Panic correspond à une erreur critique du noyau Linux dont celui-ci ne peut pas se remettre normalement. Selon la configuration du système, Linux peut alors se figer complètement, afficher un message d’erreur à l’écran ou redémarrer automatiquement après quelques secondes.

Les Kernel Panic peuvent avoir de nombreuses origines : pilote défectueux, module du noyau, problème de RAM, erreur CPU, système de fichiers endommagé, périphérique de stockage défaillant ou bug du noyau.

Après un redémarrage consécutif à un plantage, commencez par examiner les messages du noyau du démarrage précédent :

sudo journalctl -k -b -1

Pour rechercher directement les occurrences de Kernel Panic :

sudo journalctl -k -b -1 | grep -i -E "kernel panic|panic|oops"

Il est également intéressant de rechercher les erreurs généralement associées à un plantage du noyau :

sudo journalctl -k -b -1 | grep -i -E "panic|oops|bug:|call trace|fatal|mce|hardware error"

Portez notamment attention aux messages suivants :

Message	Signification possible
Kernel panic – not syncing	Le noyau a rencontré une erreur fatale et ne peut plus continuer son exécution.
Oops	Erreur grave du noyau qui n’entraîne pas nécessairement immédiatement un Kernel Panic.
BUG:	Détection d’un comportement anormal dans le noyau ou un module.
Call Trace	Pile d’appels permettant d’identifier les fonctions et modules impliqués dans le crash.
Unable to mount root fs	Le noyau ne parvient pas à monter le système de fichiers racine.
Machine Check Exception (MCE)	Le processeur a détecté une erreur matérielle.
Hardware Error	Erreur matérielle remontée au noyau.

Identifier le module ou le pilote impliqué

Lorsqu’un Kernel Panic affiche une Call Trace, recherchez les noms de modules présents juste avant ou dans la trace. Ils peuvent permettre d’identifier un pilote responsable du plantage.

Par exemple, des références répétées à des modules tels que nvidia, amdgpu, i915, un pilote réseau ou un module tiers peuvent orienter le diagnostic.

Vérifiez également si le problème est apparu après :

Une mise à jour du noyau Linux.
L’installation ou la mise à jour d’un pilote graphique.
L’ajout d’un module DKMS.
Une mise à jour importante du système.
L’installation d’un nouveau matériel.

Si le problème a commencé après une mise à jour du noyau, vous pouvez temporairement démarrer sur un noyau précédent depuis GRUB afin de vérifier si le plantage disparaît.

Que faire si aucun Kernel Panic n’est enregistré ?

Un Kernel Panic ne peut pas toujours être écrit dans les journaux. Si le noyau ou le stockage devient inutilisable immédiatement, le système peut planter avant que les dernières informations soient enregistrées sur le disque.

Ainsi, l’absence de kernel panic dans journalctl ne permet pas d’exclure totalement cette cause.

Si le système redémarre brutalement sans laisser de trace exploitable, poursuivez le diagnostic en recherchant notamment un problème de RAM, une surchauffe, une défaillance du stockage ou une erreur matérielle. Il faudra également vérifier si le redémarrage a été déclenché par un watchdog ou une panne d’alimentation.

Vérifier un manque de mémoire et l’OOM Killer

Un manque de mémoire RAM peut provoquer d’importants ralentissements, rendre un serveur presque inaccessible ou entraîner l’arrêt brutal de certains processus. Sous Linux, lorsque la mémoire disponible devient insuffisante et que le système ne peut plus satisfaire les demandes d’allocation, le noyau peut déclencher l’OOM Killer (Out Of Memory Killer).

Son rôle est de sélectionner et de terminer un ou plusieurs processus afin de libérer rapidement de la mémoire et d’éviter, lorsque cela est possible, le blocage complet du système.

Sur un serveur Web, par exemple, l’OOM Killer peut arrêter un processus PHP-FPM, MySQL/MariaDB, Java ou tout autre service consommant beaucoup de mémoire.

Vérifier l’utilisation de la RAM et du swap

Commencez par afficher l’état de la mémoire :

free -h

Vous obtenez un résultat similaire à celui-ci :

               total        used        free      shared  buff/cache   available
Mem:            15Gi        11Gi       520Mi       650Mi        3.5Gi        3.1Gi
Swap:          4.0Gi       2.8Gi       1.2Gi

Ne vous fiez pas uniquement à la colonne free. Linux utilise volontairement la mémoire inutilisée comme cache. La colonne available est généralement plus pertinente pour estimer la quantité de mémoire encore disponible pour les applications.

Portez notamment attention aux situations suivantes :

available devient très faible.
Le swap est fortement utilisé.
L’utilisation du swap augmente rapidement.
Le système devient lent alors que la RAM est presque entièrement utilisée.

Pour surveiller l’évolution de la mémoire en temps réel, utilisez également :

vmstat 2

Les colonnes si (swap in) et so (swap out) permettent de détecter une activité importante du swap. Des valeurs élevées et persistantes peuvent indiquer une pression mémoire importante.

Rechercher le déclenchement de l’OOM Killer

Après un plantage ou l’arrêt inexpliqué d’un service, recherchez les événements liés à un manque de mémoire :

sudo journalctl -k | grep -i -E "oom|out of memory|killed process"

Si le problème s’est produit avant le dernier redémarrage, examinez plutôt les messages du noyau du démarrage précédent :

sudo journalctl -k -b -1 | grep -i -E "oom|out of memory|killed process"

Vous pouvez également rechercher ces messages avec dmesg pour le démarrage actuel :

sudo dmesg -T | grep -i -E "oom|out of memory|killed process"

Un événement caractéristique ressemble à ceci :

Out of memory: Killed process 18452 (php-fpm) total-vm:...

ou :

oom-kill:constraint=CONSTRAINT_NONE...
Killed process 18452 (php-fpm)...

Dans cet exemple, le noyau a décidé de terminer un processus PHP-FPM afin de récupérer de la mémoire. Si vous retrouvez ce type de message juste avant qu’un site Web, une base de données ou un autre service devienne indisponible, l’OOM Killer est probablement directement impliqué.

Identifier les processus qui consomment le plus de mémoire

Pour afficher les processus classés par consommation de RAM :

ps aux --sort=-%mem | head -20

Vous pouvez également utiliser :

top

puis trier les processus par mémoire avec la touche M.

Cela permet d’identifier rapidement un processus dont la consommation augmente anormalement, par exemple php-fpm, mysqld, java, un serveur applicatif ou un script mal configuré.

Il faut toutefois rechercher la cause de la consommation excessive plutôt que simplement arrêter le processus concerné. Un OOM peut être provoqué par une fuite mémoire, trop de workers PHP-FPM, une base de données mal dimensionnée, une application trop gourmande, une absence de swap ou simplement une quantité de RAM insuffisante.

Si l’OOM Killer apparaît régulièrement dans les journaux, surveillez ensuite plus précisément les processus qui consomment le CPU et la mémoire, ainsi que la charge globale du système.

Identifier les processus qui consomment CPU et RAM

Une consommation excessive du processeur ou de la mémoire RAM peut fortement ralentir Linux, rendre un serveur difficilement accessible et, dans les cas extrêmes, provoquer l’arrêt de services ou le déclenchement de l’OOM Killer.

La première étape consiste donc à identifier les processus qui utilisent le plus de ressources.

Surveiller les processus avec top

La commande top affiche en temps réel l’utilisation du processeur, de la mémoire et les processus actifs :

top

Dans la liste des processus, surveillez principalement les colonnes suivantes :

Colonne	Description
PID	Identifiant du processus
USER	Utilisateur qui exécute le processus
%CPU	Pourcentage de processeur utilisé
%MEM	Pourcentage de mémoire RAM utilisé
RES	Quantité de mémoire physique actuellement utilisée par le processus
VIRT	Espace mémoire virtuel associé au processus
S	État actuel du processus
TIME+	Temps CPU total consommé par le processus

Dans top, vous pouvez notamment utiliser :

P pour classer les processus par consommation CPU.
M pour les classer par consommation mémoire.
1 pour afficher séparément l’activité de chaque cœur ou processeur logique.
q pour quitter.

Un processus qui reste durablement en tête avec une valeur %CPU ou %MEM élevée mérite d’être examiné.

Afficher les processus consommant le plus de CPU

Vous pouvez également obtenir directement les processus les plus gourmands en processeur avec ps :

ps aux --sort=-%cpu | head -20

Pour afficher seulement les informations essentielles :

ps -eo pid,user,comm,%cpu,%mem --sort=-%cpu | head -20

Cette commande est particulièrement pratique lorsqu’un serveur présente une charge CPU anormalement élevée.

Afficher les processus consommant le plus de RAM

Pour classer les processus selon leur consommation mémoire :

ps aux --sort=-%mem | head -20

Ou avec un affichage plus compact :

ps -eo pid,user,comm,%cpu,%mem,rss --sort=-%mem | head -20

La colonne RSS correspond approximativement à la quantité de mémoire physique actuellement occupée par le processus.

Sur un serveur Web, vous pouvez par exemple constater qu’un grand nombre de processus php-fpm, mysqld, mariadbd, Apache ou Java utilisent une part importante de la RAM.

Repérer les processus bloqués en attente d’I/O

Une forte charge système ne provient pas nécessairement d’une utilisation élevée du CPU. Des processus peuvent être bloqués en attente d’une opération d’entrée/sortie, notamment lorsqu’un disque ou un système de fichiers rencontre des problèmes.

Dans top, examinez la colonne S correspondant à l’état du processus.

Un processus avec l’état :

est en Uninterruptible Sleep, généralement parce qu’il attend la fin d’une opération d’I/O.

Pour rechercher ces processus :

ps -eo state,pid,ppid,comm,wchan:32 | awk '$1=="D"'

Quelques processus passant brièvement dans cet état ne sont pas forcément anormaux. En revanche, de nombreux processus durablement bloqués en état D peuvent indiquer un problème de disque, de stockage réseau (NFS), de système de fichiers ou de périphérique.

Dans ce cas, vérifiez les messages du noyau avec :

sudo dmesg -T

et :

sudo journalctl -k

Ne pas se limiter au processus qui consomme le plus

Un processus utilisant momentanément 100 % d’un cœur CPU n’indique pas nécessairement un problème. Une compression, une compilation, une sauvegarde ou une requête de base de données peut légitimement solliciter fortement le processeur pendant quelques secondes ou minutes.

Ce qui doit davantage attirer votre attention est une consommation élevée et persistante, notamment lorsqu’elle coïncide avec les ralentissements ou les blocages observés.

De même, si plusieurs processus d’un même service consomment beaucoup de ressources, recherchez la cause avant de simplement les terminer. Par exemple, de nombreux workers PHP-FPM fortement sollicités peuvent être la conséquence d’un trafic important, d’un script PHP lent, d’une requête SQL bloquée ou d’une mauvaise configuration du pool PHP-FPM.

L’étape suivante consiste alors à examiner la charge système (Load Average) afin de déterminer si le processeur est réellement saturé ou si les processus attendent principalement des ressources comme le disque.

Vérifier la charge système (Load Average)

Le Load Average permet d’évaluer la charge globale d’un système Linux. Il est particulièrement utile lorsqu’un PC ou un serveur devient lent, répond difficilement ou semble se bloquer alors que l’utilisation du processeur ne paraît pas forcément très élevée.

Vous pouvez afficher le Load Average avec la commande :

uptime

Vous obtenez par exemple :

10:42:15 up 32 days, 4:18, 2 users, load average: 1.25, 2.10, 1.84

Les trois valeurs correspondent à la charge moyenne observée respectivement pendant les 1, 5 et 15 dernières minutes.

Vous retrouvez également ces valeurs en haut de l’écran avec :

top

Contrairement à une idée fréquente, le Load Average ne correspond pas directement au pourcentage d’utilisation du processeur. Il prend notamment en compte les tâches prêtes à être exécutées ainsi que certaines tâches bloquées en attente d’une ressource, notamment des opérations d’entrée/sortie (I/O).

Ainsi, un serveur peut présenter un Load Average très élevé avec un CPU relativement peu utilisé si de nombreux processus sont bloqués dans l’attente d’un disque, d’un stockage réseau ou d’un autre périphérique.

Interpréter le Load Average

Il faut comparer la charge au nombre de processeurs logiques disponibles.

Vous pouvez connaître ce nombre avec :

nproc

Par exemple, sur un système disposant de 8 CPU logiques :

Load Average	Interprétation
1	Charge faible
4	Environ la moitié de la capacité disponible est sollicitée
8	Les CPU sont globalement pleinement occupés
16	La demande dépasse fortement les ressources disponibles

Ces valeurs restent toutefois indicatives : un Load Average élevé ne signifie pas automatiquement que le processeur est saturé.

Déterminer si la charge vient du CPU ou des I/O

Commencez par examiner top.

Si le CPU est fortement utilisé et qu’un ou plusieurs processus présentent un %CPU élevé, recherchez le processus responsable.

En revanche, si le Load Average est élevé alors que le CPU reste relativement disponible, recherchez des processus en état D (Uninterruptible Sleep) :

ps -eo state,pid,ppid,comm,wchan:32 | awk '$1=="D"'

De nombreux processus durablement en état D peuvent indiquer un problème d’I/O, par exemple :

Un disque dur ou SSD très lent ou défaillant.
Des erreurs du système de fichiers.
Un stockage NFS indisponible.
Un périphérique bloqué.
Une saturation importante des entrées/sorties.

Dans ce cas, vérifiez également les messages du noyau :

sudo dmesg -T

ainsi que les journaux :

sudo journalctl -k

Une augmentation brutale et persistante du Load Average constitue donc un indicateur important, mais il faut toujours rechercher ce qui provoque cette charge avant de conclure à un problème CPU.

Les tutoriels :

Vérifier l’espace disque

Un disque ou une partition pleine peut provoquer des ralentissements, empêcher certains services de démarrer ou rendre Linux instable. C’est particulièrement problématique lorsque les partitions /, /var ou /tmp n’ont plus d’espace disponible.

Pour vérifier rapidement l’espace disque :

df -h

Surveillez la colonne Use% et recherchez les systèmes de fichiers proches de 100 % d’utilisation.

Vérifiez également les inodes, car une partition peut ne plus accepter de nouveaux fichiers alors qu’il reste encore de l’espace disque :

df -i

Si une partition est saturée, identifiez ensuite les répertoires et fichiers qui occupent le plus d’espace avant de poursuivre le diagnostic.

Les tutoriels :

Comment vérifier l’espace disque avec les commandes df et du sous Linux

Vérifier les inodes

Même lorsqu’il reste de l’espace disque disponible, Linux peut devenir incapable de créer de nouveaux fichiers si tous les inodes sont utilisés. Ce problème peut notamment provoquer des erreurs d’écriture, empêcher la création de fichiers temporaires ou perturber certains services.

Pour vérifier l’utilisation des inodes :

df -i

Surveillez particulièrement les colonnes IUse% et IFree. Si IUse% atteint 100 %, le système de fichiers ne peut plus créer de nouveaux fichiers, même s’il dispose encore de plusieurs gigaoctets d’espace libre.

Ce problème est généralement provoqué par la présence d’un très grand nombre de petits fichiers, par exemple dans un répertoire de cache, de sessions PHP, de logs ou de fichiers temporaires.

Si les inodes sont saturés, recherchez les répertoires contenant un nombre anormalement élevé de fichiers avant de les nettoyer.

Pour aller plus loin, reportez-vous à ce guide :

Inode Linux : comprendre, vérifier et résoudre les problèmes d’inodes

Vérifier les services en échec

Un problème avec un service Linux peut parfois donner l’impression que le système entier est en panne. Sur un serveur, l’arrêt de Nginx, Apache, PHP-FPM, MariaDB/MySQL, SSH ou d’un autre service essentiel peut rendre un site ou une fonctionnalité inaccessible alors que Linux continue de fonctionner normalement.

Sur les distributions utilisant systemd, commencez par rechercher les services en échec :

systemctl --failed

Si un service apparaît avec l’état failed, vérifiez son état :

systemctl status nom-du-service

Puis consultez ses journaux :

sudo journalctl -u nom-du-service -e

Ces informations permettent généralement de déterminer si l’échec provient d’une erreur de configuration, d’un problème de permissions, d’une dépendance, d’un port déjà utilisé, d’un manque de ressources ou du plantage de l’application.

Pour aller plus loin et apprendre à diagnostiquer puis remettre en fonctionnement un service en échec :

Pour aller plus loin :

Vérifier et dépanner un service sous Linux avec systemctl et journalctl

Afficher les services en échec sous Linux avec systemctl

Diagnostiquer le matériel sous Linux

Si les journaux ne permettent pas d’identifier clairement l’origine du plantage, il est recommandé de vérifier l’état du matériel du PC ou du serveur Linux. Une RAM instable, un SSD défaillant, une surchauffe ou des erreurs CPU/PCIe peuvent provoquer des blocages et des redémarrages difficiles à distinguer d’un problème logiciel.

Linux fournit de nombreux outils permettant de rechercher ces anomalies directement en ligne de commandes. Vous pouvez notamment contrôler :

La mémoire RAM et rechercher les erreurs EDAC.
Le processeur et les erreurs MCE (Machine Check Exception).
Les disques durs, SSD SATA et NVMe avec SMART et les journaux du noyau.
Les températures et le thermal throttling.
Les périphériques PCIe et les erreurs AER.
Les erreurs matérielles enregistrées par dmesg et journalctl.

Si les plantages sont aléatoires, accompagnés de Kernel Panic, segfault, I/O error, Hardware Error, MCE, erreurs PCIe ou de redémarrages inexpliqués, poursuivez le diagnostic avec le guide dédié :

Le guide ultime à suivre :

Diagnostiquer le matériel sous Linux en ligne de commandes

Examiner les crashs avec coredumpctl

Lorsqu’une application se termine brutalement avec une erreur de segmentation (segfault) ou un autre signal fatal, systemd peut enregistrer un core dump contenant des informations sur l’état du processus au moment du crash.

La commande coredumpctl permet de retrouver ces plantages et constitue un outil particulièrement utile lorsqu’un programme ou un service plante régulièrement sans explication apparente.

Pour afficher les crashs enregistrés :

coredumpctl list

Vous obtenez notamment le PID, le nom de l’exécutable, l’utilisateur, le signal ayant provoqué le crash et la date de l’événement.

Pour afficher les informations détaillées du dernier crash :

coredumpctl info

Vous pouvez également cibler un programme particulier :

coredumpctl info php-fpm

ou rechercher ses différents crashs :

coredumpctl list php-fpm

Portez particulièrement attention aux champs Signal, Executable, Command Line et aux éventuelles informations de pile d’appels. Un signal SIGSEGV indique par exemple une erreur de segmentation, souvent liée à un bug du programme, une bibliothèque ou une extension défectueuse, voire plus rarement à un problème matériel.

Pour analyser plus profondément un core dump avec GDB, utilisez :

coredumpctl debug

ou pour un programme particulier :

coredumpctl debug nom-du-programme

Cette analyse est surtout destinée aux utilisateurs avancés et aux développeurs, mais elle peut permettre d’identifier précisément la bibliothèque, l’extension ou la fonction dans laquelle le programme a planté.

Si coredumpctl ne retourne aucun résultat, cela ne signifie pas nécessairement qu’aucun programme n’a crashé : la collecte des core dumps peut être désactivée ou limitée par la configuration de systemd. Dans ce cas, recherchez également les messages segfault, core dumped ou SIGSEGV dans journalctl.

Vérifier si le problème est réellement réseau

Sur un serveur Linux administré à distance, une perte de connexion SSH ou l’indisponibilité d’un site Web ne signifie pas forcément que Linux a planté. Le système peut continuer à fonctionner normalement alors qu’un problème réseau empêche simplement d’y accéder.

Avant de rechercher une panne matérielle ou un Kernel Panic, vérifiez donc si le serveur répond toujours sur le réseau.

Depuis une autre machine, commencez par tester sa connectivité :

ping adresse-ip-du-serveur

L’absence de réponse au ping n’est toutefois pas une preuve de panne, car les requêtes ICMP peuvent être bloquées par le pare-feu.

Si vous disposez d’un accès local ou d’une console fournie par l’hébergeur, vérifiez l’état des interfaces réseau :

ip addr

Puis les routes configurées :

ip route

Vérifiez également que l’interface réseau est bien active :

ip link

Vérifier le service SSH

Si seul l’accès SSH ne fonctionne plus, contrôlez d’abord l’état du serveur SSH :

systemctl status ssh

Selon la distribution, le service peut également être nommé sshd :

systemctl status sshd

Consultez ensuite ses derniers événements :

journalctl -u ssh

ou :

journalctl -u sshd

Vérifier les ports en écoute

La commande ss permet de vérifier que les services attendus écoutent toujours sur leurs ports :

sudo ss -lntup

Par exemple, vous devez normalement retrouver le port 22 pour SSH, ainsi que les ports 80 et 443 pour un serveur Web.

Si le serveur répond au réseau mais qu’un port particulier n’est plus en écoute, le problème provient probablement du service concerné plutôt que d’un plantage de Linux.

Enfin, vérifiez les journaux du noyau à la recherche d’une perte de lien ou d’une erreur du pilote réseau :

sudo journalctl -k | grep -i -E "network|link.*down|nic|eth|timeout|reset"

Si le serveur reste accessible depuis une console locale ou la console de l’hébergeur, mais plus depuis Internet, concentrez le diagnostic sur l’interface réseau, le routage, le pare-feu, le service SSH et l’infrastructure réseau. Cela évite de rechercher inutilement un problème de CPU, RAM ou stockage alors que Linux fonctionne toujours correctement.

Que vérifier après un plantage Linux ?

Après un plantage, un blocage ou un redémarrage inattendu de Linux, il est préférable de suivre une méthode de diagnostic plutôt que de rechercher des erreurs au hasard. Commencez par les journaux du système et du noyau, puis vérifiez les ressources, le stockage et enfin le matériel.

Le tableau suivant récapitule les principales vérifications à effectuer.

Priorité	Vérification	Commande principale	Ce qu’il faut rechercher
1	Vérifier les derniers arrêts et redémarrages	`last -x`	Redémarrage sans arrêt normal, crash ou reboot inattendu
2	Examiner le démarrage précédent	`journalctl -b -1`	Erreurs enregistrées juste avant le plantage
3	Examiner les erreurs du noyau	`journalctl -k -b -1`	Kernel Panic, pilote, I/O, matériel, watchdog
4	Rechercher un manque de mémoire	`journalctl -k -b -1 \| grep -i -E "oom\|out of memory\|killed process"`	OOM Killer et processus arrêté faute de RAM
5	Vérifier les services en échec	`systemctl --failed`	Service arrêté ou n’ayant pas réussi à démarrer
6	Vérifier CPU et mémoire	`top` et `free -h`	Processus gourmand, RAM insuffisante, swap fortement utilisé
7	Vérifier le Load Average	`uptime`	Charge anormalement élevée, saturation CPU ou attente d’I/O
8	Vérifier l’espace disque	`df -h`	Partition pleine, notamment `/`, `/var` ou `/tmp`
9	Vérifier les inodes	`df -i`	`IUse%` à 100 %, empêchant la création de nouveaux fichiers
10	Rechercher les erreurs de stockage et de système de fichiers	`dmesg -T`	I/O error, EXT4-fs error, XFS, Btrfs, NVMe, ATA
11	Vérifier l’état SMART	`smartctl -a /dev/sda`	Erreurs SMART, secteurs instables, erreurs NVMe
12	Rechercher les crashs d’applications	`coredumpctl list`	Segfault, SIGSEGV et processus ayant généré un core dump
13	Vérifier les températures	`sensors`	Surchauffe et thermal throttling
14	Rechercher les erreurs matérielles	`journalctl -k`	MCE, EDAC, Hardware Error, PCIe/AER
15	Tester la mémoire	Memtest86+	Erreurs de RAM ou instabilité mémoire

Le moment où vous effectuez le diagnostic est important. Après un plantage suivi d’un redémarrage, privilégiez les commandes utilisant -b -1, qui permettent d’examiner le démarrage précédent. Les journaux du démarrage actuel peuvent ne plus contenir les événements qui ont provoqué le crash.

Il faut également rechercher une corrélation entre plusieurs indices. Par exemple, des erreurs I/O error dans le journal du noyau, associées à des erreurs SMART et à des processus bloqués en état D, orientent fortement vers un problème de stockage. De même, des messages Out of memory suivis de Killed process permettent d’identifier un manque de mémoire plutôt qu’un véritable plantage du noyau.

Enfin, si un serveur est uniquement devenu inaccessible à distance, vérifiez d’abord le réseau, SSH et les services concernés. Une perte d’accès ne signifie pas nécessairement que Linux a planté.

Cette check-list permet ainsi de progresser du symptôme vers la cause, en distinguant un problème logiciel, un manque de ressources, une défaillance du stockage, une erreur du noyau ou une panne matérielle.