La dernière release candidate de Linux 7.2 est bien plus "grosse" qu'elle ne devrait l'être à ce stade du cycle, mais cela n'a pas empêché Linus Torvalds de la publier dimanche en attribuant ce trop-plein aux outils IA qui relisent le code du noyau.
"Je ne peux pas dire que la taille de tout ça m'enthousiasme, mais c'est comme ça : la nouvelle normalité, avec beaucoup de correctifs, dont beaucoup viennent de la revue par divers outils IA."
Rien ne lui paraît effrayant pour autant, et il ne voit aucune raison de retarder la 7.2. Une grosse taille pour ce noyau, ça veut dire plus de 400 correctifs, signés par plus de 230 personnes alors que dans une Release Candidate en général, c'est le moment où le noyau est censé se calmer avant la sortie. Alors que là, ça ressemble plutôt à un nouveau début de cycle.
Et ça tape de partout : Pilotes graphiques, son, réseau, systèmes de fichiers, code d'architecture. Les plus gros blocs viennent de s390 et zcrypt, de btrfs qui remet en place une infrastructure interne, et de correctifs netfilter ipset.
Mais attention au contresens, parce que je l'ai vu passer sur certains tweets d'anti-IA. Torvalds parle de revue de code par des outils IA, et pas d'une IA qui écrirait le noyau à sa place. Sa position de fond,
Vincent nous la racontait en juillet
quand il envoyait les anti-IA forker le noyau. Ici, ça ne concerne que des outils qui relisent du code existant et signalent des trucs douteux. Après derrière, ce sont des humains qui trient.
À titre d'exemple, l'un des correctifs de cette rc7 traite un use-after-free dans ptdump, l'interface qui affiche les tables de pages du noyau en clair pour repérer les problèmes de mémoire. C'est ce type de bug qui se transforme en faille et il était là depuis mars 2018 (depuis Linux 4.16).
C'est
Syzbot
, le robot qui bombarde le noyau d'entrées tordues en continu, qui a levé le lièvre en juin dernier. David Carlier a écrit un premier correctif en s'aidant de Claude Opus 4.8 pour remonter la piste, et Lorenzo Stoakes, mainteneur de la gestion mémoire, l'a retravaillé avant qu'il parte dans la rc7. Il devrait ensuite être rétroporté vers les noyaux stables, donc vers les machines qui tournent aujourd'hui.
Autre exemple, Greg Kroah-Hartman, qui
traque déjà des bugs du noyau avec une IA locale
, vient de faire retirer le pilote Moxa Intellio, soit près de 2200 lignes écrites en 1999 qui supporte certaines cartes série multiports. Alors pourquoi est-ce qu'il a fait ça ? Eh bien il écrit dans son patch que : "C'est un très vieux pilote, aucun matériel connu ne circule encore pour lui, et la société dit ne plus en avoir besoin, alors retirons-le puisque les LLM commencent à venir le titiller et à y trouver des choses "intéressantes" qui vont juste faire perdre du temps à tout le monde, vu qu'il ne sert plus...".
Voilà donc un autre effet de l'analyse de code par IA. Elle oblige les mainteneurs de projet à tailler dans le gras pour virer du code obsolète que des modèles de langage viendraient renifler d'un peu trop près. Ça ne peut pas faire de mal.
Pour moi, le vrai risque de ces outils sur un projet ouvert tient au volume. Un flot de signalements produits par des gens qui ne relisent pas ce qu'ils envoient, où plus personne ne distingue l'hallucination du vrai bug, et là ça partirait en eau de boudin. Mais comme le noyau, lui, garde des mainteneurs qui comprennent les tenants et les aboutissants de ce qu'ils lisent, ça se passe très bien. Même si la quantité de problèmes remontés surprend Linus.
Voilà, si cette nouvelle version du noyau vous intéresse, sachez qu'elle devrait normalement sortir la semaine prochaine en version finale.
Linux 7.2-rc7 is unusually large, but Linus Torvalds says the volume of small fixes—many prompted by AI-assisted code reviews—is becoming the “new normal.” Nothing appears serious enough to delay the stable Linux 7.2 release expected next week.
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é.
A new TONTOU “interrupt injection” attack can re-poison branch predictors after Spectre v2 defenses run, allowing unprivileged code to extract sensitive data from Linux kernel memory. An AMD kernel fix is already available, but shared hosts remain at risk until administrators deploy it and review workload isolation.
CHERRY a annoncé deux appareils à carte à puce, un clavier complet avec lecteur intégré baptisé Smart Board 1150, et un terminal séparé, le Smart Terminal ST-1150. Ils remplacent le KC 1000 SC et le ST-1144.
Une carte à puce sert ici à prouver qui vous êtes. Vous l'insérez, elle signe électroniquement un document, elle ouvre une session sur un réseau ou elle déchiffre un fichier, sans que la clé privée qu'elle contient ne sorte jamais de la puce.
Les deux appareils s'appuient sur le pilote CCID que Microsoft livre déjà dans Windows, et sur pcsc-lite sous Linux et macOS. La norme CCID permet à un lecteur de dialoguer avec le système d'exploitation sans code maison, et pcsc-lite en est l'implémentation libre côté Unix.
Aucun pilote propriétaire à installer, donc. Vous branchez et ça fonctionne, y compris sur une machine Linux, ce qui est encore assez rare pour ce type de matériel.
Screenshot
Les deux modèles embarquent aussi un contrôleur à mémoire flash, et le firmware peut être mis à jour après le déploiement. Ce genre de lecteur était jusqu'à présent figé pour toute sa durée de vie, avec les failles qu'il avait le jour de sa fabrication.
Le communiqué ne dit hélas rien sur la signature de ces mises à jour. Sur un périphérique de sécurité, la question n'a rien de cosmétique, parce qu'un firmware modifiable est aussi un firmware attaquable si personne ne vérifie d'où vient l'image installée.
Le terminal lit et écrit les cartes, pour ouvrir une porte, se connecter au réseau de l'entreprise ou valider une transaction en ligne. Il est fabriqué entièrement en Europe. CHERRY veut clairement faire les yeux doux aux administrations et aux organismes de défense, avec les certifications américaines TAA et FIPS-201 au passage, et une base lestée en métal qui permet d'y glisser la carte d'une seule main.
Le clavier ajoute pour sa part une touche Copilot, ce qui sur un poste à données sensibles est quand même quelque peu audacieux. Il existe aussi en version conforme au Trade Agreements Act américain, pour les agences fédérales et les installations militaires soumises à des règles d'approvisionnement particulières, mais bon a priori ça ne devrait pas trop vous concerner (même si on a de plus en plus de lecteurs américains depuis que le site est traduit !).
Le Smart Board 1150 est vendu 49,99 euros. Le Smart Terminal ST-1150 descend à 34,99 euros, et les deux sont disponibles dès maintenant.
J'avoue que je ne pensais plus voir sortir de nouveaux lecteurs de carte à puce en 2026.
Patch Tuesday now delivers hundreds of vulnerabilities at once. But not every fix deserves the same urgency. Join us on Wednesday, August 12, for the Vulnerability Digest from Action1. Our experts will identify the vulnerabilities that require immediate action, explain which updates can safely wait, and show you how to prioritize remediation across your environment.
Linux desktop market share has passed 10% in North America according to StatCounter. The rise may point to a broader shift: as users increasingly access services through AI agents, the underlying operating system—and their familiarity with its traditional applications—could become less important. Linux proved to be the ideal operating system for the cloud, and AI could potentially have a similar transformative impact on the desktop.
A public exploit for CVE-2026-64531, the Linux kernel Open vSwitch flaw known as OVSwrap, includes offsets for roughly 800 x86-64 kernel builds. The module can also be loaded automatically when an attacker probes its Generic Netlink interface, so an empty `lsmod` result does not prove that a host is safe.
Azure Linux 4.0 beta is now available on Windows PCs through WSL, giving developers a local environment that more closely matches Microsoft’s Azure production systems. The server-focused distribution supports x86-64 and Arm64 devices, but Microsoft limits this release to evaluation and testing rather than production use.
Découvrez Gufw, l'interface graphique UFW sous Linux : installation, création des règles de pare-feu et bonnes pratiques, sans passer par la ligne de commande.
Canonical is replacing Ubuntu’s traditional `hwctl` Deb package with a confined Snap, beginning with an automatic migration planned for Ubuntu 26.04 LTS. The change is tied to future GNOME hardware-management integration, but administrators should also account for Snap’s security maintenance requirements.
Linux 7.2-rc6 is the largest sixth release candidate in years by commit count, yet Linus Torvalds does not see a technical reason to delay Linux 7.2. The unusually busy kernel update is dominated by driver and networking fixes, with the stable release still expected in roughly two weeks.
Arch Linux has temporarily frozen package adoptions in the Arch User Repository (AUR) after attackers used maintainer takeovers and orphaned packages to push malicious updates. The campaign reportedly affects dozens of packages and delivers a Linux infostealer with remote access and SSH-worm capabilities.
Microsoft has made native CIS Benchmark auditing generally available for Linux virtual machines, eliminating the need for separate compliance tools. Azure Machine Configuration now continuously checks Azure and Azure Arc-enabled Linux systems against CIS-certified benchmarks and surfaces the results through Azure management services.
Connexion
