Un programme se ferme brusquement et le terminal affiche Segmentation fault, parfois traduit par « erreur de segmentation » ? Sous Linux, ce message indique généralement que le processus a tenté d’accéder à une zone mémoire qu’il n’avait pas le droit d’utiliser. Le noyau lui envoie alors le signal SIGSEGV et met fin à son exécution.
Le message seul ne révèle pas la cause. Il faut d’abord identifier précisément l’application concernée, retrouver les événements enregistrés au moment du crash, puis examiner le core dump lorsqu’il existe. Cette démarche permet de différencier un bug de l’application, une bibliothèque incompatible, un pilote défaillant ou, plus rarement, un problème matériel.
Ce guide présente une méthode progressive avec journalctl, dmesg, coredumpctl et GDB. Il s’adresse aux utilisateurs Linux : il n’est pas nécessaire de savoir programmer pour recueillir une trace utile et choisir la bonne correction.
Qu’est-ce qu’une erreur « Segmentation fault » sous Linux ?
Comprendre simplement le signal SIGSEGV
Chaque programme dispose d’un espace mémoire protégé. Il y place son code, ses bibliothèques et les données dont il a besoin. Si le programme tente de lire ou d’écrire à une adresse invalide, le noyau bloque l’opération. Il envoie le signal SIGSEGV, généralement identifié par le numéro 11, puis arrête le processus.
Un segfault concerne donc d’abord un processus. Il ne signifie pas automatiquement que Linux entier est instable. Si l’écran se fige, si la machine redémarre ou si plusieurs services cessent de répondre en même temps, commencez plutôt par le guide consacré aux blocages et plantages généraux de Linux.
Les causes les plus fréquentes
Un bug dans l’application : une mauvaise gestion de la mémoire peut provoquer un accès invalide. C’est la cause la plus probable lorsqu’un seul programme plante toujours de la même façon.
Une extension ou un module : un greffon de navigateur, un module Python, un thème ou une extension native peut faire tomber le processus principal.
Une bibliothèque incompatible : le programme peut charger une version de bibliothèque qui ne correspond pas à celle attendue, notamment après une mise à jour incomplète ou l’installation manuelle d’un logiciel.
Un paquet ou un fichier corrompu : un binaire endommagé ou des données illisibles peuvent déclencher le crash au lancement ou lors d’une opération précise.
Un pilote : les applications utilisant intensivement le GPU, le son ou un périphérique peuvent planter dans une bibliothèque liée au pilote.
La mémoire vive : une RAM instable reste possible, mais elle est surtout suspecte lorsque des applications différentes plantent à des endroits variables.
Évitez donc de réinstaller immédiatement le système ou de remplacer la RAM après un seul segfault. Les journaux et la trace d’appels permettent souvent de réduire fortement le champ des causes.
Identifier l’application qui provoque le segfault
Reproduire le plantage et relever le message affiché
Notez l’heure exacte du problème, le nom de l’application et l’action effectuée juste avant sa fermeture. Si le programme possède une commande de lancement, exécutez-la depuis un terminal. Vous verrez ainsi ses messages d’erreur au lieu de constater seulement la disparition de sa fenêtre.
nom-du-programme
echo $?
Sous Bash, un programme interrompu par SIGSEGV renvoie généralement le code 139, soit 128 + le numéro du signal 11. Ce code confirme le signal reçu, mais pas l’origine du problème.
Le code de sortie ne suffit pas à établir la cause, mais il confirme que le programme ne s’est pas terminé normalement. Ne reproduisez pas plusieurs fois une opération susceptible d’endommager des données. Travaillez sur une copie si le crash survient lors de l’ouverture ou de la conversion d’un fichier important.
Consulter les erreurs avec journalctl
Sur une distribution utilisant systemd, journalctl centralise les événements du système et des services. Commencez par limiter la recherche à la période du crash :
L’option -b limite la sortie au démarrage actuel. La recherche avec --grep nécessite une version relativement récente de systemd. Si elle n’est pas reconnue, affichez simplement la période utile puis recherchez le nom du programme dans la sortie.
Pour une application lancée comme service systemd, interrogez directement son unité :
Recherchez notamment le nom de l’exécutable, segfault, SIGSEGV, le signal 11 et le nom d’une bibliothèque se terminant par .so. Conservez plusieurs lignes avant et après l’événement afin de ne pas perdre son contexte.
Le noyau peut lui aussi enregistrer le processus fautif, l’adresse mémoire et la bibliothèque impliquée. La commande suivante rend les dates plus lisibles et filtre les événements courants :
Selon la politique de sécurité de la distribution, la lecture de dmesg peut être réservée à l’administrateur, d’où l’emploi de sudo. Une ligne mentionnant toujours le même exécutable ou la même bibliothèque oriente vers un défaut logiciel reproductible. Des processus très différents, des adresses changeantes et d’autres erreurs matérielles justifient une vérification plus large.
Un core dump est un instantané de la mémoire et de l’état du processus au moment de son arrêt. Lorsqu’il est géré par systemd-coredump, coredumpctl permet de retrouver les crashes sans chercher manuellement un fichier core.
Selon la distribution, systemd-coredump peut être absent ou désactivé. L’absence de résultat avec coredumpctl ne signifie donc pas qu’aucun segfault ne s’est produit.
coredumpctl list
coredumpctl list nom-du-programme
coredumpctl -1 info
La liste indique notamment la date, le PID, le signal, le chemin de l’exécutable et l’état du core dump. Dans la colonne correspondante, present signifie que le fichier est encore accessible. missing indique que son entrée existe toujours dans le journal mais que le fichier a été supprimé. truncated signale un enregistrement incomplet.
Pour éviter d’analyser le mauvais crash, utilisez le PID affiché ou le chemin complet de l’exécutable :
coredumpctl info 12345
coredumpctl info /chemin/vers/le-programme
Que faire lorsqu’aucun core dump n’est disponible ?
L’absence de résultat ne prouve pas l’absence de segfault. Le stockage peut être désactivé, le fichier peut avoir expiré, votre compte peut ne pas avoir les droits nécessaires ou la distribution peut ne pas utiliser systemd-coredump. Vérifiez d’abord la limite appliquée au shell et la destination configurée par le noyau :
ulimit -c
cat /proc/sys/kernel/core_pattern
Une limite égale à 0 interdit la création d’un core dump pour les programmes lancés depuis ce shell. Pour un test ponctuel, vous pouvez ouvrir un nouveau terminal, autoriser les core dumps dans cette session, puis lancer l’application depuis ce même terminal :
ulimit -c unlimited
nom-du-programme
Cette modification concerne la session et les processus qu’elle lance ; elle ne constitue pas une configuration permanente de tout le système. Un core dump peut contenir des données présentes dans la mémoire de l’application, par exemple des documents, des URL ou des jetons de session. Ne le publiez pas tel quel sur un forum ou un gestionnaire de bugs.
Analyser le segfault avec GDB
Installer GDB et ouvrir le core dump
GDB est un débogueur, mais quelques commandes suffisent pour obtenir une trace utile sans modifier le programme. Installez-le avec le gestionnaire de paquets de votre distribution :
# Debian, Ubuntu et dérivées
sudo apt install gdb
# Fedora
sudo dnf install gdb
# Arch Linux et dérivées
sudo pacman -S gdb
Avec systemd, le moyen le plus simple consiste à demander à coredumpctl d’ouvrir le dernier crash correspondant :
coredumpctl debug nom-du-programme
Si plusieurs entrées portent ce nom, utilisez le PID relevé précédemment. GDB charge alors l’exécutable et le core dump associés. Pour un core dump conservé manuellement, la syntaxe générale est :
Lorsque l’invite (gdb) apparaît, lancez la commande backtrace, abrégée en bt :
bt
thread apply all bt
quit
La première commande affiche la pile d’appels du thread qui a planté. La seconde affiche la trace de tous les threads ; elle est utile pour les applications multithreadées. Chaque ligne représente une fonction appelée avant le crash. La trame #0 correspond au point où l’exécution s’est arrêtée, puis #1, #2 et les suivantes remontent la chaîne des appels.
Si la sortie contient principalement des adresses hexadécimales, des points d’interrogation ou la mention no debugging symbols found, les symboles de débogage manquent. Le core dump reste valide, mais la trace sera moins parlante. Les paquets de symboles portent des noms différents selon la distribution ; recherchez ceux de l’application et de la bibliothèque citée dans les premières trames.
Repérer l’application ou la bibliothèque en cause
Ne concluez pas automatiquement que la fonction affichée en #0 contient le bug. Elle peut avoir reçu des données invalides d’un appel précédent. Pour un utilisateur, l’objectif est surtout d’identifier un motif :
le nom de l’application revient dans les premières trames : cherchez une mise à jour ou un rapport de bug correspondant à cette version ;
une extension ou un module tiers apparaît : désactivez-le temporairement et refaites le test ;
une bibliothèque graphique ou un pilote revient systématiquement : comparez avec les dernières mises à jour du pilote et testez, si l’application le permet, sans accélération matérielle ;
la trace change à chaque crash et plusieurs logiciels sont concernés : examinez la mémoire et le matériel avant d’accuser une application précise.
Avant de transmettre la trace, relisez-la et retirez les chemins contenant votre nom d’utilisateur ainsi que toute donnée confidentielle. Conservez toutefois les versions des paquets, le signal, les noms des bibliothèques et les numéros de trame.
Corriger le segfault selon son origine
Mettre à jour ou réinstaller le paquet concerné
Commencez par relever la version du programme, puis installez les mises à jour normales de votre distribution. Évitez de mélanger un paquet officiel avec des bibliothèques copiées manuellement dans /usr/local ou avec une archive téléchargée depuis une autre distribution.
Si le problème touche un seul paquet et persiste après la mise à jour, réinstallez uniquement ce paquet :
# Debian, Ubuntu et dérivées
sudo apt install --reinstall <nom-du-paquet>
# Fedora
sudo dnf reinstall <nom-du-paquet>
# Arch Linux et dérivées
sudo pacman -S <nom-du-paquet>
Une réinstallation remplace les fichiers gérés par le paquet, mais ne supprime généralement pas votre configuration personnelle. Si le crash semble lié au profil utilisateur, renommez son dossier de configuration pour effectuer un essai avec un profil neuf. Gardez l’ancien dossier comme sauvegarde et ne le supprimez qu’après avoir récupéré les données utiles.
Revenir à une version précédente après une régression
Un segfault apparu immédiatement après une mise à jour peut être une régression. Vérifiez l’historique du gestionnaire de paquets et la version signalée dans le core dump. Si votre distribution fournit encore la version précédente, un retour temporaire peut confirmer le diagnostic.
Ne téléchargez pas au hasard une ancienne bibliothèque depuis un site tiers et ne remplacez pas manuellement un fichier système. Une rétrogradation doit rester limitée au paquet concerné, utiliser les dépôts ou le cache de la distribution et être suivie d’une recherche de correctif. Notez la manipulation afin de pouvoir revenir à la version courante.
Vérifier les bibliothèques et les pilotes
Une trace pointant vers une bibliothèque ne prouve pas que celle-ci est seule responsable, mais elle fournit une piste. Comparez son paquet avec la version de l’application et terminez toute mise à jour interrompue. Pour un logiciel installé manuellement, testez si possible la version fournie par la distribution ou un format isolé officiellement proposé par l’éditeur.
Si le crash se produit lors de l’affichage 3D, de la lecture vidéo ou de l’ouverture d’une interface graphique, recherchez le pilote graphique dans journalctl, dmesg et la backtrace. Désactiver provisoirement l’accélération matérielle dans l’application peut servir de test, mais ce contournement ne remplace pas la mise à jour ou la correction du pilote.
Tester la mémoire lorsque plusieurs applications plantent
Une panne de RAM devient crédible lorsque des programmes sans rapport plantent aléatoirement, que les traces varient ou que les journaux contiennent aussi des erreurs matérielles. Vérifiez alors les événements du noyau et suivez une procédure de diagnostic matériel complète. L’article Diagnostiquer le matériel sous Linux en ligne de commandes détaille les contrôles de la mémoire, des disques, du processeur et des températures.
Avant un test prolongé, sauvegardez les données importantes. Si un profil XMP ou EXPO, un overclocking ou un réglage manuel de tension est actif, revenez aux valeurs stables recommandées par le fabricant pour vérifier si les erreurs cessent.
Checklist rapide pour résoudre un segfault
Les commandes à exécuter dans l’ordre
Notez l’heure, le nom du programme, l’action effectuée et la fréquence du crash.
Lancez si possible l’application dans un terminal pour récupérer son message d’erreur.
Consultez la période correspondante avec journalctl --since "10 minutes ago".
Recherchez les événements du noyau avec sudo dmesg --ctime.
Listez les crashes avec coredumpctl list, puis ouvrez l’entrée pertinente avec coredumpctl info.
Si un core dump est disponible, lancez coredumpctl debug, puis bt.
Mettez à jour ou réinstallez seulement le paquet identifié, puis refaites le test.
Si plusieurs programmes plantent de façon aléatoire, élargissez le diagnostic à la mémoire, aux pilotes, au stockage et à la stabilité matérielle.
Les informations à conserver pour demander de l’aide
la distribution Linux, sa version et la version du noyau obtenue avec uname -r ;
le nom exact et la version de l’application ;
les étapes permettant de reproduire le crash ;
les lignes pertinentes de journalctl et dmesg ;
le signal, le PID et le chemin de l’exécutable indiqués par coredumpctl info ;
la sortie de bt, nettoyée de toute donnée personnelle ou sensible ;
la date d’apparition du problème et les mises à jour installées juste avant.
Cette méthode transforme un message très général en diagnostic exploitable. Dans la majorité des cas, la combinaison des journaux, du core dump et de la backtrace permet au minimum d’identifier le composant concerné et d’éviter les corrections radicales sans rapport avec la cause réelle.
Télécharger un fichier depuis Internet ne garantit pas à lui seul qu’il provient bien de la source attendue ni qu’il n’a pas été modifié. Sous Linux, deux mécanismes complémentaires permettent d’effectuer ces vérifications : les sommes de contrôle pour l’intégrité et les signatures GPG pour l’authenticité.
GPG (GNU Privacy Guard) utilise la cryptographie asymétrique avec une clé privée et une clé publique. Une distribution Linux, un développeur ou un projet peut ainsi signer un fichier, une archive ou un fichier de sommes de contrôle comme SHA256SUMS. L’utilisateur peut ensuite vérifier cette signature avec la clé publique correspondante.
Dans ce guide, vous allez voir comment installer GnuPG sous Linux, importer et vérifier une clé publique, contrôler la signature d’un fichier avec gpg, vérifier une signature .sig ou .asc, valider une image ISO avec SHA256SUMS et comprendre les messages comme “Good signature”.
Nous verrons également comment distinguer intégrité et authenticité, et pourquoi il est important de vérifier l’empreinte de la clé publique avant de lui faire confiance.
Une signature GPG permet de vérifier qu’un fichier ou un message provient bien de la personne ou de l’organisation qui affirme l’avoir publié, et qu’il n’a pas été modifié depuis sa signature.
GPG (GNU Privacy Guard, ou GnuPG) repose sur la cryptographie asymétrique, avec une paire de clés :
une clé privée, conservée secrètement par son propriétaire et utilisée pour créer la signature ;
une clé publique, distribuée aux utilisateurs afin qu’ils puissent vérifier cette signature.
Lorsqu’un développeur ou une distribution Linux signe un fichier, GPG calcule une empreinte du contenu puis crée une signature à l’aide de la clé privée.
L’utilisateur peut ensuite vérifier cette signature avec la clé publique correspondante.
Par exemple :
gpg --verify fichier.iso.sig fichier.iso
Si la vérification réussit, GPG indique que la signature est valide et précise quelle clé a été utilisée.
Une signature GPG apporte donc deux informations importantes :
l’intégrité : le contenu signé n’a pas été modifié depuis la création de la signature ;
l’authenticité : la signature a été créée avec la clé privée correspondant à la clé publique utilisée pour la vérification.
Cela va plus loin qu’une simple somme de contrôle SHA256. Un hash permet de vérifier qu’un fichier correspond à une empreinte donnée, mais si un attaquant parvient à remplacer à la fois le fichier et le hash publié, cette comparaison ne suffit plus.
Avec une signature GPG, l’attaquant devrait également disposer de la clé privée du signataire pour produire une nouvelle signature valide.
Il reste toutefois une étape essentielle : s’assurer que la clé publique utilisée pour la vérification appartient réellement à l’éditeur. Pour cela, il faut notamment vérifier son empreinte (fingerprint) à partir d’une source officielle.
Les signatures GPG sont ainsi couramment utilisées pour vérifier des images ISO Linux, des archives, des paquets logiciels ou des fichiers de sommes de contrôle comme SHA256SUMS.
Installer GnuPG sous Linux
GnuPG est disponible dans les dépôts de la plupart des distributions Linux. Le paquet s’appelle généralement gnupg ou gnupg2.
Sous Debian, Ubuntu et leurs dérivées :
sudo apt update
sudo apt install gnupg
Sous Fedora :
sudo dnf install gnupg2
Sous Arch Linux et dérivées :
sudo pacman -S gnupg
Une fois l’installation terminée, vérifiez que GPG fonctionne avec :
gpg --version
La commande affiche la version installée ainsi que les principaux algorithmes pris en charge.
Vous pouvez ensuite afficher le contenu du trousseau de clés avec :
gpg --list-keys
Si aucune clé n’a encore été importée, la liste peut être vide.
Pour la vérification de signatures, il n’est pas nécessaire de créer votre propre paire de clés. Il suffit généralement d’importer la clé publique de l’éditeur ou de la distribution dont vous souhaitez vérifier les fichiers.
La prochaine étape consiste donc à récupérer puis importer cette clé publique dans GnuPG.
Importer une clé publique GPG
Pour vérifier une signature GPG, vous devez disposer de la clé publique du signataire. Cette clé permet à GnuPG de vérifier qu’une signature a bien été créée avec la clé privée correspondante.
Il existe principalement trois façons de récupérer cette clé publique.
Télécharger directement le fichier de clé publique
De nombreux projets publient leur clé sous la forme d’un fichier .asc, .gpg ou similaire.
Par exemple :
gpg --import cle-publique.asc
C’est souvent la méthode la plus simple lorsque le site officiel fournit directement la clé.
Après l’import, vérifiez sa présence avec :
gpg --list-keys
Récupérer la clé depuis un serveur de clés
Voici les étapes pour récupérer la clé publique avec cette méthode :
Si vous connaissez l’identifiant de la clé, vous pouvez la télécharger depuis un serveur de clés :
Le serveur de clés à utiliser dépend du projet. Il vaut mieux utiliser celui indiqué par la documentation officielle plutôt qu’un serveur choisi au hasard.
Dans le cas d’Ubuntu, par exemple, le serveur keyserver.ubuntu.com peut être utilisé.
Si vous ne connaissez pas encore l’identifiant de la clé, tentez d’abord de vérifier la signature :
gpg --keyid-format long --verify SHA256SUMS.gpg SHA256SUMS
GPG peut alors afficher :
gpg: Signature faite le jeu. 27 août 2026 22:43:09 UTC
gpg: avec la clef RSA 843938DF228D22F7B3742BC0D94AA3F0EFE21092
gpg: Impossible de vérifier la signature : Pas de clef publique
La ligne using RSA key indique l’identifiant de la clé manquante. Vous pouvez ensuite la récupérer :
Certains projets ne passent pas par un serveur de clés et fournissent leurs propres instructions : téléchargement direct d’une clé, paquet contenant le trousseau de clés, dépôt officiel, ou autre mécanisme.
Dans ce cas, suivez de préférence la méthode publiée par l’éditeur ou la distribution. C’est la meilleure façon d’éviter d’importer une clé non officielle ou périmée.
Quelle que soit la méthode utilisée, ne faites pas confiance à la clé uniquement parce qu’elle a été importée avec succès. Vérifiez ensuite son empreinte numérique avec :
gpg --fingerprint ID_DE_LA_CLE
Puis comparez-la avec celle publiée sur une source officielle.
Vérifier l’empreinte d’une clé publique
Avant d’utiliser une clé publique GPG pour vérifier une signature, il est important de contrôler son empreinte numérique, appelée fingerprint.
Cette empreinte est un identifiant unique associé à la clé. Elle permet de vérifier que la clé importée est bien celle publiée par l’éditeur, la distribution Linux ou le développeur concerné.
Pour afficher l’empreinte d’une clé :
gpg --fingerprint <ID_DE_LA_CLE>
Vous pouvez aussi afficher les empreintes de toutes les clés présentes dans votre trousseau :
gpg --fingerprint
GPG affiche alors une longue suite de caractères hexadécimaux, par exemple :
0123 4567 89AB CDEF 0123 4567 89AB CDEF 0123 4567
Comparez cette valeur avec l’empreinte publiée sur une source officielle : site du projet, documentation de la distribution, page de téléchargement ou autre canal de confiance.
Les deux empreintes doivent correspondre exactement.
Cette vérification est importante, car télécharger une clé depuis un serveur de clés ne suffit pas à prouver qu’elle appartient réellement à la personne ou au projet attendu. Un serveur de clés permet surtout de distribuer les clés, pas d’en garantir l’identité.
Une fois l’empreinte vérifiée, vous pouvez utiliser cette clé publique pour contrôler les signatures GPG des fichiers téléchargés.
Par exemple, pour afficher également l’identifiant court et l’empreinte dans un format plus lisible pour les scripts :
gpg --with-colons --fingerprint <ID_DE_LA_CLE>
Si l’empreinte ne correspond pas à celle publiée officiellement, n’utilisez pas la clé et récupérez-la à nouveau depuis une source fiable.
Vérifier la signature GPG d’un fichier
Une fois la clé publique du signataire importée et son empreinte vérifiée, vous pouvez utiliser GnuPG pour contrôler la signature d’un fichier.
Le cas le plus courant est celui d’une signature détachée, fournie dans un fichier séparé comme .sig, .asc ou .gpg.
Par exemple, si vous disposez de :
fichier.iso
fichier.iso.sig
utilisez :
gpg --verify fichier.iso.sig fichier.iso
GPG vérifie alors que la signature correspond bien au contenu du fichier et qu’elle a été créée avec la clé privée associée à la clé publique présente dans votre trousseau.
Si la vérification réussit, vous obtenez un message du type :
gpg: Good signature from "Nom du signataire"
Cela signifie que le fichier n’a pas été modifié depuis sa signature.
Attention toutefois : un message Good signature confirme que la signature est techniquement valide, mais il faut encore s’assurer que la clé utilisée appartient bien à la personne ou au projet attendu. C’est pourquoi la vérification préalable de l’empreinte de la clé publique reste indispensable.
Si le fichier a été modifié ou si la signature ne correspond pas, GPG affiche au contraire un message comme :
gpg: BAD signature from "Nom du signataire"
Dans ce cas, n’utilisez pas le fichier avant d’avoir vérifié son origine ou effectué un nouveau téléchargement.
Vérifier une signature détachée .sig ou .asc
Lorsque la signature est intégrée directement dans un fichier signé, GPG peut parfois déterminer automatiquement le contenu à vérifier, mais pour les téléchargements logiciels et images ISO, la signature détachée reste le cas le plus fréquent.
Une signature détachée est stockée dans un fichier séparé du fichier d’origine. Elle porte souvent l’extension .sig, .asc ou parfois .gpg.
Par exemple :
logiciel.tar.xz
logiciel.tar.xz.asc
ou :
image.iso
image.iso.sig
Pour vérifier une signature détachée, utilisez :
gpg --verify fichier.sig fichier
Par exemple :
gpg --verify logiciel.tar.xz.asc logiciel.tar.xz
ou :
gpg --verify image.iso.sig image.iso
GPG contrôle alors deux éléments :
que la signature correspond bien au fichier ;
que cette signature a été créée avec une clé privée correspondant à une clé publique présente dans votre trousseau.
Si la signature est valide, GPG affiche un message comme :
gpg: Good signature from "Nom du signataire"
Si le fichier a été modifié ou si la signature ne correspond pas :
gpg: BAD signature from "Nom du signataire"
L’extension .asc indique généralement une signature encodée en ASCII, tandis qu’un fichier .sig peut contenir une signature binaire. Dans les deux cas, la commande gpg --verify fonctionne de la même manière.
Il est également fréquent que la signature porte simplement le même nom que le fichier d’origine avec une extension supplémentaire. Cela facilite l’identification du fichier à vérifier.
Enfin, même avec une Good signature, vérifiez toujours que l’empreinte de la clé publique correspond bien à celle publiée par l’éditeur. Une signature valide n’est utile que si vous faites confiance à la bonne clé.
Vérifier une image ISO Linux avec SHA256SUMS et GPG
Certaines distributions Linux publient plusieurs fichiers permettant de vérifier leurs images ISO :
l’image ISO elle-même ;
un fichier de sommes de contrôle, par exemple SHA256SUMS ;
une signature GPG de ce fichier, par exemple SHA256SUMS.gpg ou SHA256SUMS.sign.
La vérification se fait alors en deux étapes.
Commencez par vérifier la signature du fichier SHA256SUMS :
gpg --verify SHA256SUMS.gpg SHA256SUMS
Si la signature est valide, GPG indique qu’elle a été créée avec une clé connue de votre trousseau.
Vous pouvez ensuite vérifier l’image ISO avec :
sha256sum -c SHA256SUMS
Si l’empreinte correspond :
ubuntu.iso: OK
Cette procédure apporte deux niveaux de vérification :
GPG permet de vérifier que le fichier SHA256SUMS a bien été signé avec la clé privée correspondant à la clé publique importée ;
SHA256 permet de vérifier que l’image ISO correspond exactement à l’empreinte contenue dans SHA256SUMS.
Il faut toutefois avoir vérifié au préalable que l’empreinte de la clé publique GPG correspond bien à celle publiée par la distribution Linux.
Le flux complet est donc :
Cette méthode est plus robuste qu’une simple comparaison du hash affiché sur une page web, car elle ajoute une vérification cryptographique de l’origine du fichier contenant les sommes de contrôle.
La procédure exacte peut varier selon la distribution. Certaines utilisent SHA256SUMS.gpg, d’autres .sig, .sign ou .asc, mais le principe reste le même.
Vérifier manuellement la signature d’un dépôt APT avec GPG
APT vérifie normalement automatiquement les dépôts configurés avec apt update, en contrôlant la signature du fichier Release ou InRelease. Il est néanmoins possible de reproduire cette vérification manuellement avec GPG, ce qui peut être utile pour comprendre la chaîne de confiance d’un dépôt.
Commencez par récupérer les métadonnées du dépôt, par exemple :
Vous devez ensuite disposer de la clé publique utilisée pour signer le dépôt. Importez-la dans votre trousseau GPG, par exemple :
gpg --import depot-public-key.asc
Vérifiez ensuite son empreinte :
gpg --fingerprint ID_DE_LA_CLE
Comparez cette empreinte avec celle publiée sur le site officiel du dépôt.
Une fois la clé validée, vérifiez la signature du fichier Release :
gpg --verify Release.gpg Release
Si tout est correct, GPG affiche notamment :
gpg: Good signature from "Nom du dépôt"
Certains dépôts utilisent plutôt un fichier InRelease, qui contient directement les métadonnées et leur signature OpenPGP. Dans ce cas :
gpg --verify InRelease
APT effectue normalement cette vérification automatiquement. Pour les dépôts tiers modernes, il est recommandé d’associer explicitement leur clé avec Signed-By et de placer les clés gérées localement dans /etc/apt/keyrings/, plutôt que d’utiliser apt-key, désormais déprécié.
Par exemple :
deb [signed-by=/etc/apt/keyrings/exemple.gpg] https://exemple.org/debian stable main
Ainsi, APT n’accepte ce dépôt que si ses métadonnées sont signées avec une clé présente dans le trousseau indiqué.
Que signifient « Good signature » et les avertissements GPG ?
Lors d’une vérification avec gpg --verify, GnuPG affiche plusieurs messages qui permettent de savoir si la signature est valide et si la clé utilisée est considérée comme fiable.
Le message le plus important est :
gpg: Good signature from "Nom du signataire"
Cela signifie que la signature correspond bien au fichier vérifié et qu’elle a été créée avec la clé privée associée à la clé publique présente dans votre trousseau.
En revanche, cela ne signifie pas automatiquement que vous pouvez faire confiance à cette clé.
GPG peut par exemple afficher :
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Ce message signifie que la signature est techniquement correcte, mais que GPG ne peut pas garantir que la clé publique appartient réellement à la personne ou au projet indiqué.
C’est pourquoi il faut vérifier l’empreinte de la clé publique auprès d’une source officielle.
À l’inverse, si GPG affiche :
gpg: BAD signature from "Nom du signataire"
la signature ne correspond pas au fichier. Celui-ci a pu être modifié, corrompu ou ne pas correspondre à la signature téléchargée.
Vous pouvez aussi rencontrer un message du type :
gpg: Can't check signature: No public key
Dans ce cas, la signature est présente, mais la clé publique nécessaire à sa vérification n’a pas encore été importée.
Enfin, GPG affiche généralement l’identifiant ou l’empreinte de la clé utilisée. Vérifiez cette valeur avec :
gpg --fingerprint ID_DE_LA_CLE
En résumé :
Message GPG
Signification
Good signature
La signature correspond au fichier
BAD signature
Le fichier ou la signature ne correspond pas
No public key
La clé publique nécessaire manque
avertissement sur la confiance
Signature valide, mais identité de la clé non vérifiée
Une Good signature est donc nécessaire, mais elle doit être associée à une clé publique dont l’empreinte a été vérifiée auprès d’une source de confiance.
Supprimer ou gérer les clés du trousseau GPG
Au fil du temps, votre trousseau GPG peut contenir plusieurs clés publiques importées pour vérifier des signatures. Vous pouvez les afficher, exporter ou supprimer selon vos besoins.
Pour lister les clés publiques présentes dans le trousseau :
gpg --list-keys
Pour afficher également leur empreinte :
gpg --fingerprint
Si vous souhaitez obtenir plus de détails sur une clé précise :
gpg --list-keys ID_DE_LA_CLE
Pour supprimer une clé publique devenue inutile :
gpg --delete-key ID_DE_LA_CLE
GPG vous demande une confirmation avant de retirer la clé du trousseau.
Si vous gérez aussi vos propres clés privées, leur suppression doit être effectuée séparément :
gpg --delete-secret-key ID_DE_LA_CLE
Attention : supprimer une clé privée peut vous empêcher de déchiffrer d’anciens fichiers ou de créer de nouvelles signatures avec cette identité. Sauvegardez-la avant toute suppression si elle vous appartient encore.
Vous pouvez également exporter une clé publique afin de la sauvegarder ou de la transférer vers une autre machine :
Conservez évidemment les exports de clés privées dans un emplacement sécurisé.
Enfin, si vous avez importé plusieurs clés portant des noms similaires, utilisez toujours leur empreinte complète pour les identifier sans ambiguïté avant de les supprimer ou de les exporter.
Intégrité et authenticité : quelle différence ?
Lorsqu’on vérifie un fichier téléchargé, il faut distinguer deux notions : l’intégrité et l’authenticité.
L’intégrité consiste à vérifier que le fichier n’a pas été modifié ou corrompu. Pour cela, on utilise généralement une somme de contrôle comme SHA256.
Par exemple :
sha256sum -c SHA256SUMS
Si le résultat affiche :
ubuntu.iso: OK
cela signifie que le fichier correspond bien à l’empreinte enregistrée dans SHA256SUMS.
Mais cette vérification ne prouve pas que le fichier SHA256SUMS lui-même provient bien de l’éditeur officiel.
C’est là qu’intervient l’authenticité.
Une signature GPG permet de vérifier que le fichier de sommes de contrôle, ou le fichier lui-même, a été signé avec la clé privée correspondant à une clé publique connue.
Par exemple :
gpg --verify SHA256SUMS.gpg SHA256SUMS
Si la signature est valide et que vous avez vérifié l’empreinte de la clé publique auprès d’une source officielle, vous pouvez alors avoir davantage confiance dans l’origine du fichier.
On peut résumer ainsi :
Vérification
Outil
Ce qu’elle confirme
Intégrité
SHA256, SHA512, etc.
Le fichier n’a pas changé par rapport à l’empreinte de référence
Authenticité
Signature GPG
La signature a été créée avec la clé privée correspondant à la clé publique utilisée
Identité du signataire
Empreinte de la clé GPG
La clé publique utilisée est bien celle de l’éditeur attendu
Pour une image ISO Linux, la méthode la plus complète consiste donc à :
vérifier l’empreinte de la clé publique GPG ;
vérifier la signature GPG du fichier SHA256SUMS ;
vérifier ensuite l’image ISO avec sha256sum -c.
Ainsi, SHA256 vérifie le contenu, tandis que GPG permet de vérifier l’origine de la référence utilisée pour ce contrôle.
Restic est un logiciel de sauvegarde gratuit et open source qui permet de protéger ses fichiers sous Windows, Linux et macOS. Il se distingue par son fonctionnement en ligne de commande, son chiffrement intégré, la déduplication des données et la gestion des sauvegardes sous forme de snapshots.
Avec Restic, vous pouvez sauvegarder des dossiers vers un disque local, un disque externe, un NAS, un serveur distant ou encore un stockage cloud via rclone. Les sauvegardes suivantes ne recopient pas inutilement les données déjà présentes, ce qui permet de réduire l’espace utilisé et d’accélérer les opérations.
L’outil permet également de restaurer une sauvegarde complète ou seulement certains fichiers, d’exclure des dossiers, de gérer une politique de rétention avec forget et prune, de vérifier l’intégrité du repository et d’automatiser les sauvegardes avec PowerShell, cron ou systemd.
Dans ce tutoriel, vous allez voir comment installer Restic, créer un repository, sauvegarder et restaurer vos fichiers, gérer les snapshots, supprimer les anciennes sauvegardes, vérifier leur intégrité et automatiser les sauvegardes.
Restic est particulièrement adapté si vous recherchez une solution de sauvegarde légère, chiffrée et scriptable, sans dépendre d’une interface graphique.
Qu’est-ce que Restic ?
Restic est un logiciel de sauvegarde en ligne de commande, gratuit et open source, conçu pour créer des sauvegardes rapides, chiffrées et dédupliquées.
Il fonctionne sous Windows, Linux, macOS et d’autres systèmes, et permet de sauvegarder des fichiers vers différents types de destinations : un disque local, un disque USB, un NAS, un serveur distant ou certains stockages cloud.
Restic repose sur deux notions principales :
le repository : l’emplacement dans lequel les données de sauvegarde sont stockées ;
le snapshot : une photographie de l’état des fichiers au moment d’une sauvegarde.
À chaque nouvelle sauvegarde, Restic ne recopie pas inutilement toutes les données déjà présentes. Il réutilise les blocs déjà sauvegardés et n’ajoute que les nouvelles données ou celles qui ont été modifiées. Cela permet de réduire l’espace disque utilisé et d’accélérer les sauvegardes suivantes.
Les données enregistrées dans le dépôt sont également chiffrées. Le contenu des fichiers, leurs noms et les métadonnées sont protégés par le mot de passe du repository.
Restic permet notamment de :
sauvegarder un ou plusieurs dossiers ;
conserver plusieurs versions grâce aux snapshots ;
restaurer une sauvegarde complète ou seulement certains fichiers ;
exclure des fichiers ou dossiers ;
vérifier l’intégrité du repository ;
supprimer automatiquement les anciennes sauvegardes ;
automatiser les sauvegardes avec le Planificateur de tâches de Windows, cron ou systemd ;
utiliser un stockage local ou distant.
Restic est donc particulièrement adapté si vous recherchez une solution de sauvegarde légère, fiable et scriptable, sans dépendre d’une interface graphique.
Son principal inconvénient est justement son fonctionnement en ligne de commande : il faut se familiariser avec quelques commandes pour créer le dépôt, lancer les sauvegardes et effectuer les restaurations. Une fois cette logique comprise, son utilisation reste toutefois assez simple.
Installer Restic sur Windows et Linux
Restic est disponible sous Windows et Linux. Il s’agit d’un programme en ligne de commande : une fois installé, vous l’utilisez depuis PowerShell, l’Invite de commandes ou un terminal Linux.
Installer Restic sous Windows
Sous Windows, Restic est disponible sous la forme d’un exécutable autonome. Il n’est donc pas nécessaire de passer par un programme d’installation classique.
Téléchargez la dernière version stable de Restic depuis la page officielle :
Choisissez l’archive correspondant à votre architecture, généralement Windows AMD64 pour un PC Windows 64 bits.
Après le téléchargement :
décompressez l’archive ;
renommez éventuellement le fichier en restic.exe ;
placez-le dans un dossier dédié, par exemple C:\Program Files\Restic\ ;
ajoutez ce dossier à la variable d’environnement PATH afin de pouvoir lancer Restic depuis n’importe quel terminal.
Vous pouvez ensuite vérifier que Restic fonctionne avec :
restic version
La version installée doit alors s’afficher.
Si vous ne souhaitez pas modifier le PATH, ouvrez PowerShell directement dans le dossier de Restic puis utilisez :
.\restic.exe version
Installer Restic sous Linux
Sous Linux, Restic est disponible dans les dépôts de nombreuses distributions.
Sur Debian, Ubuntu et dérivées :
sudo apt update
sudo apt install restic
Sur Fedora :
sudo dnf install restic
Sur Arch Linux et dérivées :
sudo pacman -S restic
Une fois l’installation terminée, vérifiez la version :
restic version
Vous pouvez aussi télécharger directement le binaire depuis le site officiel de Restic si vous souhaitez disposer d’une version plus récente que celle fournie par les dépôts de votre distribution.
Après l’installation, Restic est prêt à être utilisé. L’étape suivante consiste à créer un repository, c’est-à-dire l’emplacement dans lequel seront stockées les sauvegardes.
Créer un dépôt de sauvegarde Restic
Avant de pouvoir sauvegarder des fichiers avec Restic, il faut créer un dépôt, appelé repository. Il s’agit de l’emplacement dans lequel Restic va stocker les données, les métadonnées et les différents snapshots de sauvegarde.
Le dépôt peut se trouver sur un disque local, un disque USB, un NAS, un serveur distant ou un stockage cloud. Pour commencer simplement, vous pouvez créer un dépôt sur un autre disque.
Sous Windows, par exemple :
restic init --repo D:\Sauvegardes\Restic
Sous Linux :
restic init --repo /mnt/sauvegardes/restic
Lors de l’initialisation, Restic vous demande de définir un mot de passe. Celui-ci sert à chiffrer le contenu du dépôt.
Choisissez un mot de passe solide et conservez-le précieusement. Sans ce mot de passe, il ne sera pas possible d’accéder aux sauvegardes ni de restaurer les fichiers.
Le mot de passe ne peut pas être récupéré par Restic : conservez-en une copie dans un gestionnaire de mots de passe ou un emplacement sécurisé.
Une fois le dépôt créé, Restic affiche un message confirmant son initialisation.
Vous pouvez ensuite vérifier que le dépôt est accessible avec :
restic -r D:\Sauvegardes\Restic snapshots
ou sous Linux :
restic -r /mnt/sauvegardes/restic snapshots
Comme aucune sauvegarde n’a encore été effectuée, la liste des snapshots sera vide.
À partir de ce moment, le repository est prêt à recevoir les premières sauvegardes. Lors des commandes suivantes, l’option -r ou --repo permet d’indiquer à Restic quel dépôt utiliser.
Sauvegarder un dossier avec Restic
Une fois le repository créé, vous pouvez lancer votre première sauvegarde avec la commande backup.
Sous Windows, par exemple pour sauvegarder le dossier Documents :
Restic demande alors le mot de passe du repository, analyse les fichiers puis enregistre les données dans le dépôt.
À la fin de l’opération, un résumé indique notamment :
le nombre de fichiers analysés ;
le volume de données ajouté ;
la quantité réellement stockée après déduplication ;
la durée de la sauvegarde ;
l’identifiant du nouveau snapshot.
Lors des sauvegardes suivantes, Restic ne recopie pas inutilement les données déjà présentes dans le repository. Il détecte les nouveaux fichiers et les blocs modifiés, ce qui réduit le temps de sauvegarde et l’espace utilisé.
Vous pouvez également sauvegarder plusieurs dossiers dans une seule commande :
Il est aussi possible de sauvegarder un dossier complet contenant plusieurs sous-dossiers. Restic parcourt automatiquement son contenu de manière récursive.
Restic conserve chaque sauvegarde sous la forme d’un snapshot. Un snapshot représente l’état des fichiers au moment où la commande backup a été exécutée.
Pour afficher la liste des sauvegardes disponibles, utilisez :
restic -r D:\Sauvegardes\Restic snapshots
Sous Linux :
restic -r /mnt/sauvegardes/restic snapshots
Restic affiche alors un tableau contenant notamment :
l’identifiant du snapshot ;
la date et l’heure de la sauvegarde ;
le nom de l’ordinateur ;
l’utilisateur ;
les chemins sauvegardés.
L’identifiant du snapshot est particulièrement utile pour effectuer une restauration précise.
Par exemple, si Restic affiche un snapshot avec l’identifiant :
4f3a9c2b
Vous pourrez ensuite l’utiliser dans une commande de restauration.
Il est aussi possible d’afficher les informations détaillées d’un snapshot avec :
restic -r D:\Sauvegardes\Restic stats 4f3a9c2b
Pour afficher le contenu d’un snapshot sans restaurer les fichiers, utilisez :
restic -r D:\Sauvegardes\Restic ls 4f3a9c2b
Vous pouvez également utiliser le mot-clé latest pour cibler automatiquement la sauvegarde la plus récente :
restic -r D:\Sauvegardes\Restic ls latest
Cela évite d’avoir à recopier l’identifiant du dernier snapshot.
Enfin, si vous avez défini la variable RESTIC_REPOSITORY, la commande peut être simplifiée :
restic snapshots
Cette liste des snapshots permet de vérifier que les sauvegardes sont bien présentes et de choisir celle à utiliser pour restaurer des fichiers.
Restaurer des fichiers avec Restic
Restic permet de restaurer une sauvegarde complète ou seulement certains fichiers à partir d’un snapshot existant.
Pour restaurer le dernier snapshot disponible vers un dossier spécifique sous Windows :
Avant de restaurer, il peut être utile d’afficher le contenu du snapshot :
restic -r D:\Sauvegardes\Restic ls latest
Cela permet de vérifier les chemins présents dans la sauvegarde et d’éviter de restaurer des données inutiles.
Une fois la restauration terminée, contrôlez le contenu du dossier cible avant de remplacer d’éventuels fichiers existants sur le système.
Pour une restauration importante, il est préférable de restaurer d’abord vers un dossier temporaire, puis de recopier manuellement les fichiers souhaités à leur emplacement d’origine. Cela limite le risque d’écraser par erreur une version plus récente d’un fichier.
Exclure des fichiers et dossiers de la sauvegarde
Lors d’une sauvegarde, il peut être utile d’exclure certains fichiers inutiles, temporaires ou volumineux afin de réduire la taille du repository et d’accélérer l’opération.
Restic propose pour cela l’option --exclude.
Par exemple, pour exclure tous les fichiers temporaires :
Cette méthode est particulièrement utile pour automatiser les sauvegardes, car vous pouvez modifier les règles d’exclusion sans avoir à réécrire toute la commande.
Avant d’exclure un dossier, vérifiez toutefois qu’il ne contient pas de données importantes. Une exclusion mal définie peut empêcher certains fichiers d’être présents dans les snapshots suivants.
Supprimer les anciennes sauvegardes avec forget et prune
Au fil du temps, Restic peut conserver de nombreux snapshots. Pour éviter que le repository ne grossisse indéfiniment, vous pouvez supprimer les anciennes sauvegardes selon une politique de rétention.
Restic utilise principalement deux commandes pour cela :
forget : supprime les références aux snapshots devenus inutiles ;
prune : supprime réellement du repository les données qui ne sont plus utilisées par aucun snapshot.
Il est donc important de comprendre que forget seul ne libère pas forcément immédiatement tout l’espace disque.
Pour afficher d’abord les snapshots disponibles :
restic -r D:\Sauvegardes\Restic snapshots
Vous pouvez ensuite supprimer un snapshot précis avec son identifiant :
restic -r D:\Sauvegardes\Restic forget 4f3a9c2b
Pour appliquer une politique de rétention automatique, utilisez les options --keep-*.
Cette commande supprime les snapshots qui ne correspondent plus aux règles de conservation, mais les blocs de données devenus inutiles peuvent encore rester dans le repository.
Pour réellement récupérer l’espace disque, lancez ensuite :
restic -r D:\Sauvegardes\Restic prune
Il est également possible d’effectuer les deux opérations en une seule commande :
Cette méthode est particulièrement pratique dans un script de sauvegarde automatisé.
Avant de supprimer des snapshots, vérifiez toutefois que votre politique de rétention correspond bien à vos besoins. Une sauvegarde supprimée avec forget puis nettoyée avec prune ne pourra plus être restaurée.
Il est donc recommandé de commencer avec une rétention prudente, puis d’ajuster les valeurs en fonction de l’espace disponible et de la fréquence de vos sauvegardes.
Vérifier l’intégrité des sauvegardes avec restic check
Il est important de vérifier régulièrement que le repository Restic ne contient pas d’erreur et que les sauvegardes restent exploitables.
Pour cela, Restic propose la commande check.
Sous Windows :
restic -r D:\Sauvegardes\Restic check
Sous Linux :
restic -r /mnt/sauvegardes/restic check
Cette commande vérifie la structure du repository, les index, les snapshots et les références entre les différents objets stockés.
Si tout est correct, Restic termine l’analyse sans signaler d’erreur.
Pour effectuer une vérification plus poussée des données enregistrées, vous pouvez utiliser :
restic -r D:\Sauvegardes\Restic check --read-data
Cette option demande à Restic de lire les données présentes dans le repository afin de vérifier leur intégrité.
Attention toutefois : sur un repository volumineux, --read-data peut être beaucoup plus long qu’un simple check, car l’ensemble des données doit être parcouru.
Il est également possible de limiter la vérification à une partie des données, par exemple :
Cette méthode permet d’effectuer régulièrement un contrôle partiel sans relire tout le repository à chaque fois.
Dans une stratégie de sauvegarde sérieuse, vous pouvez par exemple :
lancer restic check régulièrement ;
effectuer ponctuellement un contrôle avec --read-data ;
tester de temps en temps une restauration réelle de quelques fichiers.
En effet, une sauvegarde n’est réellement fiable que si elle peut être restaurée correctement. Vérifier le repository est donc utile, mais il est également recommandé de tester périodiquement une restauration vers un dossier temporaire.
Sauvegarder vers un disque externe, un NAS ou un serveur distant
Restic peut enregistrer ses sauvegardes sur différents types de destinations. Le repository n’a pas besoin de se trouver sur le disque principal du PC : il peut être stocké sur un disque USB, un NAS ou un serveur distant.
Sauvegarder sur un disque externe
Pour un disque USB ou un second disque interne, il suffit d’utiliser son chemin comme repository.
Cette méthode permet notamment d’utiliser les nombreux fournisseurs compatibles avec rclone sans que Restic ait besoin de gérer directement chacun d’eux.
Quelle destination choisir ?
Pour une sauvegarde locale simple, un disque externe est souvent suffisant. Un NAS est plus pratique pour automatiser les sauvegardes de plusieurs machines, tandis qu’un serveur distant ou un stockage cloud permet de conserver une copie hors du domicile ou de l’entreprise.
Pour une meilleure protection des données, l’idéal reste de disposer d’au moins une copie de sauvegarde stockée sur un support ou un emplacement différent du PC sauvegardé.
Automatiser les sauvegardes Restic
Restic se prête très bien à l’automatisation. Une fois la commande de sauvegarde définie, vous pouvez la lancer régulièrement avec le Planificateur de tâches de Windows, cron sous Linux ou un service systemd.
L’objectif est généralement d’exécuter automatiquement une commande de ce type :
Le principal point à gérer est le mot de passe du repository. Pour éviter une saisie manuelle à chaque exécution, vous pouvez utiliser un fichier contenant le mot de passe.
Vous pourrez ainsi consulter le journal en cas d’échec ou vérifier la date de la dernière sauvegarde réussie.
Enfin, même avec une automatisation parfaitement configurée, contrôlez régulièrement la présence des snapshots avec restic snapshots et testez ponctuellement une restauration. Une tâche qui s’exécute automatiquement ne garantit pas à elle seule que les sauvegardes sont réellement exploitables.
Quelques commandes Restic utiles
Restic propose de nombreuses commandes pour gérer les sauvegardes, consulter les snapshots, restaurer des fichiers ou entretenir le repository. Voici les principales à connaître.
Ces commandes couvrent l’essentiel des opérations courantes avec Restic : création du dépôt, sauvegarde, restauration, gestion des snapshots et vérification des données.
Restic : avantages et limites
Restic est une solution de sauvegarde particulièrement intéressante si vous recherchez un outil léger, fiable, chiffré et facilement automatisable.
Ses principaux avantages sont :
le chiffrement intégré : les sauvegardes sont protégées avant leur stockage ;
la déduplication : les blocs déjà présents dans le repository ne sont pas recopiés inutilement ;
les snapshots : il est possible de conserver plusieurs états successifs des fichiers ;
la compatibilité multiplateforme : Restic fonctionne sous Windows, Linux et macOS ;
le support de nombreuses destinations : disque local, disque USB, NAS, serveur SFTP ou stockage distant via rclone ;
la simplicité de l’automatisation : les commandes peuvent facilement être intégrées à PowerShell, cron ou systemd ;
la vérification d’intégrité : la commande restic check permet de contrôler régulièrement l’état du repository ;
la restauration sélective : il est possible de restaurer un snapshot complet ou seulement certains fichiers.
Restic présente toutefois quelques limites.
La principale est son fonctionnement essentiellement en ligne de commande. Pour un utilisateur habitué aux logiciels de sauvegarde avec interface graphique, la prise en main peut demander un petit temps d’adaptation.
La gestion du mot de passe du repository demande également de la rigueur. Si vous perdez ce mot de passe, les données chiffrées ne pourront plus être restaurées.
Les opérations d’entretien comme forget, prune ou check --read-data peuvent aussi devenir longues sur de gros repositories, en particulier lorsque le stockage est distant ou relativement lent.
Enfin, Restic sauvegarde avant tout des fichiers et dossiers. Ce n’est pas un logiciel d’image système complet destiné à restaurer Windows entier, les partitions, le secteur de démarrage et toutes les applications après une panne de disque. Il ne remplace donc pas une image système si votre objectif est de restaurer Windows, les partitions et le démarrage après une panne complète du disque À lire :
sauvegarder régulièrement ses documents et données personnelles ;
conserver plusieurs versions de fichiers ;
envoyer des sauvegardes chiffrées vers un NAS ou un serveur distant ;
automatiser une stratégie de sauvegarde avec des scripts.
En revanche, si votre objectif est de pouvoir restaurer intégralement un PC après une panne du disque système, il est préférable de compléter Restic avec une sauvegarde d’image système.
Restic est donc particulièrement adapté aux utilisateurs qui recherchent une solution de sauvegarde sobre, sécurisée et scriptable, à condition d’être à l’aise avec quelques commandes.
Au démarrage de Linux, le noyau doit pouvoir identifier et monter la partition racine / pour accéder aux fichiers nécessaires au fonctionnement du système. Lorsque cette étape échoue, le démarrage peut s’interrompre sur un Kernel Panic accompagné du message :
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(...)
Cette erreur peut apparaître après une mise à jour du noyau, une modification des partitions ou de GRUB, mais aussi à cause d’un initramfs endommagé, d’un UUID incorrect, d’un pilote de stockage manquant, d’un système de fichiers corrompu ou d’un SSD/disque défaillant.
Il n’est généralement pas nécessaire de réinstaller Linux. En identifiant à quelle étape l’accès à la partition racine échoue, il est souvent possible de réparer le démarrage depuis GRUB, le mode de récupération ou un Live USB Linux.
Dans ce guide, découvrez les causes de l’erreur « VFS: Unable to mount root fs » et les solutions pour démarrer sur un ancien noyau, vérifier la partition racine et son UUID, reconstruire l’initramfs, réparer le système de fichiers et retrouver un Linux fonctionnel.
Qu’est-ce que l’erreur « VFS: Unable to mount root fs » ?
L’erreur « VFS: Unable to mount root fs » est un Kernel Panic qui se produit pendant le démarrage de Linux lorsque le noyau ne parvient pas à accéder ou à monter le système de fichiers racine.
Le message se présente généralement sous une forme proche de :
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Le système de fichiers racine, représenté par /, contient les fichiers indispensables au fonctionnement de Linux. Si le noyau ne parvient pas à le monter, il ne peut pas poursuivre normalement la séquence de démarrage et déclenche alors un Kernel Panic.
Le problème peut apparaître très tôt au démarrage, parfois juste après une mise à jour du noyau, une modification des partitions ou une opération ayant affecté l’initramfs ou le stockage.
Que signifie VFS ?
VFS (Virtual File System) est la couche du noyau Linux qui fournit une interface commune aux différents systèmes de fichiers, tels que ext4, XFS ou Btrfs.
Lorsque le message indique :
VFS: Unable to mount root fs
cela signifie donc que le noyau n’a pas réussi à monter le système de fichiers devant devenir la racine /.
Cela ne signifie pas nécessairement que le système de fichiers lui-même est endommagé. Le noyau peut tout simplement ne pas parvenir à trouver le périphérique qui le contient ou ne pas disposer du pilote nécessaire pour y accéder.
Que signifie « unknown-block » ?
La fin du message fournit également un indice important :
unknown-block(0,0)
Les deux nombres correspondent à des identifiants utilisés par Linux pour représenter le périphérique de stockage.
Lorsque le message indique unknown-block(0,0), le noyau ne parvient généralement pas à identifier correctement le périphérique contenant la partition racine. Il faut alors rechercher en priorité un problème concernant l’initramfs, le paramètre root=, l’UUID de la partition ou le pilote du contrôleur de stockage.
Dans d’autres situations, vous pouvez rencontrer par exemple :
unknown-block(8,1)
Le noyau a alors identifié un périphérique bloc précis, ce qui peut davantage orienter les recherches vers la partition, le système de fichiers ou son accessibilité.
Le contenu exact de unknown-block(...) constitue donc un indice de diagnostic, mais ne permet pas à lui seul de déterminer la cause.
Quelles sont les causes de « Unable to mount root fs » ?
L’erreur « VFS: Unable to mount root fs » signifie que le noyau Linux n’arrive pas à monter la partition racine /. Plusieurs problèmes peuvent interrompre la chaîne de démarrage entre GRUB, le noyau, l’initramfs et le périphérique de stockage.
Le message unknown-block(...) ainsi que les erreurs affichées juste avant le Kernel Panic peuvent fournir de précieux indices.
Mise à jour interrompue, mauvaise génération de l’image
Erreur apparue après une mise à jour du noyau
Nouveau noyau défectueux ou incompatible
Régression du kernel, module incompatible
Ancien noyau fonctionnel depuis GRUB
Mauvaise partition racine
Paramètre root= incorrect
UUID ou périphérique différent de la partition réelle
UUID incorrect
Partition recréée, clonée ou modifiée
UUID de GRUB/fstab différent de celui retourné par blkid
Pilote de stockage absent
NVMe, SATA, RAID ou contrôleur non disponible dans l’initramfs
Souvent unknown-block(0,0)
Système de fichiers endommagé
Corruption ext4, XFS, Btrfs…
Erreurs de système de fichiers avant le panic
SSD ou disque défaillant
Erreurs de lecture ou contrôleur instable
I/O error, erreurs NVMe/SATA
Configuration GRUB incorrecte
Mauvaise entrée ou paramètres du noyau erronés
Mauvais root=, problème après modification de GRUB
Démarrer Linux avec un ancien noyau
Si l’erreur « VFS: Unable to mount root fs » est apparue juste après une mise à jour du noyau Linux, commencez par essayer de démarrer avec la version précédente du kernel.
Linux conserve généralement plusieurs noyaux installés. Il est donc possible de sélectionner un ancien kernel depuis GRUB sans désinstaller immédiatement la nouvelle version.
Sélectionner un ancien noyau depuis GRUB
Redémarrez le PC et affichez le menu GRUB. Selon la distribution et la configuration, vous devrez éventuellement maintenir la touche Maj (Shift) ou appuyer plusieurs fois sur Échap (Esc) pendant le démarrage.
Ensuite :
Sélectionnez Options avancées pour Ubuntu, ou l’entrée équivalente de votre distribution.
GRUB affiche les différentes versions du noyau disponibles.
Sélectionnez une version antérieure du noyau, sans choisir le mode Recovery dans un premier temps.
Démarrez Linux normalement.
Si le système démarre correctement, vérifiez le noyau actuellement utilisé avec :
uname -r
Vous pouvez également afficher les noyaux présents dans /boot :
ls -lh /boot
Si l’ancien noyau fonctionne
Si Linux démarre avec le kernel précédent mais affiche « Unable to mount root fs » avec la version la plus récente, cela constitue un indice important.
Le problème peut notamment concerner :
L’initramfs associé au nouveau noyau.
Un pilote ou module de stockage absent de cet initramfs.
Un module DKMS qui n’a pas été correctement reconstruit.
Une régression ou une incompatibilité avec le nouveau kernel.
Dans ce cas, évitez de supprimer immédiatement l’ancien noyau fonctionnel : il constitue une solution de secours pendant le diagnostic.
Vous pouvez ensuite tenter de reconstruire l’initramfs du noyau problématique et mettre à jour la configuration de GRUB.
Si aucun ancien noyau ne démarre
Si plusieurs versions du noyau provoquent la même erreur, la piste d’une simple régression du kernel devient moins probable.
Il faut alors vérifier en priorité la partition racine, son UUID, l’initramfs, le système de fichiers et le périphérique de stockage.
Si Linux ne démarre avec aucun noyau disponible, utilisez le mode de récupération ou un Live USB Linux afin d’accéder au système et d’effectuer les réparations.
Le démarrage avec un ancien noyau constitue donc surtout un test de diagnostic rapide : si l’ancien kernel fonctionne, concentrez les recherches sur ce qui a changé avec la nouvelle version plutôt que de modifier immédiatement les partitions ou le système de fichiers.
Démarrer en mode de récupération
Si Linux ne démarre toujours pas normalement, le mode de récupération (Recovery Mode) permet d’accéder à plusieurs outils de dépannage sans charger complètement le système.
Il est particulièrement utile avec l’erreur « VFS: Unable to mount root fs », car il peut permettre d’obtenir un shell administrateur et d’effectuer certaines réparations sur le système de fichiers, l’initramfs ou la configuration du démarrage.
Depuis GRUB, ouvrez généralement Options avancées, puis sélectionnez une entrée du noyau comportant la mention Recovery Mode.
Selon la distribution et la situation, vous pourrez notamment :
Accéder à un shell root.
Vérifier ou réparer le système de fichiers.
Reconstruire l’initramfs.
Corriger une mise à jour de paquets interrompue.
Vérifier les partitions et leurs UUID.
Mettre à jour la configuration de GRUB.
Examiner les journaux et messages d’erreur.
Si plusieurs noyaux sont proposés, vous pouvez également essayer le mode de récupération d’un ancien kernel lorsque l’erreur est apparue après une mise à jour.
Pour accéder au mode Recovery et connaître les différents outils disponibles, suivez le guide correspondant à votre distribution :
Si le mode de récupération ne démarre pas non plus ou provoque le même Kernel Panic, utilisez plutôt un Live USB Linux. Celui-ci permettra d’accéder aux partitions depuis un système indépendant afin de vérifier le stockage, réparer le système de fichiers ou reconstruire l’initramfs.
Vérifier la partition racine et son UUID
L’erreur « VFS: Unable to mount root fs » peut apparaître lorsque le noyau Linux cherche la partition racine / au mauvais emplacement. Cela peut notamment se produire après un clonage de disque, une modification du partitionnement, une restauration ou un changement incorrect de la configuration de démarrage.
L’objectif est donc de vérifier que la partition existe toujours et que son UUID correspond à celui utilisé par Linux et GRUB.
Identifier la partition racine
Depuis le mode de récupération ou un Live USB Linux, affichez les partitions et leurs systèmes de fichiers :
lsblk -f
Vous pouvez compléter avec :
sudo blkid
Repérez la partition contenant votre installation Linux, par exemple :
L’UUID doit correspondre à celui obtenu avec lsblk -f ou blkid.
Si les valeurs sont différentes, Linux peut essayer de monter une ancienne partition ou un système de fichiers dont l’identifiant a changé.
Ne modifiez toutefois pas /etc/fstab avant d’avoir identifié avec certitude la partition racine.
Vérifier le paramètre root= de GRUB
GRUB indique également au noyau où se trouve la partition racine grâce au paramètre root=.
Si Linux démarre avec un ancien noyau, affichez les paramètres utilisés :
cat /proc/cmdline
Vous pouvez notamment obtenir :
root=UUID=a1b2c3d4-e5f6-7890-abcd-123456789abc
Vérifiez là encore que cet UUID correspond à celui de la véritable partition racine.
Si Linux ne démarre plus, sélectionnez son entrée dans GRUB puis appuyez sur e. Recherchez la ligne commençant par linux et vérifiez la valeur :
root=UUID=...
Vous pouvez temporairement remplacer un UUID incorrect par le bon afin de tester le démarrage. Cette modification n’est valable que pour cette tentative et ne change pas définitivement la configuration de GRUB.
Si Linux démarre après cette correction, vous avez probablement identifié la cause du problème.
Corriger définitivement l’UUID
Une fois Linux démarré, corrigez si nécessaire l’UUID incorrect dans /etc/fstab ou la configuration concernée, puis régénérez GRUB.
Sur Ubuntu et Debian :
sudo update-grub
Si la partition racine, son UUID et le paramètre root= sont déjà corrects mais que le Kernel Panic affiche toujours unknown-block(0,0), le problème vient probablement d’une autre étape du démarrage.
Il faut alors vérifier en priorité l’initramfs et les pilotes nécessaires pour accéder au périphérique de stockage.
Reconstruire l’initramfs
L’initramfs est chargé très tôt pendant le démarrage de Linux. Il contient notamment les modules et outils nécessaires pour détecter le périphérique de stockage et accéder à la partition racine /.
S’il est endommagé, incomplet ou ne contient plus un pilote nécessaire, le noyau peut ne pas parvenir à monter la partition racine et afficher l’erreur « VFS: Unable to mount root fs ». Cette situation peut notamment survenir après une mise à jour du noyau ou d’un pilote.
Reconstruire l’initramfs sur Ubuntu et Debian
Si vous pouvez démarrer avec un ancien noyau ou depuis le mode de récupération, reconstruisez les images initramfs avec :
sudo update-initramfs -u -k all
Pour reconstruire uniquement celle du noyau actuellement utilisé :
sudo update-initramfs -u -k "$(uname -r)"
Mettez ensuite à jour GRUB :
sudo update-grub
Puis redémarrez le PC et essayez à nouveau le noyau qui provoquait l’erreur.
Reconstruire l’initramfs sur Fedora et RHEL
Fedora, RHEL et plusieurs distributions dérivées utilisent généralement dracut.
Pour reconstruire l’initramfs du noyau en cours :
sudo dracut --force
Si plusieurs noyaux sont installés, vérifiez leurs versions :
ls /lib/modules/
Lorsque vous devez réparer un noyau différent de celui actuellement démarré, veillez à reconstruire l’image correspondant à la bonne version du kernel.
Vérifier que l’initramfs existe
Vous pouvez contrôler les images présentes dans /boot :
ls -lh /boot
Selon la distribution, vous devez notamment retrouver des fichiers de type :
vmlinuz-...
initrd.img-...
ou :
initramfs-....img
Vérifiez qu’une image initramfs existe bien pour le noyau que vous essayez de démarrer. Un nouveau kernel accompagné d’un initramfs absent ou mal généré peut expliquer pourquoi l’ancien noyau fonctionne alors que le nouveau provoque le Kernel Panic.
Si Linux ne démarre plus du tout
Si aucun noyau ou mode de récupération ne permet de démarrer, utilisez un Live USB Linux. Vous pourrez monter l’installation existante, entrer dans le système avec chroot, puis reconstruire l’initramfs et mettre à jour GRUB.
Le principe est alors : Live USB → monter Linux → chroot → reconstruire l’initramfs → mettre à jour GRUB
Inutile de détailler ici toute la procédure chroot, puisqu’elle est déjà expliquée dans le guide dédié.
Si l’erreur persiste
Si l’initramfs a été correctement reconstruit mais que le noyau affiche toujours unknown-block(0,0), vérifiez ensuite que l’image contient bien les pilotes nécessaires au contrôleur de stockage.
Si le SSD ou le disque est détecté mais que la partition racine ne peut toujours pas être montée, recherchez plutôt un système de fichiers endommagé ou un problème avec le périphérique de stockage.
Vérifier et réparer le système de fichiers
Si le noyau détecte correctement la partition racine mais n’arrive pas à monter son système de fichiers, une corruption de celui-ci peut provoquer l’erreur « VFS: Unable to mount root fs ».
Ce problème peut notamment apparaître après un arrêt brutal du PC, une coupure de courant, un plantage pendant une écriture ou des erreurs provenant du SSD ou du disque dur.
Recherchez dans les messages précédant le Kernel Panic des indications comme :
Sous Linux, la commande fsck permet de vérifier et, selon le système de fichiers, de réparer les erreurs détectées. fsck sert en réalité d’interface aux outils adaptés au type de système de fichiers concerné.
Commencez par identifier la partition et son système de fichiers :
lsblk -f
Par exemple, si la partition racine utilise ext4 et correspond à /dev/nvme0n1p2, vous pouvez effectuer sa vérification depuis un Live USB ou un environnement de récupération, une fois la partition démontée :
sudo fsck /dev/nvme0n1p2
Selon les erreurs rencontrées, l’outil peut proposer de réparer les incohérences détectées.
Attention : n’effectuez pas une réparation fsck sur la partition racine montée en lecture/écriture. Pour les systèmes de fichiers ext2/ext3/ext4 notamment, e2fsck déconseille explicitement la vérification d’un système de fichiers monté. Utilisez de préférence le mode de récupération ou un Live USB.
Pour connaître les différentes options et méthodes de réparation, consultez notre guide complet :
Enfin notez que vous pouvez effectuer un fsck depuis les options de récupération :
Attention au type de système de fichiers
Tous les systèmes de fichiers ne se réparent pas de la même manière. Pour XFS, par exemple, fsck.xfs ne réalise pas directement la réparation : l’outil dédié est xfs_repair.
Btrfs utilise également ses propres outils de vérification et de réparation ; fsck.btrfs n’effectue pas une vérification classique.
Il est donc important d’identifier le système de fichiers avec lsblk -f avant de lancer une réparation.
Si les erreurs réapparaissent après avoir réparé le système de fichiers, ne vous contentez pas de relancer régulièrement fsck. Des corruptions répétées peuvent être le symptôme d’un SSD ou disque défaillant, d’erreurs d’entrée/sortie ou d’une autre instabilité matérielle.
Dans ce cas, l’étape suivante consiste à vérifier l’état du périphérique de stockage.
Vérifier le SSD ou le disque dur
Si l’erreur « VFS: Unable to mount root fs » s’accompagne d’erreurs d’entrée/sortie ou si le système de fichiers se corrompt régulièrement, vérifiez également l’état du SSD ou du disque dur.
Un périphérique de stockage défaillant peut empêcher le noyau de lire correctement la partition racine. Dans ce cas, reconstruire l’initramfs ou réparer le système de fichiers peut ne résoudre le problème que temporairement.
Rechercher les erreurs de stockage
Depuis le mode de récupération ou un Live USB, consultez les messages du noyau :
lsblk permet d’obtenir les informations sur les périphériques bloc détectés par Linux.
Repérez le SSD ou disque contenant la partition racine avant de poursuivre les vérifications.
Vérifier les données SMART
Les SSD et disques compatibles exposent généralement des informations S.M.A.R.T. permettant de surveiller leur état de santé, les erreurs enregistrées et différents indicateurs d’usure. Sous Linux, ces données peuvent notamment être interrogées avec smartctl, fourni par smartmontools.
Comme tu as déjà un guide complet consacré à cette vérification, je ne détaillerais pas ici toutes les commandes et attributs SMART :
L’objectif est notamment de rechercher des erreurs matérielles, des secteurs problématiques, une usure anormale du SSD ou des erreurs enregistrées par le contrôleur.
Si le stockage présente des signes de défaillance, sauvegardez vos données importantes avant d’effectuer des réparations répétées du système de fichiers.
À l’inverse, si le disque est en bon état, que la partition est correctement détectée et que son système de fichiers ne présente pas d’erreur, revenez plutôt aux pistes liées à l’initramfs, aux pilotes de stockage ou à la configuration du démarrage.
Vérifier les pilotes de stockage dans l’initramfs
Pour monter la partition racine /, le noyau doit pouvoir détecter le SSD ou le disque dès les premières étapes du démarrage. Les pilotes nécessaires au contrôleur de stockage doivent donc être disponibles dans l’initramfs.
Si un module NVMe, SATA, RAID ou correspondant à un contrôleur particulier est absent, Linux peut ne pas détecter le périphérique contenant la partition racine et afficher notamment :
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Cette piste est particulièrement intéressante lorsque le problème apparaît après une mise à jour du noyau, une reconstruction de l’initramfs ou une modification de la configuration du stockage.
Identifier le pilote de stockage utilisé
Si vous pouvez démarrer avec un ancien noyau fonctionnel, identifiez le contrôleur de stockage et le pilote utilisé :
Vous pouvez également rechercher les principaux modules de stockage chargés :
lsmod | grep -Ei "nvme|ahci|ata|scsi|raid"
Selon le matériel, vous pouvez par exemple rencontrer nvme, nvme_core, ahci ou libahci. Le module réellement nécessaire dépend toutefois du contrôleur présent sur le PC.
Vérifier que le module est présent dans l’initramfs
Sur Ubuntu et Debian, affichez d’abord les images disponibles :
ls -lh /boot/initrd.img-*
Puis recherchez le pilote dans l’initramfs correspondant au noyau qui ne démarre pas. Par exemple pour NVMe :
Si l’ancien noyau démarre correctement, comparer son initramfs avec celui du nouveau kernel peut aider à repérer un module absent dans l’image problématique.
Que faire si le pilote est absent ?
Si vous avez identifié avec certitude un module indispensable absent de l’initramfs, commencez par reconstruire l’image comme expliqué dans la section précédente.
Sur Ubuntu/Debian :
sudo update-initramfs -u -k all
sudo update-grub
Si le module reste absent, il est possible de forcer son inclusion dans l’initramfs. Cette opération dépend toutefois de la distribution et ne doit être effectuée qu’après avoir identifié précisément le pilote nécessaire.
Cas des volumes RAID, LVM ou chiffrés
La détection du disque ne suffit pas toujours. Si la partition racine se trouve sur LVM, un RAID ou un volume chiffré, l’initramfs doit également disposer des composants nécessaires pour assembler ou déverrouiller le volume avant de pouvoir monter /.
Ainsi, si le SSD apparaît correctement depuis un Live USB mais que Linux affiche toujours unknown-block au démarrage, vérifiez la configuration de l’initramfs et la manière dont la partition racine est construite.
Si les pilotes nécessaires sont bien présents, poursuivez plutôt le diagnostic du côté de l’UUID, de GRUB, du système de fichiers ou du stockage lui-même.
Réparer depuis un Live USB Linux
Si Linux ne démarre avec aucun noyau disponible ni en mode de récupération, utilisez un Live USB Linux. Celui-ci permet d’accéder au système installé depuis un environnement indépendant afin d’effectuer les réparations.
Commencez par identifier et monter la partition racine comme expliqué dans la section « Vérifier la partition racine et son UUID ». Profitez également du Live USB pour sauvegarder vos fichiers importants si vous suspectez une corruption du système de fichiers ou un problème de stockage.
Une fois la partition montée, vous pouvez utiliser chroot afin d’exécuter les commandes dans l’environnement du Linux installé.
Réparer l’installation avec chroot
Pour reconstruire l’initramfs ou corriger la configuration de démarrage, vous pouvez ensuite utiliser chroot afin d’exécuter les commandes dans l’environnement du Linux installé.
Cette opération nécessite notamment de monter certains systèmes virtuels et, selon la configuration, les partitions /boot et EFI. La procédure étant identique à celle utilisée pour réparer GRUB depuis un Live USB, suivez le guide dédié :
mkdir -p /tmp/chroot
sudo mount -t ext4 /dev/sda2 /tmp/chroot
sudo mount --bind /proc /tmp/chroot/proc
sudo mount --bind /dev /tmp/chroot/dev
sudo mount --bind /sys /tmp/chroot/sys
sudo chroot /tmp/chroot/
Une fois dans le chroot, sur Ubuntu ou Debian, reconstruisez l’initramfs :
update-initramfs -u -k all
Puis régénérez la configuration de GRUB :
update-grub
Sur Fedora, RHEL ou une distribution utilisant dracut, reconstruisez l’initramfs avec l’outil correspondant à votre distribution.
Quittez ensuite le chroot, démontez proprement les partitions puis redémarrez le PC sans le Live USB.
Si l’erreur « VFS: Unable to mount root fs » persiste malgré un UUID correct et un initramfs reconstruit, poursuivez les vérifications du côté des pilotes de stockage, du système de fichiers et de l’état du SSD ou du disque dur.
Que faire si l’erreur persiste ?
Si Linux affiche toujours « VFS: Unable to mount root fs » après les vérifications précédentes, évitez de multiplier les modifications au hasard. À ce stade, il faut déterminer précisément à quelle étape l’accès à la partition racine échoue.
Vérifiez en priorité les points suivants :
Essayez un ancien noyau Linux depuis GRUB.
Vérifiez que la partition racine est bien détectée avec lsblk -f et blkid.
Comparez son UUID avec celui utilisé dans /etc/fstab et le paramètre root= de GRUB.
Reconstruisez l’initramfs et vérifiez qu’il contient les pilotes de stockage nécessaires.
Contrôlez et réparez le système de fichiers si des erreurs sont détectées.
Vérifiez l’état de santé du SSD ou du disque dur.
Recherchez les messages I/O error, nvme, ata, EXT4-fs error ou similaires avant le Kernel Panic.
Utilisez un Live USB Linux lorsque le système installé ne permet plus d’effectuer ces opérations.
Le message unknown-block(...) peut également aider à orienter les recherches. Un unknown-block(0,0) suggère notamment que le noyau ne parvient pas à identifier correctement le périphérique racine, ce qui renforce les pistes liées à l’initramfs, au paramètre root= ou au pilote de stockage.
À l’inverse, si le périphérique est identifié mais que son système de fichiers ne peut pas être monté, concentrez davantage les vérifications sur la partition, le système de fichiers et l’état du stockage.
Sauvegarder les données avant d’aller plus loin
Si le SSD ou le disque présente des erreurs ou si le système de fichiers se corrompt régulièrement, sauvegardez vos fichiers importants avant de poursuivre les réparations.
Un Live USB permet généralement d’accéder à la partition Linux et de copier les données vers un autre support, à condition que le stockage reste suffisamment fonctionnel.
Évitez notamment d’enchaîner les réparations du système de fichiers sur un disque présentant des erreurs matérielles : la priorité devient alors la récupération des données et le remplacement du périphérique défaillant.
Une réinstallation peut être envisagée si le stockage est sain mais que le système reste impossible à démarrer malgré :
UUID correct → système de fichiers sain → initramfs reconstruit → pilotes présents → GRUB corrigé.
Elle doit toutefois rester une solution de dernier recours. L’erreur « Unable to mount root fs » possède souvent une cause précise qu’il est possible de corriger sans réinstaller complètement Linux.
Si le problème s’accompagne d’autres Kernel Panic, de blocages ou d’erreurs matérielles sans rapport apparent, élargissez également le diagnostic au reste du PC.
Un Kernel Panic est l’une des erreurs les plus critiques que peut rencontrer un système Linux. Il se produit lorsque le noyau détecte une situation suffisamment grave pour qu’il ne puisse plus continuer à fonctionner normalement. Le système peut alors se figer complètement, afficher une série de messages techniques ou redémarrer automatiquement.
Identifier l’origine d’un Kernel Panic nécessite donc d’examiner les messages du noyau et les événements ayant précédé le plantage. Des outils comme journalctl, dmesg, lsmod ou kdump permettent de récupérer des informations précieuses et d’orienter le diagnostic vers un problème logiciel ou matériel.
Dans ce guide, découvrez comment diagnostiquer un Kernel Panic sous Linux, récupérer et analyser les journaux, identifier un pilote ou module responsable, vérifier le matériel et réparer un système qui ne démarre plus après le plantage.
Un Kernel Panic est une erreur critique du noyau Linux qui se produit lorsque celui-ci rencontre une situation suffisamment grave pour qu’il ne puisse plus continuer à fonctionner normalement.
Le noyau (kernel) constitue le cœur du système Linux. Il assure notamment la communication avec le matériel, la gestion de la mémoire, des processus, des pilotes et des systèmes de fichiers. Lorsqu’une erreur irrécupérable survient à ce niveau, poursuivre l’exécution pourrait provoquer une corruption des données ou aggraver le problème. Le noyau peut alors déclencher volontairement un panic et arrêter le système.
Selon la configuration de Linux, le PC peut alors :
Se figer complètement avec un message d’erreur à l’écran.
Afficher une série d’informations techniques et une Call Trace.
Redémarrer automatiquement après quelques secondes.
Rester bloqué jusqu’à un redémarrage manuel.
Un Kernel Panic est donc différent du simple plantage d’une application. Si Firefox, un jeu ou un autre programme se ferme brutalement, le noyau Linux continue généralement de fonctionner. Lors d’un Kernel Panic, c’est au contraire le fonctionnement du système lui-même qui est compromis.
Kernel Panic, Kernel Oops ou blocage : quelles différences ?
Tous les problèmes graves de Linux ne correspondent pas nécessairement à un Kernel Panic.
Un Kernel Oops indique qu’une erreur a été détectée dans le noyau. Linux enregistre des informations techniques sur l’incident et peut parfois continuer à fonctionner, même si le système peut ensuite devenir instable.
Un Kernel Panic est plus grave : le noyau considère qu’il n’est plus possible de poursuivre l’exécution de manière sûre.
Enfin, un freeze ou blocage de Linux peut avoir de nombreuses autres origines : pilote graphique bloqué, manque de mémoire, problème matériel, stockage défaillant ou processus qui monopolise certaines ressources. Un écran figé ne signifie donc pas automatiquement qu’un Kernel Panic s’est produit.
Les messages affichés à l’écran ou enregistrés dans les journaux sont essentiels pour faire la différence. Des termes comme Kernel panic, Oops, BUG, Call Trace ou le nom d’un module noyau constituent alors des indices importants.
Dans la suite de ce guide, nous allons voir quelles sont les principales causes d’un Kernel Panic et comment récupérer ces informations afin d’identifier son origine.
Quelles sont les causes d’un Kernel Panic ?
Un Kernel Panic peut avoir une origine logicielle ou matérielle. Un pilote défectueux, un problème de mémoire RAM, une erreur de stockage ou encore une mise à jour du noyau peuvent provoquer une erreur suffisamment grave pour empêcher Linux de continuer à fonctionner normalement.
Image initramfs endommagée, pilote de stockage manquant
Kernel Panic principalement au démarrage
Matériel ou firmware
BIOS/UEFI, carte mère, alimentation, périphérique PCIe
Erreurs matérielles, comportement instable ou aléatoire
Pilote ou module du noyau défectueux
Les pilotes et modules du noyau sont une cause importante de Kernel Panic puisqu’ils s’exécutent directement dans l’espace noyau.
Un problème peut apparaître après la mise à jour d’un pilote graphique, l’installation d’un module tiers ou le passage à une nouvelle version du noyau Linux. Les pilotes NVIDIA, les modules DKMS ou certains pilotes de périphériques constituent par exemple des éléments à vérifier lorsqu’un Kernel Panic apparaît après une modification du système.
Le nom du module impliqué peut parfois apparaître dans la Call Trace ou dans les messages enregistrés avant le plantage.
Problème matériel ou instabilité du PC
Un Kernel Panic peut également être la conséquence d’une instabilité matérielle. La mémoire RAM est notamment à surveiller : une barrette défectueuse ou des paramètres XMP/EXPO trop agressifs peuvent provoquer des corruptions mémoire qui finissent par faire planter le noyau.
Le processeur peut également devenir instable à cause d’un overclocking, d’un undervolting trop important ou, dans certains cas, de températures excessives.
Si les Kernel Panic sont aléatoires, impliquent des modules différents ou apparaissent principalement sous forte charge, il est pertinent d’élargir le diagnostic au matériel.
Un SSD ou un disque dur défaillant peut provoquer des erreurs d’entrée/sortie (I/O) qui empêchent le noyau d’accéder correctement aux données nécessaires au fonctionnement du système.
Une corruption du système de fichiers peut également entraîner des problèmes graves, notamment lorsque la partition système devient inaccessible.
Des messages contenant I/O error, EXT4-fs error, BTRFS error, nvme ou encore des erreurs SATA constituent alors des pistes à examiner.
Mise à jour ou régression du noyau Linux
Enfin, un Kernel Panic peut apparaître après une mise à jour du noyau. Une nouvelle version peut introduire une régression ou révéler une incompatibilité avec un pilote ou un périphérique particulier.
Un indice particulièrement intéressant est donc la date d’apparition du problème. Si Linux fonctionnait normalement avant une mise à jour du kernel et que les Kernel Panic ont commencé immédiatement après, démarrer temporairement sur l’ancien noyau depuis GRUB constitue un excellent test.
L’identification de la cause repose toutefois rarement sur le seul message « Kernel Panic ». Il faut récupérer les journaux du noyau et les informations affichées au moment du plantage pour déterminer quel pilote, composant ou sous-système est réellement impliqué.
Comment récupérer les informations après un Kernel Panic ?
Pour déterminer l’origine d’un Kernel Panic, il faut récupérer les messages enregistrés par le noyau avant le plantage. Ils peuvent contenir le nom d’un pilote ou d’un module, une erreur mémoire, une erreur d’entrée/sortie ou encore une Call Trace permettant d’orienter le diagnostic.
Lorsque Linux a redémarré, journalctl est généralement le premier outil à utiliser.
Consulter les messages du noyau du démarrage précédent
Sur une distribution utilisant systemd, exécutez :
journalctl -k -b -1
L’option -k limite l’affichage aux messages du noyau, tandis que -b -1 demande les journaux correspondant au démarrage précédent.
Vous pouvez également afficher uniquement les erreurs :
Il est souvent utile d’examiner également les dernières lignes précédant le plantage, car l’erreur ayant déclenché le Kernel Panic peut apparaître avant le message final.
dmesg est surtout utile pour examiner le démarrage et la session en cours. Après un redémarrage consécutif à un Kernel Panic, journalctl -k -b -1 est généralement plus intéressant pour retrouver les événements du système précédent.
Que faire si le journal du démarrage précédent est vide ?
Les journaux ne sont pas toujours conservés après un redémarrage. Vous pouvez vérifier si les anciens boots sont disponibles avec :
journalctl --list-boots
Si seul le démarrage actuel apparaît, la journalisation persistante n’est probablement pas disponible ou les anciens journaux ont déjà été supprimés.
Dans ce cas, il peut être nécessaire de configurer la conservation persistante du journal systemd avant de reproduire le problème.
Il faut également garder à l’esprit qu’un Kernel Panic particulièrement brutal peut empêcher Linux d’écrire les derniers messages sur le disque. Le journal peut alors s’interrompre juste avant l’information la plus intéressante.
Pour les plantages difficiles à reproduire ou lorsque les journaux classiques ne suffisent pas, des mécanismes plus avancés comme kdump permettent de conserver un vidage mémoire du noyau afin d’effectuer une analyse plus approfondie.
Une fois les messages récupérés, l’étape suivante consiste à identifier les lignes réellement importantes dans le Kernel Panic et à interpréter la Call Trace.
Vérifier si un pilote ou module noyau est responsable
Les pilotes et modules du noyau sont une cause fréquente de Kernel Panic, car ils s’exécutent directement dans l’espace noyau. Un module défectueux, incompatible avec une nouvelle version du kernel ou mal compilé peut provoquer une erreur critique du système.
La première étape consiste à rechercher si un nom de module revient dans les journaux ou dans la Call Trace du Kernel Panic.
Vous pouvez par exemple filtrer les messages du démarrage précédent avec :
Si un nom de module apparaît régulièrement juste avant le plantage, notez-le pour poursuivre les vérifications.
Lister les modules noyau chargés
La commande suivante affiche les modules actuellement chargés :
lsmod
Vous pouvez rechercher un module précis avec :
lsmod | grep nom_module
Pour obtenir davantage d’informations :
modinfo nom_module
modinfo peut notamment afficher :
Le chemin du module.
Sa version.
Son auteur.
Les dépendances.
Les paramètres disponibles.
La version du noyau pour laquelle il a été compilé selon le module.
Ces informations sont utiles lorsqu’un pilote tiers ou un module DKMS est suspecté.
Vérifier les modules DKMS
Certains pilotes tiers sont reconstruits automatiquement à chaque mise à jour du noyau grâce à DKMS, notamment certains pilotes graphiques ou pilotes matériels additionnels.
Pour afficher les modules DKMS installés :
dkms status
Si un Kernel Panic apparaît juste après une mise à jour du noyau, vérifiez que les modules nécessaires ont bien été recompilés pour la nouvelle version et qu’aucune erreur DKMS n’est présente.
Vous pouvez aussi comparer la version du noyau actuellement utilisée :
uname -r
avec les informations retournées par modinfo.
Rechercher les erreurs liées à un pilote précis
Si vous connaissez le nom du module suspect, filtrez directement les journaux :
Désactiver temporairement un module pour confirmer le diagnostic
Si un module non essentiel semble responsable, vous pouvez tenter de le désactiver temporairement afin de vérifier si les Kernel Panic disparaissent.
Pour retirer un module chargé :
sudo modprobe -r nom_module
Cette commande ne fonctionne que si le module n’est pas utilisé par un périphérique ou un autre module.
Pour empêcher son chargement au prochain démarrage, il est également possible de le placer temporairement dans une blacklist modprobe. Cette méthode doit toutefois être utilisée avec prudence : bloquer un pilote graphique, réseau ou de stockage indispensable peut empêcher le système de fonctionner correctement.
L’objectif n’est donc pas de désactiver au hasard les modules présents dans la Call Trace, mais de vérifier si le même pilote revient systématiquement dans plusieurs Kernel Panic.
Si le problème est apparu récemment, demandez-vous ce qui a changé juste avant :
Mise à jour du noyau Linux.
Mise à jour du pilote NVIDIA ou AMD.
Installation d’un nouveau module DKMS.
Mise à jour du BIOS/UEFI.
Ajout d’un périphérique PCIe, USB ou de stockage.
Modification d’un paramètre du kernel ou du démarrage.
Lorsqu’un Kernel Panic apparaît juste après une mise à jour du noyau, un test très efficace consiste à redémarrer sur l’ancienne version du kernel depuis GRUB. Si les plantages disparaissent, cela renforce fortement l’hypothèse d’une régression du noyau ou d’une incompatibilité avec un pilote/module.
Enfin, gardez à l’esprit qu’un module cité dans une Call Trace n’est pas automatiquement le responsable. Une corruption mémoire ou une instabilité matérielle peut provoquer le crash d’un pilote parfaitement sain. Il faut donc toujours croiser cette piste avec les autres symptômes et les tests matériels.
Analyser un Kernel Panic avec kdump
Lorsque les journaux journalctl et dmesg ne permettent pas d’identifier l’origine d’un Kernel Panic, les utilisateurs avancés et administrateurs système peuvent utiliser kdump pour effectuer une analyse plus approfondie.
Kdump utilise kexec pour démarrer un second noyau, appelé noyau de capture, après le plantage. Une partie de la mémoire est réservée à l’avance afin que ce noyau puisse récupérer l’état mémoire du système qui vient de planter et l’enregistrer dans un fichier vmcore.
Le principe est le suivant : Kernel Panic → noyau de capture → création du vmcore → analyse du crash
Le fichier vmcore peut ensuite être analysé avec des outils spécialisés comme crash, en utilisant les symboles de débogage correspondant au noyau ayant planté. Cette analyse permet notamment d’examiner les messages du noyau, la pile d’appels, les processus et les modules présents au moment du crash.
La mise en place et surtout l’analyse d’un vmcore restent toutefois des opérations techniques destinées principalement aux administrateurs système et au débogage du noyau. Pour un PC personnel, commencez par journalctl, les messages du noyau, la vérification des pilotes/modules et le diagnostic matériel.
Que faire si Linux ne démarre plus après un Kernel Panic ?
Si Linux ne démarre plus après un Kernel Panic, le problème peut venir du noyau récemment installé, d’un pilote/module incompatible, de l’initramfs, du système de fichiers ou d’un problème matériel.
L’objectif est d’abord de retrouver un système démarrable, puis d’analyser ce qui a changé juste avant l’apparition du problème.
Démarrer sur un ancien noyau depuis GRUB
Si les Kernel Panic ont commencé après une mise à jour du noyau, essayez en priorité de démarrer sur une version précédente.
Depuis le menu GRUB :
Ouvrez Options avancées pour Ubuntu/Debian ou l’entrée équivalente de votre distribution.
Sélectionnez un ancien noyau Linux.
Démarrez normalement.
Si le système démarre correctement avec l’ancien kernel, cela oriente fortement vers une régression du noyau ou un problème de pilote/module compatible uniquement avec certaines versions.
Vous pouvez vérifier la version utilisée avec :
uname -r
Utiliser le mode de récupération
Si un ancien noyau ne suffit pas, essayez le mode Recovery / dépannage proposé dans GRUB.
Selon la distribution, ce mode permet notamment de :
Ouvrir un shell root.
Vérifier le système de fichiers.
Réparer certains paquets.
Recréer l’initramfs.
Désactiver temporairement un pilote ou module problématique.
Il peut être utile lorsque le Kernel Panic survient très tôt pendant le démarrage.
Vérifier ou reconstruire l’initramfs
Un initramfs endommagé ou incomplet peut empêcher le noyau de charger les pilotes nécessaires au démarrage, notamment ceux liés au stockage.
Sur Debian/Ubuntu, vous pouvez reconstruire l’initramfs avec :
sudo update-initramfs -u -k all
Puis mettre à jour GRUB :
sudo update-grub
Sur d’autres distributions, la commande peut différer, par exemple avec dracut.
Démarrer depuis un Live USB
Si aucun noyau installé ne permet de démarrer, utilisez un Live USB Linux.
Depuis le système Live, vous pouvez :
Accéder aux fichiers importants et effectuer une sauvegarde.
Monter la partition Linux.
Vérifier le système de fichiers.
Examiner les journaux présents sur le disque.
Réparer le chargeur d’amorçage.
Réinstaller un noyau ou reconstruire l’initramfs.
C’est également une bonne méthode pour déterminer si le problème vient du système installé ou d’une panne matérielle plus générale.
Vérifier le système de fichiers et le stockage
Si le Kernel Panic est associé à des erreurs de lecture, de montage ou d’entrée/sortie, vérifiez le stockage avant d’insister sur les réparations logicielles.
Vous pouvez rechercher des erreurs dans les journaux avec des termes comme :
Un système de fichiers endommagé peut parfois être réparé avec fsck, à condition de ne pas lancer la vérification sur une partition montée en écriture.
Profitez également du Live USB pour vérifier l’état SMART du SSD ou du disque si une défaillance matérielle est suspectée.
Si les journaux ou la Call Trace pointent régulièrement vers un module noyau précis, il peut être utile de désactiver temporairement ce module afin de vérifier si Linux démarre à nouveau.
Cette opération est surtout pertinente pour les pilotes graphiques, Wi-Fi ou modules tiers. Évitez toutefois de blacklister au hasard un pilote lié au stockage ou à un composant indispensable au démarrage.
En dernier recours : sauvegarder puis réparer ou réinstaller
Si Linux reste impossible à démarrer malgré un ancien noyau, la reconstruction de l’initramfs et la vérification du stockage, sauvegardez d’abord vos données depuis un Live USB.
Vous pourrez ensuite tenter une réparation plus complète du système ou, si la corruption est importante, procéder à une réinstallation.
Avant d’en arriver là, vérifiez cependant que le problème n’est pas matériel. Des Kernel Panic répétés avec des messages différents peuvent être provoqués par une RAM instable, un SSD défaillant, un CPU instable ou un autre composant matériel.
Le guide Kernel Panic pourrait n’en donner qu’une explication de 200 mots + lien vers ce futur guide.
Kernel panic – not syncing: Attempted to kill init!
Le message Kernel panic - not syncing: Attempted to kill init! apparaît lorsque le processus init, généralement le processus PID 1, s’arrête ou rencontre une erreur qui l’empêche de poursuivre son fonctionnement.
Ce processus joue un rôle essentiel : il constitue le premier processus lancé en espace utilisateur et permet ensuite d’initialiser le reste du système. S’il disparaît, Linux ne peut normalement plus poursuivre son fonctionnement et déclenche un Kernel Panic.
Cette erreur peut notamment être liée à :
Un initramfs endommagé ou incomplet.
Un problème avec systemd ou le programme utilisé comme init.
Une corruption du système de fichiers racine.
Des bibliothèques ou fichiers système manquants ou corrompus.
Une mise à jour interrompue ou défectueuse.
Une erreur de mémoire ou une instabilité matérielle provoquant le crash du processus init.
Si le problème apparaît au démarrage, essayez d’abord de lancer un ancien noyau depuis GRUB ou le mode de récupération. Vous pouvez ensuite vérifier le système de fichiers, reconstruire l’initramfs et contrôler les fichiers système.
Il est également important d’examiner les lignes affichées juste avant Attempted to kill init! : ce message indique la conséquence finale du problème, mais pas nécessairement sa cause initiale.
Kernel panic – not syncing: Fatal exception
Le message Kernel panic - not syncing: Fatal exception indique qu’une exception suffisamment grave s’est produite dans le noyau pour empêcher Linux de poursuivre son fonctionnement en toute sécurité.
Contrairement à une erreur très spécifique comme VFS: Unable to mount root fs, le message Fatal exception ne permet généralement pas à lui seul d’identifier la cause.
Il faut donc examiner les informations qui le précèdent, notamment :
La Call Trace.
Le nom d’un pilote ou module noyau.
Les éventuels messages Oops ou BUG.
Le processus et le CPU concernés.
Les erreurs mémoire ou matérielles précédant le panic.
Les modules éventuellement indiqués comme chargés ou impliqués.
Une Fatal exception peut notamment provenir d’un bug du noyau, d’un pilote défectueux, d’un module tiers ou d’une corruption mémoire provoquée par une instabilité matérielle.
Après le redémarrage, consultez en priorité les messages du noyau du démarrage précédent :
journalctl -k -b -1
Si plusieurs Kernel Panic présentent des Call Trace différentes et impliquent des modules sans rapport entre eux, élargissez également les vérifications à la RAM, au processeur et au matériel.
Kernel Panic après une mise à jour du noyau
Si les Kernel Panic commencent immédiatement après une mise à jour du noyau Linux, la nouvelle version du kernel constitue une piste importante.
Le problème ne vient toutefois pas nécessairement du noyau lui-même. Une mise à jour peut également révéler une incompatibilité avec un pilote, un module DKMS, l’initramfs ou un périphérique matériel.
Le test le plus simple consiste à redémarrer le PC et à sélectionner l’ancienne version du noyau depuis les options avancées de GRUB.
Si Linux fonctionne normalement avec l’ancien kernel, vérifiez ensuite :
Les éventuelles erreurs connues avec la nouvelle version du noyau.
Les modules DKMS avec dkms status.
Les pilotes graphiques ou autres pilotes tiers récemment mis à jour.
La bonne génération de l’initramfs.
Les journaux du démarrage ayant échoué.
Les paramètres du noyau éventuellement modifiés.
Vous pouvez connaître le noyau actuellement utilisé avec :
uname -r
et afficher les noyaux disponibles dans /boot :
ls -lh /boot
Si l’ancien noyau fonctionne correctement, conservez-le temporairement comme solution de secours plutôt que de supprimer immédiatement les autres versions. Cela permet de continuer à utiliser Linux pendant que vous recherchez s’il s’agit d’une régression du kernel ou d’une incompatibilité avec un module.
Sur les distributions Linux modernes utilisant systemd, les services système sont principalement administrés avec la commande systemctl. Serveur Web Nginx ou Apache, PHP-FPM, SSH, MariaDB/MySQL ou encore services réseau : lorsqu’un service ne démarre plus, s’arrête brutalement ou passe dans l’état failed, systemctl permet d’effectuer les premières vérifications.
Pour trouver pourquoi un service Linux est en échec, il faut généralement compléter le diagnostic avec journalctl, qui permet de consulter ses journaux et de retrouver les erreurs de configuration, problèmes de permissions, dépendances manquantes, ports déjà utilisés, timeouts ou crashs d’application.
Dans ce guide, découvrez comment vérifier et dépanner un service sous Linux avec systemctl et journalctl : lister les services, identifier ceux en échec, consulter leur état et leurs logs, démarrer ou redémarrer un service, vérifier ses dépendances et son fichier unit systemd, puis résoudre les erreurs empêchant son démarrage.
Sur la plupart des distributions Linux récentes, les services sont gérés par systemd. La commande systemctl permet de les lister, vérifier leur état, les démarrer ou les arrêter et diagnostiquer les services qui rencontrent des erreurs.
Pour afficher les services actuellement chargés par systemd, utilisez :
systemctl list-units --type=service
La commande affiche notamment le nom du service, son état de chargement et son état d’exécution.
Colonne
Description
UNIT
Nom de l’unité systemd, par exemple nginx.service ou ssh.service
LOAD
Indique si le fichier de configuration du service a été correctement chargé
ACTIVE
État général du service : active, inactive, failed, etc.
SUB
État plus précis du service : running, exited, dead, failed, etc.
DESCRIPTION
Description du service
Par défaut, list-units affiche principalement les unités actuellement chargées. Pour afficher tous les services installés, y compris ceux qui ne sont pas actuellement actifs, utilisez plutôt :
systemctl list-unit-files --type=service
Cette commande permet également de connaître leur configuration au démarrage, avec des états tels que enabled, disabled, static ou masked.
Pour afficher uniquement les services actuellement actifs :
Enfin, si votre objectif est de rechercher directement les services rencontrant un problème, inutile de parcourir toute la liste. systemctl dispose d’une commande dédiée permettant d’afficher uniquement les unités en échec :
systemctl --failed
C’est cette commande qu’il est recommandé d’utiliser en premier lorsqu’un service ne fonctionne plus ou après un problème système.
Lorsqu’une application ne fonctionne plus ou qu’un serveur présente un dysfonctionnement, commencez par vérifier si systemd a détecté des services en échec.
La commande suivante affiche toutes les unités actuellement dans l’état failed :
systemctl --failed
Vous pouvez obtenir par exemple :
UNIT LOAD ACTIVE SUB DESCRIPTION
php8.4-fpm.service loaded failed failed The PHP 8.4 FastCGI Process Manager
Les colonnes ACTIVE et SUB indiquent ici que le service a échoué. Cela signifie que systemd a tenté de le démarrer ou de le maintenir en fonctionnement, mais qu’une erreur l’en a empêché.
Pour limiter la recherche aux services :
systemctl --failed --type=service
Vérifier un service en particulier
Si vous connaissez le nom du service en panne, affichez directement son état avec :
systemctl status nom-du-service
Par exemple :
systemctl status php8.4-fpm
ou :
systemctl status nginx
La sortie de systemctl status fournit plusieurs informations importantes :
Loaded : indique si l’unité systemd a été correctement chargée.
Active : indique si le service est actif, arrêté ou en échec.
Main PID : PID du processus principal lorsqu’il fonctionne.
Result : raison générale de l’échec.
Process / ExecStart : commande ayant été exécutée par systemd.
Les derniers messages du journal associés au service.
Vous pouvez par exemple rencontrer :
Active: failed (Result: exit-code)
Cela indique que le programme lancé par systemd s’est terminé avec un code de retour indiquant une erreur. Il faut alors rechercher le message qui explique pourquoi le programme s’est arrêté.
Comprendre l’état Active
Le champ Active permet de connaître rapidement la situation du service.
État
Signification
active (running)
Le service fonctionne normalement
active (exited)
La commande du service s’est terminée correctement, mais aucun processus ne reste actif. Cela peut être normal pour certains services
inactive (dead)
Le service n’est actuellement pas démarré
failed
Le service a tenté de fonctionner mais a rencontré une erreur
activating
Le service est en cours de démarrage
deactivating
Le service est en cours d’arrêt
Un état active (exited) n’est donc pas nécessairement une erreur. Certains services de type oneshot exécutent une tâche puis se terminent normalement.
Repérer le code d’erreur
Lorsqu’un service échoue, recherchez particulièrement les lignes Result, code et status.
Par exemple :
Active: failed (Result: exit-code)
puis :
code=exited, status=1/FAILURE
Cela signifie que le programme a été lancé mais s’est terminé avec un code d’erreur.
Vous pouvez également rencontrer :
Result: timeout : le service n’a pas terminé son démarrage ou son arrêt dans le délai prévu.
Result: signal : le processus a été terminé par un signal.
Result: core-dump : le processus a planté et généré un core dump.
Result: exit-code : le programme s’est terminé avec un code d’erreur.
Result: watchdog : le service n’a pas répondu au mécanisme watchdog dans le délai prévu.
Les dernières lignes affichées par systemctl status donnent souvent une première indication sur l’origine du problème. Toutefois, elles ne représentent qu’une partie des journaux.
Pour obtenir l’historique complet et déterminer pourquoi le service a échoué, l’étape suivante consiste à consulter ses logs avec journalctl -u.
Consulter les services qui ont échoué après le démarrage
Après un redémarrage, il peut être utile d’exécuter :
systemctl --failed
Un service secondaire en échec n’indique pas nécessairement un problème grave. En revanche, si un composant essentiel comme SSH, Nginx, Apache, PHP-FPM, MariaDB/MySQL ou un service réseau apparaît dans cette liste, son échec peut expliquer directement le dysfonctionnement rencontré.
Ne redémarrez pas systématiquement le service immédiatement. Commencez plutôt par consulter son état et ses journaux, afin de conserver les informations permettant d’identifier la cause de l’échec.
La prochaine étape consiste donc à utiliser systemctl status, puis journalctl -u pour déterminer précisément pourquoi le service ne démarre plus.
Consulter les logs d’un service
La commande journalctl permet de consulter les journaux enregistrés par systemd pour un service particulier. C’est l’une des commandes les plus importantes pour comprendre pourquoi un service ne démarre pas, s’arrête brutalement ou rencontre des erreurs.
Pour afficher les journaux d’un service, utilisez l’option -u suivie du nom de l’unité :
sudo journalctl -u nom-du-service
Par exemple, pour Nginx :
sudo journalctl -u nginx
Ou pour PHP-FPM :
sudo journalctl -u php8.4-fpm
Afficher les derniers événements
Lorsque le journal contient beaucoup d’entrées, utilisez l’option -e pour vous positionner directement à la fin :
sudo journalctl -u nginx -e
Vous pouvez également afficher uniquement les dernières lignes :
sudo journalctl -u nginx -n 50
Cela permet de retrouver rapidement les événements enregistrés juste avant l’arrêt ou l’échec du service.
Cette méthode est particulièrement utile lorsque vous connaissez approximativement l’heure à laquelle le service est tombé en panne.
Suivre les logs en temps réel
Pour afficher les nouveaux événements au fur et à mesure qu’ils sont générés, utilisez l’option -f :
sudo journalctl -u nginx -f
Laissez cette commande ouverte puis, dans un autre terminal, redémarrez le service ou reproduisez le problème. Vous pourrez ainsi observer immédiatement les erreurs générées.
Utilisez Ctrl + C pour arrêter le suivi.
Rechercher les erreurs importantes
Portez notamment attention aux messages contenant :
failed ou failure : échec d’une opération.
permission denied : problème de permissions.
address already in use : un autre processus utilise déjà le port nécessaire.
out of memory ou killed process : manque de mémoire.
segfault ou core dumped : plantage du programme.
timeout : délai d’attente dépassé.
dependency failed : une dépendance nécessaire au service est en échec.
configuration error ou syntax error : erreur dans un fichier de configuration.
Il est également important de vérifier les logs propres à l’application. journalctl peut indiquer qu’un service a échoué sans contenir tous les détails. Nginx, Apache, PHP-FPM, MariaDB ou d’autres applications peuvent écrire des informations supplémentaires dans leurs propres fichiers sous /var/log/.
Après avoir identifié le message d’erreur, évitez de redémarrer le service en boucle. Vérifiez d’abord sa configuration, ses permissions, ses ports et ses dépendances afin de corriger la cause réelle de l’échec.
Activer ou désactiver un service au démarrage
Par défaut, tous les services Linux ne sont pas automatiquement lancés au démarrage du système. Avec systemd, la commande systemctl permet de vérifier si un service est configuré pour démarrer automatiquement, puis d’activer ou de désactiver ce comportement.
Pour vérifier l’état d’un service au démarrage :
systemctl is-enabled nom-du-service
Par exemple :
systemctl is-enabled nginx
La commande peut notamment retourner :
enabled : le service est activé au démarrage.
disabled : le service existe mais n’est pas activé automatiquement.
static : le service ne peut pas être activé directement et est généralement lancé comme dépendance d’une autre unité.
masked : le service est complètement bloqué et ne peut pas être démarré normalement.
Activer un service au démarrage
Pour configurer un service afin qu’il démarre automatiquement avec Linux :
sudo systemctl enable nom-du-service
Par exemple :
sudo systemctl enable nginx
La commande enablen’a pas pour rôle de démarrer immédiatement le service. Elle configure systemd afin qu’il soit lancé automatiquement lors des prochains démarrages.
Si vous souhaitez à la fois activer et démarrer immédiatement le service :
sudo systemctl enable --now nginx
Vous pouvez ensuite vérifier son état :
systemctl status nginx
Désactiver un service au démarrage
Pour empêcher le démarrage automatique d’un service :
sudo systemctl disable nom-du-service
Par exemple :
sudo systemctl disable nginx
Le service ne sera plus lancé automatiquement au prochain démarrage, mais il n’est pas arrêté immédiatement.
Pour le désactiver et l’arrêter dans la même opération :
sudo systemctl disable --now nginx
Ne pas confondre disable et mask
La commande disable empêche simplement le démarrage automatique. Le service peut toujours être lancé manuellement avec :
sudo systemctl start nginx
À l’inverse, mask bloque complètement son démarrage :
sudo systemctl mask nom-du-service
Une tentative de démarrage retourne alors une erreur indiquant que l’unité est masked.
Pour lever ce blocage :
sudo systemctl unmask nom-du-service
Utilisez mask avec prudence, car un autre service peut dépendre de l’unité que vous bloquez. Pour un simple dépannage ou pour empêcher un service de démarrer avec Linux, disable est généralement suffisant.
Vérifier pourquoi un service ne démarre pas
Lorsqu’un service refuse de démarrer, évitez de le relancer plusieurs fois sans examiner la cause de l’échec. systemctl et journalctl permettent généralement d’obtenir les premières informations nécessaires au diagnostic.
Commencez par afficher l’état du service :
systemctl status nom-du-service
Par exemple :
systemctl status nginx
Examinez particulièrement les lignes Active, Result, ExecStart et les derniers messages affichés. Un état tel que :
Active: failed (Result: exit-code)
indique que le programme a bien été lancé par systemd, mais qu’il s’est terminé avec une erreur.
Consultez ensuite les journaux complets du service :
sudo journalctl -u nom-du-service -e
Pour afficher les événements du démarrage actuel :
sudo journalctl -u nom-du-service -b
Les messages d’erreur permettent généralement de déterminer dans quelle direction poursuivre le diagnostic.
Message ou symptôme
Cause probable
Vérification
Permission denied
Droits incorrects sur un fichier, répertoire ou socket
Vérifier le propriétaire et les permissions avec ls -l ou namei -l
Address already in use
Le port utilisé par le service est déjà occupé
Identifier le processus avec ss -lntup
No such file or directory
Fichier de configuration, exécutable ou autre fichier nécessaire absent
Vérifier les chemins indiqués dans les logs
Configuration error / Syntax error
Erreur dans un fichier de configuration
Utiliser l’outil de validation fourni par l’application
Dependency failed
Un service ou une unité nécessaire est en échec
Examiner les dépendances avec systemctl list-dependencies
Failed with result ‘exit-code’
Le programme s’est terminé avec un code d’erreur
Examiner systemctl status et journalctl -u
Failed with result ‘timeout’
Le service n’a pas démarré dans le délai prévu
Rechercher un blocage, une dépendance ou une ressource inaccessible
Start request repeated too quickly
Le service plante immédiatement et systemd a cessé de tenter de le redémarrer
Corriger l’erreur initiale puis utiliser systemctl reset-failed
Out of memory / Killed process
Processus arrêté à cause d’un manque de mémoire
Vérifier la RAM, le swap et l’OOM Killer
Segmentation fault / core dumped
Le programme a planté
Examiner les journaux et utiliser coredumpctl
Vérifier si un port est déjà utilisé
Pour un serveur Web, une base de données, SSH ou tout autre service réseau, vérifiez que le port nécessaire n’est pas déjà occupé :
sudo ss -lntup
Par exemple, pour rechercher le processus utilisant le port 80 :
sudo ss -lntp | grep ':80 '
Si un autre programme écoute déjà sur ce port, le nouveau service peut échouer avec une erreur Address already in use.
Vérifier les permissions
Une erreur Permission denied peut provenir des droits d’un fichier de configuration, d’un répertoire, d’un certificat, d’un socket ou d’un fichier de log.
Commencez par vérifier les permissions :
ls -l /chemin/vers/fichier
Pour contrôler également les permissions de chaque répertoire constituant le chemin :
namei -l /chemin/vers/fichier
Cette dernière commande est particulièrement pratique lorsqu’un service possède les droits sur le fichier lui-même mais ne peut pas traverser l’un des répertoires parents.
Rechercher un manque de mémoire ou un crash
Si le processus disparaît immédiatement, recherchez une intervention de l’OOM Killer :
En présence d’un segfault ou d’un core dump, vérifiez également :
coredumpctl list
Puis affichez les informations du crash concerné avec :
coredumpctl info
Enfin, lorsqu’un service refuse de démarrer après une modification de sa configuration, vérifiez toujours la syntaxe avant de le redémarrer. De nombreux logiciels fournissent leur propre commande de validation, ce qui permet souvent d’identifier immédiatement la ligne ou le fichier responsable de l’erreur.
Vérifier la configuration avant de redémarrer un service
Lorsqu’un service ne fonctionne plus après la modification d’un fichier de configuration, vérifiez sa syntaxe avant de le redémarrer. De nombreux logiciels Linux disposent d’une commande permettant de valider leur configuration sans interrompre le service actuellement en cours d’exécution.
Cette précaution est particulièrement importante sur un serveur distant : une simple erreur de syntaxe dans Nginx, Apache ou SSH peut empêcher le service de redémarrer et rendre le serveur ou un site inaccessible.
Voici quelques commandes courantes :
Service
Commande de vérification
Nginx
sudo nginx -t
Apache (Debian/Ubuntu)
sudo apache2ctl configtest
Apache (RHEL/Fedora)
sudo httpd -t
PHP-FPM
sudo php-fpm -t ou la commande correspondant à la version installée
OpenSSH
sudo sshd -t
Postfix
sudo postfix check
Samba
sudo testparm
Par exemple, après avoir modifié la configuration de Nginx :
sudo nginx -t
Si la configuration est correcte, vous obtenez notamment :
syntax is ok
test is successful
Vous pouvez alors recharger la configuration sans interrompre les connexions existantes :
sudo systemctl reload nginx
Si le test retourne une erreur, ne redémarrez pas le service immédiatement. Le message indique généralement le fichier et parfois la ligne contenant l’erreur. Corrigez-la, puis relancez le test.
Pour SSH, cette précaution est encore plus importante lorsque vous administrez un serveur à distance. Après avoir modifié sshd_config, vérifiez la configuration avec :
sudo sshd -t
Si aucune erreur n’est affichée, la syntaxe est valide. Gardez toutefois votre session SSH actuelle ouverte jusqu’à ce que vous ayez confirmé qu’une nouvelle connexion fonctionne correctement.
Enfin, lorsque le logiciel le permet, préférez systemctl reload à restart pour une simple modification de configuration. reload demande au service de relire sa configuration sans l’arrêter complètement, tandis que restart provoque un arrêt puis un nouveau démarrage du service.
Réinitialiser l’état failed d’un service
Lorsqu’un service échoue à plusieurs reprises, systemd peut conserver son état failed, même après avoir corrigé la cause du problème. Dans certains cas, systemd peut également cesser temporairement de tenter de démarrer le service lorsque celui-ci plante plusieurs fois en peu de temps.
Vous pouvez vérifier les services actuellement en échec avec :
systemctl --failed
Après avoir identifié et corrigé la cause du problème, réinitialisez l’état d’échec du service avec :
sudo systemctl reset-failed nom-du-service
Par exemple, pour Nginx :
sudo systemctl reset-failed nginx
Vous pouvez ensuite tenter de démarrer à nouveau le service :
sudo systemctl start nginx
Puis vérifiez son état :
systemctl status nginx
La commande reset-failed ne répare pas le service. Elle efface simplement l’état failed enregistré par systemd ainsi que certains compteurs associés aux échecs de démarrage. Il faut donc toujours corriger l’erreur initiale avant de l’utiliser.
Cette commande est notamment utile lorsque vous rencontrez un message de ce type :
Start request repeated too quickly
ou :
Failed with result 'start-limit-hit'
Cela signifie généralement que le service a échoué plusieurs fois dans un intervalle court et que systemd a atteint sa limite de tentatives de démarrage.
Dans ce cas :
Consultez d’abord les erreurs avec systemctl status nom-du-service.
Examinez les journaux avec journalctl -u nom-du-service.
Corrigez la configuration, les permissions ou le problème ayant provoqué les échecs.
Exécutez systemctl reset-failed nom-du-service.
Tentez à nouveau de démarrer le service.
Pour réinitialiser l’état failed de toutes les unités systemd en échec, vous pouvez utiliser :
sudo systemctl reset-failed
Cette dernière commande doit surtout être utilisée après avoir vérifié les unités concernées : effacer leur état failed sans comprendre pourquoi elles ont échoué peut masquer temporairement des problèmes qui nécessitent encore une intervention.
Vérifier les dépendances d’un service
Un service Linux peut refuser de démarrer alors que sa propre configuration est correcte parce qu’une unité dont il dépend est arrêtée ou en échec. Avec systemd, ces dépendances peuvent concerner un autre service, un point de montage, un socket, un périphérique ou une cible (target).
Pour afficher les dépendances d’un service, utilisez :
systemctl list-dependencies nom-du-service
Par exemple :
systemctl list-dependencies nginx
La commande affiche l’arborescence des unités nécessaires ou associées au fonctionnement du service.
Pour afficher également les dépendances qui ne sont pas actuellement actives :
systemctl list-dependencies --all nginx
Si une unité apparaît en échec, vérifiez son état :
systemctl status nom-de-unite
Puis consultez ses journaux :
sudo journalctl -u nom-de-unite -e
Rechercher les dépendances inverses
Il peut également être utile de déterminer quels services dépendent d’une unité donnée. Utilisez pour cela :
Cela permet d’identifier les unités susceptibles d’être affectées si MariaDB est arrêté ou en échec.
Comprendre les relations entre les unités
Pour obtenir des informations plus précises sur les dépendances déclarées par un service :
systemctl show nom-du-service
Vous pouvez notamment rechercher les propriétés :
Requires : unités nécessaires au fonctionnement du service.
Wants : dépendances souhaitées mais généralement moins strictes.
After et Before : ordre de démarrage entre les unités.
BindsTo : dépendance forte à une autre unité.
PartOf : lie certaines opérations, comme l’arrêt ou le redémarrage, à une autre unité.
Par exemple :
systemctl show nginx -p Requires -p Wants -p After
Si systemctl status affiche un message tel que Dependency failed for…, ne cherchez donc pas uniquement une erreur dans le service concerné. Identifiez d’abord l’unité en échec dont il dépend, puis corrigez celle-ci avant de tenter un nouveau démarrage.
Vérifier le fichier unit systemd
Chaque service géré par systemd repose sur un fichier unit (.service) qui décrit notamment la commande à exécuter, l’utilisateur utilisé, les dépendances, les conditions de redémarrage et l’ordre de lancement.
Lorsqu’un service ne démarre plus ou se comporte de manière inattendue, il peut être utile de vérifier le fichier unit réellement utilisé par systemd, notamment si celui-ci a été personnalisé.
Pour afficher la définition complète d’un service :
systemctl cat nom-du-service
Par exemple :
systemctl cat nginx
Cette commande est préférable à l’ouverture directe d’un fichier dans /etc/systemd/system/ ou /usr/lib/systemd/system/, car elle affiche la configuration réellement assemblée par systemd, y compris les éventuels fichiers de surcharge (drop-ins).
Vous pouvez notamment y retrouver les sections suivantes :
Section / directive
Rôle
[Unit]
Informations générales et dépendances du service
After= / Before=
Ordre de démarrage par rapport aux autres unités
Requires= / Wants=
Dépendances du service
[Service]
Paramètres d’exécution du service
ExecStart=
Commande utilisée pour démarrer le service
ExecReload=
Commande utilisée lors d’un rechargement
User= / Group=
Utilisateur et groupe sous lesquels le service s’exécute
Restart=
Comportement à adopter lorsque le processus s’arrête
WorkingDirectory=
Répertoire de travail du processus
Environment=
Variables d’environnement fournies au service
[Install]
Définit notamment comment le service est activé au démarrage
Identifier l’emplacement du fichier unit
Pour connaître précisément le fichier chargé par systemd :
systemctl show nom-du-service -p FragmentPath
Par exemple :
systemctl show nginx -p FragmentPath
Vous pouvez également afficher les éventuels fichiers de surcharge :
systemctl show nginx -p DropInPaths
Les fichiers unit fournis par les paquets sont généralement stockés dans des répertoires comme /usr/lib/systemd/system/ ou /lib/systemd/system/, tandis que les personnalisations administrateur sont généralement placées dans /etc/systemd/system/.
Vérifier les personnalisations d’un service
Un service peut fonctionner avec son fichier unit d’origine mais également avec un ou plusieurs drop-ins qui remplacent certaines directives.
La commande :
systemctl cat nom-du-service
permet de visualiser ces différentes sources dans un même affichage.
C’est particulièrement utile lorsqu’un service fonctionne différemment de sa configuration par défaut après une ancienne modification, une migration ou l’ajout d’une personnalisation systemd.
Pour modifier proprement les paramètres d’un service sans éditer directement le fichier fourni par le paquet, utilisez :
sudo systemctl edit nom-du-service
systemd crée alors une surcharge dans /etc/systemd/system/ qui ne sera pas écrasée lors d’une mise à jour du paquet.
Après toute modification d’un fichier unit ou d’un drop-in, il est nécessaire de demander à systemd de recharger ses fichiers de configuration avec systemctl daemon-reload avant de redémarrer le service.
Recharger systemd après modification d’un service
Lorsque vous modifiez un fichier unit systemd (.service) ou un fichier de surcharge (drop-in), systemd ne prend pas automatiquement en compte les changements. Il faut lui demander de relire les fichiers unit avant de redémarrer le service concerné.
Pour cela, exécutez :
sudo systemctl daemon-reload
Cette commande recharge la configuration de systemd et prend notamment en compte les modifications effectuées dans :
/etc/systemd/system/
/usr/lib/systemd/system/
/lib/systemd/system/
Les fichiers de surcharge créés avec systemctl edit
Après le rechargement, redémarrez le service concerné :
sudo systemctl restart nom-du-service
Puis vérifiez son état :
systemctl status nom-du-service
Par exemple, après avoir modifié une surcharge pour Nginx :
sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl status nginx
Ne pas confondre daemon-reload, reload et restart
Ces trois commandes ont des fonctions différentes :
Commande
Action
systemctl daemon-reload
Demande à systemd de relire les fichiers unit et leurs surcharges
systemctl reload service
Demande au service lui-même de relire sa configuration, sans l’arrêter lorsque celui-ci prend en charge cette opération
En revanche, si vous avez uniquement modifié le fichier de configuration de l’application, par exemple nginx.conf, un daemon-reload n’est généralement pas nécessaire. Après avoir vérifié la syntaxe, vous pouvez simplement recharger Nginx :
sudo nginx -t
sudo systemctl reload nginx
Retenez donc que daemon-reload concerne la configuration de systemd, tandis que reload concerne la configuration du service ou de l’application.
Tableau des commandes systemctl pour dépanner un service
Le tableau suivant récapitule les principales commandes systemctl à connaître pour vérifier, diagnostiquer et réparer un service géré par systemd.
Commande
Description
systemctl list-units --type=service
Lister les services actuellement chargés
systemctl list-unit-files --type=service
Lister tous les fichiers de services installés et leur état d’activation
systemctl --failed
Afficher les unités actuellement en échec
systemctl status service
Afficher l’état détaillé d’un service et ses derniers messages
systemctl is-active service
Vérifier rapidement si un service est actif
systemctl is-enabled service
Vérifier si un service est activé au démarrage
systemctl start service
Démarrer un service
systemctl stop service
Arrêter un service
systemctl restart service
Arrêter puis redémarrer un service
systemctl reload service
Recharger la configuration d’un service sans l’arrêter, lorsque cette fonction est prise en charge
systemctl enable service
Activer le démarrage automatique d’un service
systemctl enable --now service
Activer un service au démarrage et le démarrer immédiatement
systemctl disable service
Désactiver le démarrage automatique d’un service
systemctl disable --now service
Désactiver le service au démarrage et l’arrêter immédiatement
systemctl mask service
Bloquer complètement le démarrage d’un service
systemctl unmask service
Lever le blocage appliqué avec mask
systemctl reset-failed service
Effacer l’état failed et les compteurs d’échec d’un service
systemctl list-dependencies service
Afficher les dépendances d’un service
systemctl list-dependencies --reverse service
Afficher les unités qui dépendent du service
systemctl cat service
Afficher le fichier unit et les éventuels fichiers de surcharge (drop-ins)
systemctl show service
Afficher toutes les propriétés systemd d’un service
systemctl edit service
Créer ou modifier proprement une surcharge du fichier unit
systemctl daemon-reload
Demander à systemd de relire les fichiers unit après une modification
Pour un diagnostic rapide d’un service qui ne démarre plus, commencez généralement par ces trois commandes :
Si le service a échoué plusieurs fois et que systemd refuse désormais de le relancer avec un message comme Start request repeated too quickly, corrigez d’abord l’erreur puis utilisez :
Enfin, n’oubliez pas que systemctl et journalctl sont complémentaires : systemctl permet surtout de connaître et modifier l’état du service, tandis que journalctl permet d’analyser ses journaux afin de déterminer pourquoi il a échoué.
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.
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
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 :
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.
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.
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 :
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.
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
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.
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.
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.
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 :
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 journalctlne 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 :
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 :
D
est en Uninterruptible Sleep, généralement parce qu’il attend la fin d’une opération d’I/O.
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 :
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) :
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.
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.
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.
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 :
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é :
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 :
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
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.
Lorsqu’un PC ou un serveur Linux plante, se bloque ou redémarre de manière inattendue, l’origine du problème peut être matérielle : mémoire RAM instable, disque dur ou SSD défaillant, surchauffe, erreur CPU, périphérique PCIe ou contrôleur de stockage.
Linux intègre de nombreux outils en ligne de commandes permettant d’identifier le matériel et de rechercher les signes d’une défaillance. Les journaux du noyau avec dmesg et journalctl peuvent révéler des erreurs matérielles, tandis que des outils comme smartctl, Memtest86+, sensors, lspci ou dmidecode permettent d’approfondir le diagnostic d’un composant particulier.
Dans ce guide, découvrez comment diagnostiquer le matériel sous Linux en ligne de commandes : identifier les composants, tester la mémoire RAM, vérifier la santé des disques et SSD, surveiller les températures et rechercher les erreurs CPU/MCE, EDAC, PCIe, SATA ou NVMe.
Si votre ordinateur ne démarre plus correctement ou si vous souhaitez effectuer les tests depuis un environnement indépendant du système installé, vous pouvez également utiliser un Live USB Ubuntu : Tester et faire un diagnostic matériel de son PC sur Ubuntu
C’est particulièrement utile parce que le titre promet du diagnostic en ligne de commandes : le lecteur doit pouvoir reproduire les commandes.
Identifier le matériel du PC ou serveur Linux
Avant de rechercher une panne matérielle, commencez par identifier précisément les composants détectés par Linux. Plusieurs commandes permettent d’obtenir rapidement des informations sur le processeur, la mémoire RAM, les périphériques PCI/PCIe, les périphériques USB et les disques.
Pour afficher les caractéristiques du processeur :
lscpu
La commande indique notamment le modèle du CPU, son architecture, le nombre de cœurs et de threads, les caches ainsi que les fonctions prises en charge.
Pour obtenir uniquement les informations principales :
Pour connaître la quantité de mémoire détectée par Linux :
lsmem
Vous pouvez compléter avec :
free -h
Pour obtenir des informations plus détaillées sur les barrettes de mémoire installées, utilisez dmidecode avec les droits administrateur :
sudo dmidecode --type memory
Vous pouvez ainsi retrouver, lorsque le BIOS/UEFI fournit ces informations, la capacité, le fabricant, la référence, la vitesse et l’emplacement de chaque barrette de RAM.
Identifier les périphériques PCI et PCIe
La commande lspci permet d’identifier les périphériques connectés aux bus PCI et PCI Express :
lspci
Vous pouvez notamment y retrouver :
La carte graphique.
La carte réseau Ethernet ou Wi-Fi.
Les contrôleurs SATA/NVMe.
Les contrôleurs USB.
Les cartes son.
Les autres cartes d’extension PCIe.
Pour afficher également le pilote du noyau utilisé par chaque périphérique :
lspci -k
Cette variante est particulièrement intéressante lors d’un diagnostic, car elle permet de vérifier quel pilote Linux prend en charge un composant.
Cette commande permet notamment de repérer les clés USB, disques externes, webcams, adaptateurs Bluetooth ou Wi-Fi et autres périphériques connectés en USB.
Si un périphérique n’apparaît pas dans lsusb, le problème peut se situer au niveau de la connexion, du port USB ou du matériel lui-même plutôt qu’au niveau de son pilote.
Cette étape permet surtout de déterminer quel périphérique examiner ensuite. Par exemple, après avoir identifié un SSD comme /dev/nvme0n1 ou un disque comme /dev/sda, vous pourrez consulter son état SMART et rechercher dans les journaux du noyau les éventuelles erreurs qui lui sont associées.
Rechercher les erreurs matérielles dans les journaux
Certaines instabilités ou certains plantages de Linux peuvent provenir directement du matériel : processeur, mémoire RAM, carte mère, bus PCIe ou contrôleur de stockage. Le noyau Linux peut détecter une partie de ces anomalies et les enregistrer dans ses journaux.
Commencez par rechercher les principales erreurs matérielles :
Erreur détectée par le processeur, pouvant concerner le CPU, la RAM ou d’autres composants
EDAC
Erreur liée à la détection/correction des erreurs mémoire, notamment avec de la RAM ECC
PCIe Bus Error
rreur signalée par le mécanisme PCIe Advanced Error Reporting
AER
Erreur signalée par le mécanisme PCIe Advanced Error Reporting
Corrected error
Erreur matérielle détectée puis corrigée, qui mérite une surveillance si elle se répète
Uncorrected / Fatal error
Erreur qui n’a pas pu être corrigée et peut provoquer une instabilité ou un plantage
Attention : la présence des termes AER, PCIe ou DPC dans les journaux ne signifie pas nécessairement qu’une erreur matérielle s’est produite. Certains messages indiquent simplement les fonctionnalités prises en charge ou activées par le matériel.
Une erreur corrigée isolée n’indique pas nécessairement qu’un composant est en panne. En revanche, des erreurs matérielles répétées, surtout lorsqu’elles apparaissent juste avant les blocages ou redémarrages, doivent être prises au sérieux.
Sur un serveur, vous pouvez également utiliser rasdaemon lorsqu’il est disponible. Cet outil collecte et facilite l’analyse des événements RAS (Reliability, Availability and Serviceability), notamment les erreurs mémoire, CPU et PCIe.
Enfin, les journaux Linux ne permettent pas de détecter toutes les pannes. Si les plantages restent inexpliqués, poursuivez le diagnostic en testant séparément la RAM, le stockage, les températures et, si possible, l’alimentation et les autres composants matériels.
Vérifier l’état SMART des disques
Un disque dur, SSD ou NVMe défaillant peut provoquer des erreurs d’entrée/sortie, des ralentissements importants, des blocages et parfois un plantage complet de Linux.
Avec smartmontools, vérifiez rapidement les données SMART du disque :
sudo smartctl -a /dev/sda
Pour un SSD NVMe :
sudo smartctl -a /dev/nvme0
Portez notamment attention à l’état SMART général, aux secteurs réalloués ou instables, aux erreurs non corrigibles, aux erreurs d’intégrité NVMe et à la température du disque.
Si dmesg ou journalctl signale parallèlement des I/O error, des erreurs ATA/NVMe ou des erreurs répétées du système de fichiers, une défaillance du stockage doit être sérieusement envisagée. Dans ce cas, sauvegardez les données importantes avant d’effectuer des tests ou des réparations supplémentaires.
Un système de fichiers endommagé peut provoquer des erreurs d’entrée/sortie, des fichiers inaccessibles, des blocages ou le passage d’une partition en lecture seule (read-only).
Commencez par rechercher les erreurs signalées par le noyau :
Si Linux a redémarré après le plantage, examinez plutôt le démarrage précédent :
sudo journalctl -k -b -1
Des messages tels que EXT4-fs error, I/O error, Buffer I/O error ou Read-only file system doivent attirer votre attention.
Si des erreurs de système de fichiers sont détectées, utilisez l’outil de réparation adapté (fsck, xfs_repair, outils Btrfs, etc.). N’exécutez pas fsck sur un système de fichiers monté en lecture/écriture, au risque d’aggraver les dommages.
Une mémoire RAM défectueuse ou instable peut provoquer des plantages difficiles à diagnostiquer : Kernel Panic, erreurs de segmentation (segfault), corruption de données, applications qui plantent aléatoirement ou redémarrages inexpliqués.
Commencez par rechercher les éventuelles erreurs mémoire détectées par le noyau Linux :
Les systèmes équipés de mémoire ECC peuvent également remonter des erreurs corrigées ou non corrigées par l’intermédiaire d’EDAC (Error Detection And Correction). Des erreurs EDAC répétées doivent être examinées, même si elles sont indiquées comme corrigées.
Tester la RAM avec Memtest86+
Les journaux Linux ne permettent pas de détecter toutes les erreurs de mémoire. Pour effectuer un véritable test de la RAM, utilisez Memtest86+, qui fonctionne indépendamment du système d’exploitation.
Redémarrez le PC ou le serveur et lancez Memtest86+ depuis GRUB lorsqu’il est disponible, ou depuis une clé USB bootable.
Laissez le test effectuer plusieurs passes complètes. Une seule erreur détectée est déjà anormale : une mémoire RAM fonctionnant correctement ne doit générer aucune erreur.
Si des erreurs apparaissent :
Désactivez temporairement tout overclocking du processeur ou de la mémoire.
Désactivez les profils XMP/EXPO et rétablissez les paramètres mémoire par défaut du BIOS/UEFI.
Si plusieurs barrettes sont installées, testez-les une par une.
Testez si nécessaire une même barrette dans différents emplacements mémoire afin d’écarter un problème de slot ou de carte mère.
Des erreurs mémoire ne signifient donc pas systématiquement qu’une barrette est physiquement défectueuse. Une fréquence trop élevée, des timings incorrects, une tension inadaptée ou un problème du contrôleur mémoire peuvent également provoquer une instabilité.
Si les plantages sont aléatoires et touchent des applications différentes, notamment avec des segfault, des Kernel Panic ou des fichiers qui se corrompent sans cause évidente, un test approfondi de la RAM fait partie des vérifications matérielles prioritaires.
Vous pouvez aussi utiliser Memtest86, plus de détails:
Une surchauffe du processeur, du GPU ou d’un autre composant peut provoquer des ralentissements, du thermal throttling, des blocages et, dans les cas les plus sévères, un arrêt ou un redémarrage de sécurité du système.
Sous Linux, vous pouvez surveiller les températures avec le paquet lm-sensors. Une fois installé et configuré, exécutez :
sensors
Pour surveiller les températures en continu :
watch -n 2 sensors
Observez particulièrement les températures du CPU, de la carte mère et, lorsqu’elles sont disponibles, celles du GPU et des SSD NVMe. Une température élevée n’indique pas nécessairement une panne : il faut surtout rechercher une température qui atteint régulièrement la limite critique du composant ou qui coïncide avec les blocages.
Vous pouvez également rechercher dans les messages du noyau les événements liés à une surchauffe ou à une limitation thermique :
Des messages faisant référence à thermal throttling, critical temperature ou à une température dépassant un seuil critique peuvent orienter vers un problème de refroidissement.
Dans ce cas, vérifiez notamment l’état des ventilateurs, l’accumulation de poussière, le radiateur et le système de refroidissement. Sur une machine ancienne, une pâte thermique dégradée peut également entraîner une augmentation importante des températures.
Enfin, gardez à l’esprit qu’un arrêt thermique brutal peut ne pas laisser de message exploitable dans les journaux, le système pouvant s’éteindre avant que l’événement soit écrit sur le disque.
Vérifier les erreurs CPU et Machine Check Exception
Le processeur peut détecter certaines erreurs matérielles et les signaler au noyau Linux par l’intermédiaire du mécanisme Machine Check Exception (MCE). Ces erreurs peuvent concerner directement le CPU, mais également les caches, le contrôleur mémoire, la RAM ou les communications avec d’autres composants.
Des erreurs MCE répétées peuvent provoquer des Kernel Panic, des blocages, des redémarrages ou des erreurs applicatives aléatoires.
Pour rechercher les erreurs matérielles enregistrées par le noyau :
Un message peut par exemple contenir Machine check events logged, MCE, Hardware Error, Corrected error ou Uncorrected error.
Toutes les erreurs MCE ne provoquent pas nécessairement un plantage. Une erreur corrigée (Corrected Error) a été détectée et récupérée par le matériel. Une occurrence isolée n’indique pas forcément une panne, mais des erreurs corrigées qui se répètent doivent être surveillées.
À l’inverse, une Uncorrected Error ou une erreur indiquée comme Fatal est plus préoccupante et peut être directement responsable d’un plantage.
Vérifiez si une mise à jour du BIOS/UEFI est disponible.
Recherchez une éventuelle instabilité du CPU, de la RAM ou de la carte mère.
Sur un serveur, des outils comme rasdaemon peuvent également faciliter la collecte et l’analyse des erreurs matérielles remontées par le processeur, la mémoire et les mécanismes RAS.
Enfin, une Machine Check Exception ne signifie pas automatiquement que le processeur est défectueux. Le CPU est souvent le composant qui détecte et signale l’erreur, alors que sa véritable origine peut être la RAM, le contrôleur mémoire, la carte mère ou une configuration matérielle instable.
Vérifier les erreurs PCIe et périphériques
Les périphériques connectés au bus PCI Express (PCIe) peuvent également être à l’origine de plantages ou d’instabilités sous Linux. Cela concerne notamment les cartes graphiques, cartes réseau, contrôleurs NVMe, cartes RAID et autres cartes d’extension.
Linux peut signaler ces problèmes grâce au mécanisme AER (Advanced Error Reporting) de PCI Express.
Pour rechercher les erreurs PCIe enregistrées par le noyau :
Les messages peuvent notamment contenir PCIe Bus Error, AER, Corrected error, Uncorrected error ou Fatal error.
Message
Signification
Gravité / action
AER enabled with IRQ…
Le mécanisme PCIe Advanced Error Reporting est activé pour ce port.
Informatif, ce n’est pas une erreur.
DPC error containment capabilities…
Affiche les capacités Downstream Port Containment permettant d’isoler certaines erreurs PCIe.
Informatif, ce n’est pas une erreur.
Slot(…): Card present
Un périphérique est détecté dans un slot PCIe Hot Plug.
Informatif.
Signaling PME with IRQ…
Configuration de la gestion d’énergie PCIe (Power Management Event).
Informatif.
Failed to check link status
Le pilote pciehp n’a pas réussi à déterminer l’état de la liaison PCIe.
À surveiller si le message se répète ou si un périphérique disparaît/ne fonctionne pas.
Data Link Layer Link Active not set…
La couche liaison PCIe n’est pas passée à l’état actif dans le délai attendu.
Peut accompagner un problème d’établissement de la liaison. À surveiller si répété.
PCIe Bus Error: severity=Corrected
Une erreur PCIe a été détectée puis corrigée par le matériel/AER.
Généralement non critique si occasionnelle ; à surveiller si répétée.
PCIe Bus Error: severity=Uncorrected
Une erreur PCIe n’a pas pu être corrigée.
Anormal, identifier le périphérique concerné.
severity=Fatal
Erreur PCIe fatale.
Critique, peut entraîner la perte du périphérique ou un plantage.
Link down / link is down
La liaison avec le périphérique PCIe a été perdue.
Vérifier périphérique, slot, alimentation et pilote.
timeout
Le périphérique n’a pas répondu dans le délai prévu.
Rechercher d’autres erreurs autour du même périphérique.
reset / resetting
Linux tente de réinitialiser le périphérique après un problème.
À surveiller si les resets sont répétés.
Notez que certaines « error » peuvent être seulement informatives.
Pour identifier les périphériques PCI/PCIe présents sur la machine :
lspci
Pour afficher également le pilote du noyau associé à chaque périphérique :
lspci -k
Lorsqu’un identifiant PCI apparaît dans les journaux, par exemple 0000:03:00.0, vous pouvez identifier précisément le périphérique concerné avec :
lspci -s 03:00.0 -k
Cela permet de déterminer rapidement si l’erreur concerne, par exemple, une carte graphique, un contrôleur NVMe ou une carte réseau.
Des erreurs PCIe répétées peuvent provenir du périphérique lui-même, de son pilote, d’un mauvais contact dans le connecteur PCIe, du BIOS/UEFI, de la carte mère ou parfois de l’alimentation. Sur un PC fixe, si le problème concerne une carte d’extension, vérifiez également qu’elle est correctement insérée dans son slot et que ses éventuels connecteurs d’alimentation sont correctement branchés.
Une erreur AER corrigée et occasionnelle n’est pas nécessairement synonyme de panne. En revanche, une accumulation d’erreurs, des Uncorrected/Fatal errors, des resets répétés ou la disparition d’un périphérique doivent conduire à approfondir le diagnostic.
Vérifier les périphériques de stockage NVMe/SATA
Un SSD NVMe, un disque SATA ou son contrôleur peut être à l’origine de blocages, de ralentissements importants, de systèmes de fichiers passant en lecture seule ou de plantages de Linux. Avant même que SMART ne signale une panne, le noyau peut enregistrer des timeouts, resets et erreurs d’entrée/sortie (I/O).
Commencez par identifier les périphériques de stockage :
Portez notamment attention aux messages suivants :
Message
Cause possible
I/O error
Échec d’une opération de lecture ou d’écriture
Buffer I/O error
Erreur d’accès au périphérique de stockage
ataX: hard resetting link
Linux tente de réinitialiser une liaison SATA en erreur
SATA link down
Perte de communication avec le périphérique SATA
failed command
Commande ATA/SATA ayant échoué
timeout
SSD ou disque n’ayant pas répondu dans le délai attendu
nvme reset controller
Réinitialisation du contrôleur NVMe après un problème
I/O timeout
Opération d’entrée/sortie ayant dépassé le délai prévu
Sur un disque SATA, des erreurs répétées ne signifient pas nécessairement que le disque est défectueux. Un câble SATA endommagé ou mal connecté, un connecteur d’alimentation ou un contrôleur SATA peut également être responsable.
Sur un SSD NVMe, des timeouts ou resets répétés peuvent provenir du SSD, de son firmware, du contrôleur PCIe, d’une surchauffe ou d’un problème de gestion de l’énergie.
Si vous détectez ce type d’erreur, vérifiez ensuite l’état SMART du disque ou du SSD avec smartctl. En présence d’erreurs I/O répétées ou d’un état SMART dégradé, sauvegardez les données importantes avant de poursuivre les tests.
Tableau des commandes de diagnostic matériel Linux
Le tableau suivant récapitule les principales commandes permettant d’identifier le matériel et rechercher une panne sous Linux. Elles constituent une bonne base de diagnostic avant de passer à des tests plus approfondis.
Composant / vérification
Commande
Utilité
Processeur (CPU)
lscpu
Afficher le modèle, l’architecture, les cœurs, threads et caractéristiques du processeur
Mémoire RAM
lsmem
Afficher l’organisation et la quantité de mémoire détectée
Utilisation de la RAM
free -h
Vérifier la mémoire disponible, utilisée et le swap
Barrettes de RAM
sudo dmidecode --type memory
Afficher les caractéristiques des barrettes (capacité, vitesse, fabricant, emplacement)
Test de la RAM
Memtest86+
Détecter les erreurs et instabilités de la mémoire RAM
Périphériques PCI/PCIe
lspci
Identifier les cartes graphiques, réseau, contrôleurs et cartes d’extension
Pilotes PCI/PCIe
lspci -k
Identifier le pilote du noyau utilisé par chaque périphérique
Périphériques USB
lsusb
Lister les périphériques USB détectés
Disques et SSD
lsblk
Identifier les disques, SSD, partitions et points de montage
État SMART
sudo smartctl -a /dev/sda
Vérifier l’état de santé d’un disque SATA
État SMART NVMe
sudo smartctl -a /dev/nvme0
Vérifier la santé et les erreurs d’un SSD NVMe
Températures
sensors
Afficher les températures et autres capteurs matériels
Surveillance des températures
watch -n 2 sensors
Surveiller les températures en temps réel
Messages du noyau
sudo dmesg -T
Rechercher les erreurs matérielles, pilotes, stockage et périphériques
Journal du noyau
sudo journalctl -k
Consulter les événements matériels enregistrés par le noyau
Démarrage précédent
sudo journalctl -k -b -1
Rechercher une erreur matérielle ayant précédé un plantage ou redémarrage
Rechercher les erreurs de système de fichiers et d’entrée/sortie
Erreurs RAS
ras-mc-ctl --errors
Consulter les erreurs matérielles collectées par rasdaemon
Il n’existe pas de commande unique permettant de conclure qu’un composant est défectueux. Il faut généralement croiser plusieurs indices. Par exemple, des erreurs I/O error dans journalctl, des resets NVMe répétés et des erreurs SMART sur le même SSD constituent un faisceau d’indices beaucoup plus significatif qu’un message isolé.
De même, après un plantage suivi d’un redémarrage, pensez à examiner le démarrage précédent avec journalctl -k -b -1 : les journaux du démarrage actuel peuvent ne plus montrer les événements qui ont précédé la panne.
Surveiller les erreurs matérielles dans le temps avec rasdaemon
Pour aller plus loin dans le diagnostic, notamment sur un serveur Linux fonctionnant en continu, vous pouvez utiliser rasdaemon. Cet outil collecte et conserve un historique des événements RAS (Reliability, Availability and Serviceability) remontés par le noyau Linux.
Il permet notamment de surveiller certaines erreurs mémoire ECC/EDAC, Machine Check Events (MCE) et erreurs PCIe/AER afin de déterminer si elles sont isolées ou si elles se répètent et deviennent plus fréquentes avec le temps. Cette surveillance peut aider à détecter la dégradation progressive d’un composant avant qu’elle ne provoque une panne plus importante.
Contrairement à Memtest86+ ou aux autotests SMART, rasdaemon ne teste pas directement le matériel : il enregistre les erreurs détectées pendant le fonctionnement normal du système.
Les serveurs et stations de travail Linux disposent de mécanismes permettant de détecter et signaler certaines erreurs matérielles avant qu’elles ne provoquent nécessairement une panne. Une erreur mémoire ECC corrigée, une Machine Check Exception (MCE) ou une erreur PCIe/AER peut ainsi être enregistrée alors que le système continue à fonctionner normalement.
rasdaemon est un outil Linux dédié à la collecte et à la surveillance de ces événements RAS (Reliability, Availability and Serviceability). Associé à ras-mc-ctl, il permet de conserver un historique des erreurs matérielles, d’afficher leur détail et surtout de déterminer si elles se répètent ou deviennent plus fréquentes avec le temps.
Dans ce guide, découvrez comment installer et configurer rasdaemon sous Linux, enregistrer les événements RAS et utiliser ras-mc-ctl pour surveiller les erreurs mémoire ECC/EDAC, MCE et PCIe/AER. Vous apprendrez également à distinguer les erreurs Corrected, Uncorrected et Fatal et à mettre en place une surveillance régulière du matériel d’un serveur.
rasdaemon est un outil Linux destiné à collecter, enregistrer et faciliter l’analyse des erreurs matérielles remontées par le noyau. Il est principalement utilisé sur les serveurs et les stations de travail pour surveiller la fiabilité du matériel et détecter des anomalies qui peuvent passer inaperçues tant qu’elles restent corrigibles.
Son nom fait référence à RAS (Reliability, Availability and Serviceability), que l’on peut traduire par fiabilité, disponibilité et facilité de maintenance. Il s’agit d’un ensemble de mécanismes matériels et logiciels permettant de détecter, signaler et parfois corriger des erreurs sans provoquer immédiatement l’arrêt du système.
Selon le matériel et les mécanismes pris en charge par le noyau, rasdaemon peut notamment collecter des événements concernant :
La mémoire RAM ECC et EDAC (Error Detection And Correction).
Les erreurs processeur et Machine Check Events (MCE).
Les erreurs du bus PCI Express (PCIe/AER).
Certaines erreurs liées au stockage ou à d’autres composants disposant de mécanismes RAS.
Le noyau Linux peut déjà afficher ce type d’informations dans dmesg ou journalctl. L’intérêt de rasdaemon est de permettre une collecte structurée et persistante des événements, afin de suivre leur évolution dans le temps.
Par exemple, une mémoire ECC peut détecter et corriger automatiquement une erreur sans provoquer de plantage. Le serveur continue donc à fonctionner normalement. Si ce type d’erreur commence toutefois à se répéter régulièrement sur une même barrette, cela peut constituer le signe d’une dégradation matérielle.
Il est donc important de distinguer plusieurs niveaux d’erreurs :
Type d’erreur
Signification
Corrected / Correctable
L’erreur a été détectée et corrigée. Le système peut continuer à fonctionner, mais des occurrences répétées doivent être surveillées.
Uncorrected / Uncorrectable
L’erreur n’a pas pu être corrigée automatiquement et peut provoquer une corruption de données ou une instabilité.
Fatal
Erreur grave pouvant entraîner la perte d’un périphérique, un Kernel Panic ou un arrêt du système.
rasdaemon n’est donc pas un outil de test matériel comparable à Memtest86+ ou à un autotest SMART. Il ne sollicite pas volontairement les composants pour rechercher une panne. Son rôle est plutôt de surveiller et enregistrer les erreurs matérielles détectées pendant le fonctionnement normal de Linux.
Il est particulièrement intéressant sur un serveur fonctionnant 24 h/24, car il permet de repérer une augmentation progressive des erreurs corrigées avant qu’elles ne se transforment éventuellement en panne plus importante.
Dans la suite de ce guide, nous allons voir comment installer rasdaemon, activer la collecte des événements RAS et analyser les erreurs enregistrées avec ras-mc-ctl.
Installer rasdaemon
Le paquet rasdaemon est disponible dans les dépôts de nombreuses distributions Linux. Son installation nécessite les droits administrateur.
Sur Debian et Ubuntu, utilisez :
sudo apt update
sudo apt install rasdaemon
Sur Fedora :
sudo dnf install rasdaemon
Sur RHEL, Rocky Linux ou AlmaLinux, recherchez d’abord si le paquet est disponible dans les dépôts activés :
dnf search rasdaemon
Puis, s’il est disponible :
sudo dnf install rasdaemon
Selon la version de la distribution, l’activation d’un dépôt supplémentaire peut être nécessaire.
Sur Arch Linux :
sudo pacman -S rasdaemon
Une fois l’installation terminée, vérifiez que l’exécutable est disponible :
rasdaemon --version
Vous pouvez également afficher les options prises en charge :
rasdaemon --help
Le paquet installe généralement deux outils importants :
rasdaemon : le démon chargé de collecter les événements RAS remontés par le noyau.
ras-mc-ctl : l’utilitaire permettant notamment de consulter les erreurs et informations collectées.
Vous pouvez vérifier leur présence avec :
command -v rasdaemon
command -v ras-mc-ctl
L’installation du paquet ne garantit toutefois pas que tous les types d’erreurs matérielles pourront être surveillés. Les informations disponibles dépendent du processeur, de la carte mère, de la mémoire ECC éventuelle, des pilotes et des mécanismes RAS pris en charge par le noyau Linux.
Après l’installation, l’étape suivante consiste donc à activer et démarrer le service rasdaemon, puis à vérifier que la collecte des événements fonctionne correctement.
Activer et démarrer rasdaemon
Une fois rasdaemon installé, vérifiez que son service systemd est activé et en cours d’exécution. Le démon pourra ainsi surveiller les événements RAS remontés par le noyau Linux pendant le fonctionnement de la machine.
Pour démarrer rasdaemon et l’activer automatiquement au démarrage de Linux :
sudo systemctl enable --now rasdaemon
L’option --now permet d’effectuer les deux opérations en une seule commande : activer le service au démarrage et le lancer immédiatement.
Vérifiez ensuite son état :
systemctl status rasdaemon
Si le service fonctionne correctement, vous devez notamment obtenir un état similaire à :
Active: active (running)
Vous pouvez également vérifier simplement s’il est actif :
Pour vérifier le démarrage du démon et rechercher d’éventuelles erreurs :
sudo journalctl -u rasdaemon -e
Pour suivre ses événements en temps réel :
sudo journalctl -u rasdaemon -f
Si le service refuse de démarrer, affichez son état détaillé et ses derniers journaux :
systemctl status rasdaemon
sudo journalctl -u rasdaemon -e
Les fonctionnalités réellement disponibles dépendent du matériel, du noyau Linux et des mécanismes RAS pris en charge par la machine. L’absence de certains types d’événements ne signifie donc pas nécessairement que rasdaemon fonctionne mal.
Une fois le service actif, l’étape suivante consiste à vérifier que rasdaemon collecte correctement les événements matériels et, si nécessaire, à activer leur enregistrement persistant.
Pour exploiter pleinement rasdaemon, il est recommandé d’activer l’enregistrement persistant des événements RAS. Cela permet de conserver un historique des erreurs matérielles détectées et de les consulter ultérieurement avec ras-mc-ctl.
Cette fonction est particulièrement utile sur un serveur : elle permet de déterminer si des erreurs mémoire ECC, MCE ou PCIe/AER apparaissent régulièrement ou si leur nombre augmente avec le temps.
Pour activer l’enregistrement des événements, utilisez :
sudo rasdaemon --record
L’option --record demande à rasdaemon d’enregistrer les événements collectés dans une base de données SQLite.
Toutefois, si rasdaemon fonctionne déjà comme service systemd, ne lancez pas immédiatement cette commande, car l’enregistrement peut déjà être activé par le service.
Commencez par vérifier sa configuration :
systemctl cat rasdaemon
Recherchez la directive ExecStart. Si celle-ci contient l’option --record, l’enregistrement persistant est déjà activé et aucune modification supplémentaire n’est nécessaire.
Vous pouvez également vérifier la ligne de commande du processus en cours :
ps -ef | grep '[r]asdaemon'
Afficher un résumé des erreurs avec ras-mc-ctl
Une fois rasdaemon actif et l’enregistrement des événements configuré, la commande ras-mc-ctl permet de consulter les erreurs matérielles collectées.
Pour obtenir une vue d’ensemble, utilisez :
sudo ras-mc-ctl --summary
Cette commande affiche un résumé des événements RAS enregistrés dans la base de rasdaemon. Selon le matériel, le noyau et les mécanismes pris en charge par votre machine, vous pouvez notamment retrouver des compteurs liés à :
La mémoire et EDAC.
Les erreurs Machine Check (MCE).
Les erreurs PCIe/AER.
Les erreurs matérielles corrigées ou non corrigées.
D’autres événements RAS pris en charge par le système.
Si aucun problème matériel n’a été détecté, les compteurs concernés restent à 0 ou ras-mc-ctl indique qu’aucune erreur n’a été enregistrée. C’est un résultat normal.
Interpréter les résultats
Il est surtout important de surveiller l’évolution des compteurs dans le temps plutôt qu’une valeur isolée.
Situation
Interprétation
Aucune erreur
Aucun événement matériel pris en charge n’a été enregistré
Une erreur corrigée isolée
À surveiller, mais ne signifie pas nécessairement qu’un composant est défectueux
Erreurs corrigées qui augmentent régulièrement
Peut indiquer une dégradation ou une instabilité matérielle
Erreurs non corrigées
Anomalie plus sérieuse nécessitant d’identifier le composant concerné
Erreurs fatales
Peuvent provoquer un plantage, un Kernel Panic ou la perte d’un périphérique
Par exemple, sur un serveur équipé de mémoire ECC, quelques erreurs corrigées doivent être surveillées. Si leur nombre augmente régulièrement et qu’elles concernent toujours le même module mémoire, il devient pertinent de vérifier la barrette, son emplacement et la configuration mémoire.
De même, des erreurs PCIe/AER répétées peuvent conduire à examiner le périphérique PCIe concerné, son pilote, le slot, le BIOS/UEFI ou son alimentation.
Vous pouvez relancer périodiquement :
sudo ras-mc-ctl --summary
afin de vérifier si les compteurs évoluent.
Le résumé permet ainsi d’obtenir rapidement une vue générale de la santé matérielle remontée par les mécanismes RAS. Si des erreurs apparaissent, utilisez ensuite les fonctions détaillées de ras-mc-ctl ainsi que journalctl pour identifier plus précisément leur origine.
Surveiller les erreurs mémoire ECC et EDAC
Sur les serveurs et stations de travail équipés de mémoire ECC (Error-Correcting Code), le contrôleur mémoire peut détecter et, dans certains cas, corriger automatiquement les erreurs de mémoire. Sous Linux, ces événements peuvent être remontés par le sous-système EDAC (Error Detection And Correction) et collectés par rasdaemon.
La surveillance de ces erreurs est particulièrement intéressante sur un serveur : une barrette peut commencer à générer des erreurs corrigées tout en continuant à fonctionner normalement. Une augmentation progressive de leur nombre peut alors constituer un signe précurseur d’une défaillance mémoire.
Pour afficher un résumé des erreurs enregistrées :
sudo ras-mc-ctl --summary
Pour obtenir le détail des événements :
sudo ras-mc-ctl --errors
Vous pouvez également rechercher les événements EDAC directement dans les journaux du noyau :
Dans les événements mémoire, vous pouvez notamment rencontrer les termes CE et UE :
Type
Signification
Action
CE – Corrected Error
L’erreur mémoire a été détectée et corrigée par le mécanisme ECC.
Surveiller son évolution et le composant concerné.
UE – Uncorrected Error
L’erreur n’a pas pu être corrigée.
À prendre au sérieux : risque d’instabilité, de corruption ou de plantage.
Erreurs CE répétées
Les erreurs corrigées s’accumulent, éventuellement sur le même module.
Identifier le DIMM concerné et envisager son remplacement.
Une erreur corrigée isolée ne signifie pas nécessairement qu’une barrette de RAM est défectueuse. En revanche, si les erreurs CE augmentent régulièrement, particulièrement sur le même module ou canal mémoire, une investigation matérielle devient nécessaire.
Identifier la barrette mémoire concernée
Lorsque le matériel et le pilote EDAC fournissent suffisamment d’informations, les événements peuvent permettre d’identifier un DIMM, un canal ou un contrôleur mémoire particulier.
Vous pouvez comparer ces informations avec la configuration physique de la mémoire :
sudo dmidecode --type memory
Cette commande permet notamment d’afficher les emplacements mémoire (Locator), la capacité et, selon le matériel, le fabricant et la référence des barrettes.
Si rasdaemon ou EDAC désigne par exemple un emplacement DIMM_A1, DIMM_B2 ou un canal précis, recherchez l’emplacement correspondant dans dmidecode et dans la documentation de la carte mère ou du serveur.
Si les erreurs mémoire deviennent récurrentes, complétez le diagnostic avec un test de la RAM, par exemple Memtest86+, et vérifiez également les paramètres mémoire du BIOS/UEFI. Un overclocking, un profil XMP/EXPO ou une configuration mémoire instable peut également provoquer des erreurs sans que la barrette soit nécessairement défectueuse.
Analyser les Machine Check Events (MCE)
Les Machine Check Events (MCE) correspondent à des erreurs matérielles détectées par le processeur grâce à son mécanisme Machine Check Architecture (MCA). Contrairement à ce que leur nom peut laisser penser, une erreur MCE ne signifie pas nécessairement que le CPU est défectueux : le processeur peut signaler une anomalie provenant de la mémoire RAM, des caches, du contrôleur mémoire, de la carte mère ou d’autres composants.
rasdaemon permet de collecter ces événements et de conserver leur historique afin d’identifier les erreurs qui se répètent.
Commencez par afficher le résumé des événements enregistrés :
sudo ras-mc-ctl --summary
Puis consultez les erreurs détaillées :
sudo ras-mc-ctl --errors
Vous pouvez compléter cette analyse avec les messages du noyau :
Une erreur MCE peut être corrigée, non corrigée ou fatale. Son niveau de gravité et sa répétition sont donc plus importants que la simple présence du terme MCE.
Type d’événement
Signification
Action
Corrected / Correctable
Le matériel a détecté puis corrigé l’erreur.
Surveiller si elle se répète.
Uncorrected / Uncorrectable
L’erreur n’a pas pu être corrigée.
Rechercher rapidement le composant concerné.
Fatal
L’erreur empêche le système de continuer normalement.
Peut être directement liée à un Kernel Panic ou un redémarrage.
Erreurs répétées sur le même composant
Une anomalie matérielle ou une instabilité devient probable.
Approfondir le diagnostic du composant concerné.
Une erreur corrigée isolée n’indique donc pas nécessairement une panne. En revanche, des événements MCE qui apparaissent régulièrement ou dont la fréquence augmente doivent être pris au sérieux.
Rechercher l’origine d’une erreur MCE
Lorsqu’une erreur MCE est enregistrée, recherchez les informations permettant d’identifier sa provenance. Selon le processeur et le matériel, les événements peuvent notamment faire référence :
Au CPU ou à un cœur particulier.
Aux caches L1, L2 ou L3.
Au contrôleur mémoire.
À un canal ou une barrette de RAM.
À une erreur de bus ou d’interconnexion.
Il faut ensuite croiser ces informations avec les autres événements RAS. Par exemple, des MCE associées à des erreurs EDAC/ECC sur le même canal mémoire orientent davantage vers la RAM ou le contrôleur mémoire que vers une défaillance du processeur lui-même.
Si les erreurs MCE se répètent :
Désactivez tout overclocking ou undervolting.
Rétablissez temporairement les paramètres par défaut du BIOS/UEFI.
Désactivez les profils mémoire XMP/EXPO pour effectuer un test.
Vérifiez les températures du processeur.
Testez la mémoire RAM.
Vérifiez si une mise à jour du BIOS/UEFI ou du microcode CPU est disponible.
Recherchez si les événements concernent toujours le même CPU, cœur, cache ou canal mémoire.
L’intérêt de rasdaemon est ici de conserver un historique : plutôt que d’analyser uniquement une erreur ponctuelle dans dmesg, vous pouvez déterminer si les Machine Check Events se répètent ou deviennent plus fréquents, ce qui constitue un indicateur beaucoup plus pertinent d’une éventuelle dégradation matérielle.
Surveiller les erreurs PCIe/AER
Le bus PCI Express (PCIe) dispose d’un mécanisme appelé AER (Advanced Error Reporting) permettant de détecter et de signaler certaines erreurs de communication entre le processeur, le chipset et les périphériques PCIe.
Ces erreurs peuvent concerner de nombreux composants : carte graphique, SSD NVMe, carte réseau, contrôleur RAID, carte HBA ou tout autre périphérique connecté en PCI Express.
Avec rasdaemon, vous pouvez conserver un historique de ces événements afin de déterminer s’ils sont isolés ou s’ils se répètent sur le même périphérique.
Commencez par afficher le résumé des événements enregistrés :
sudo ras-mc-ctl --summary
Puis consultez les erreurs détaillées :
sudo ras-mc-ctl --errors
Vous pouvez compléter le diagnostic en recherchant les erreurs PCIe dans les journaux du noyau :
Toutes les lignes contenant les termes PCIe, AER ou DPC ne correspondent pas à une erreur. Linux affiche également de nombreux messages informatifs lors de l’initialisation du matériel.
Message
Signification
Action
AER enabled with IRQ…
Le mécanisme Advanced Error Reporting est activé.
Informatif, aucune action nécessaire.
DPC error containment capabilities…
Le port indique ses capacités Downstream Port Containment.
Informatif, ce n’est pas une erreur détectée.
Slot(…): Card present
Un périphérique est présent dans le slot PCIe.
Informatif.
PCIe Bus Error: severity=Corrected
Une erreur a été détectée puis corrigée.
À surveiller si elle devient fréquente.
PCIe Bus Error: severity=Uncorrected
L’erreur n’a pas pu être corrigée.
Identifier le périphérique et approfondir le diagnostic.
severity=Fatal
Erreur PCIe grave.
Peut provoquer la perte du périphérique ou un plantage.
Failed to check link status
Le pilote n’a pas réussi à vérifier correctement l’état de la liaison PCIe.
À surveiller si le message se répète ou accompagne la disparition d’un périphérique.
Data Link Layer Link Active not set
La liaison PCIe n’est pas devenue active dans le délai prévu.
Rechercher d’autres erreurs concernant le même port.
Link down
La liaison PCIe avec le périphérique a été perdue.
Vérifier le périphérique, le slot, l’alimentation et le pilote.
timeout / reset
Le périphérique ne répond plus correctement et peut avoir été réinitialisé.
À investiguer si les événements sont répétés.
Cette distinction est importante : une simple ligne AER enabled ne signifie pas qu’une erreur PCIe s’est produite.
Identifier le périphérique PCIe concerné
Les événements PCIe contiennent généralement une adresse permettant d’identifier le périphérique ou le port concerné, par exemple :
0000:03:00.0
Pour identifier ce périphérique :
lspci -s 03:00.0 -k
La commande affiche le composant ainsi que le pilote du noyau utilisé.
Vous pouvez ensuite rechercher tous les événements concernant cette adresse PCIe :
sudo journalctl -k | grep -i "03:00.0"
Cela permet de déterminer si les erreurs concernent systématiquement le même périphérique ou la même liaison PCIe.
Surveiller surtout la répétition des erreurs
Comme pour les erreurs ECC ou MCE, une erreur PCIe corrigée isolée n’indique pas nécessairement une panne matérielle. En revanche, des centaines ou milliers d’erreurs corrigées, des erreurs Uncorrected/Fatal, des pertes de liaison ou des resets répétés doivent être examinés.
Selon le périphérique concerné, vérifiez alors :
Le pilote Linux et le firmware du périphérique.
Le BIOS/UEFI de la carte mère.
Le branchement et le slot PCIe sur un PC ou serveur permettant cette vérification.
L’alimentation du périphérique.
Les températures.
Pour un SSD NVMe, son état SMART et ses propres journaux d’erreurs.
L’intérêt de rasdaemon est surtout de pouvoir déterminer si ces événements s’accumulent au fil des jours ou des semaines. Une augmentation régulière des erreurs sur la même adresse PCIe constitue un indice beaucoup plus significatif qu’un événement isolé observé au démarrage.
Mettre en place une surveillance régulière sur un serveur
Sur un serveur fonctionnant en continu, l’intérêt de rasdaemon est surtout de pouvoir suivre l’évolution des erreurs matérielles dans le temps. Une erreur corrigée isolée peut être sans conséquence, tandis qu’une augmentation régulière des erreurs ECC/EDAC, MCE ou PCIe/AER peut révéler une dégradation progressive d’un composant.
Commencez par vérifier périodiquement le résumé des événements :
sudo ras-mc-ctl --summary
Puis, si de nouvelles erreurs apparaissent, consultez leur détail :
sudo ras-mc-ctl --errors
Vous pouvez également vérifier les événements récents du noyau :
Enregistrez le fichier puis rendez-le exécutable :
sudo chmod 750 /usr/local/sbin/check-ras.sh
Testez-le manuellement :
sudo /usr/local/sbin/check-ras.sh
Puis vérifiez le résultat :
sudo tail -50 /var/log/ras-monitor.log
Exécuter automatiquement la vérification
Vous pouvez ensuite exécuter ce script régulièrement avec cron ou un timer systemd. Pour une simple surveillance matérielle, une vérification quotidienne est généralement suffisante : les événements restent enregistrés par rasdaemon entre deux contrôles.
L’objectif n’est toutefois pas simplement d’accumuler des rapports. Il faut surtout pouvoir détecter l’apparition de nouvelles erreurs ou l’augmentation de leur fréquence.
Par exemple :
Des erreurs ECC corrigées qui augmentent régulièrement sur le même DIMM peuvent indiquer une barrette mémoire à surveiller.
Des MCE répétées peuvent orienter vers le CPU, la RAM, le contrôleur mémoire ou la carte mère.
Des erreurs PCIe/AER répétées sur la même adresse PCIe peuvent signaler un problème de périphérique, de liaison, de slot ou de pilote.
Une erreur Uncorrected ou Fatal doit conduire à examiner rapidement le composant concerné.
Sur un serveur critique, il est préférable de conserver l’historique des événements plutôt que de réinitialiser régulièrement la base rasdaemon. Cela permet de comparer leur fréquence sur plusieurs jours ou semaines et de détecter une éventuelle dégradation matérielle avant qu’elle ne provoque une panne.
Tableau des commandes rasdaemon et ras-mc-ctl
Le tableau suivant récapitule les principales commandes rasdaemon et ras-mc-ctl utiles pour surveiller et diagnostiquer les erreurs matérielles sous Linux.
Commande
Description
rasdaemon --version
Afficher la version de rasdaemon installée
rasdaemon --help
Afficher les options disponibles
sudo systemctl enable --now rasdaemon
Activer rasdaemon au démarrage et lancer immédiatement le service
systemctl status rasdaemon
Vérifier l’état du service rasdaemon
systemctl is-active rasdaemon
Vérifier rapidement si rasdaemon fonctionne
sudo journalctl -u rasdaemon -e
Afficher les derniers messages du service rasdaemon
sudo journalctl -u rasdaemon -f
Suivre les messages du service en temps réel
systemctl cat rasdaemon
Afficher le fichier unit systemd et vérifier les options de démarrage
sudo rasdaemon --record
Lancer rasdaemon avec l’enregistrement des événements dans sa base de données
sudo ras-mc-ctl --summary
Afficher un résumé des erreurs matérielles enregistrées
sudo ras-mc-ctl --errors
Afficher le détail des erreurs matérielles enregistrées
sudo dmidecode --type memory
Identifier les barrettes et emplacements mémoire lors de l’analyse d’erreurs ECC/EDAC
lspci
Identifier les périphériques PCI/PCIe
lspci -s 03:00.0 -k
Identifier le périphérique et le pilote correspondant à une adresse PCIe précise
sudo journalctl -k
Consulter les événements matériels enregistrés par le noyau
sudo journalctl -k -b -1
Examiner les événements du noyau du démarrage précédent après un plantage
Pour un contrôle rapide de la santé matérielle, commencez généralement par :
sudo ras-mc-ctl --summary
Si des événements apparaissent, affichez ensuite leur détail :
sudo ras-mc-ctl --errors
Puis complétez l’analyse avec les journaux du noyau :
sudo journalctl -k
Après un plantage ou un redémarrage inattendu, utilisez plutôt :
sudo journalctl -k -b -1
L’objectif est de croiser les informations : rasdaemon permet de suivre l’historique des événements RAS, tandis que journalctl fournit le contexte du noyau autour de l’erreur. Une accumulation d’erreurs ECC/EDAC, MCE ou PCIe/AER sur le même composant est généralement plus significative qu’un événement corrigé et isolé.
Connexion
