Linux : votre serveur redémarre de façon aléatoire — la piste des logs que vous ignorez

Ce que « redémarrage aléatoire » signifie vraiment (et pourquoi ce n’est rarement aléatoire)

Un hôte Linux « a redémarré de façon aléatoire » est une histoire. Votre travail est de la transformer en chronologie avec une cause. La plupart des redémarrages appartiennent à quelques catégories :

• Redémarrage ordonné : quelqu’un ou quelque chose a appelé reboot, shutdown, ou a déclenché un flux de mise à jour du noyau.
• Redémarrage suite à un plantage : kernel panic, BUG, blocage, ou watchdog déclenché ; parfois avec kdump, parfois sans.
• Événement d’alimentation : picote de l’alimentation PSU, déclenchement PDU, réinitialisation BMC/firmware, reset d’hyperviseur, ou une intervention « utile » des mains à distance.
• Action du contrôleur de gestion : cycle d’alimentation IPMI, politique iDRAC/iLO, ou remédiation automatisée.
• Événement de virtualisation : hôte redémarré, VM réinitialisée, migration à chaud échouée, ou chaîne de snapshots devenue incontrôlable.

L’erreur principale : traiter le « redémarrage » comme un seul événement. C’en est deux : la fin d’un démarrage (la défaillance) et le début du démarrage suivant (la reprise). Les logs Linux parleront des deux, mais pas au même endroit ni avec la même honnêteté.

Une citation à garder sur votre bureau : « idée paraphrasée » — W. Edwards Deming : sans mesure, vous devinez en grande partie.  Dans les redémarrages, la « mesure » ce sont vos logs, les enregistrements d’événements firmware, et les dump de crash. Si vous ne les avez pas, vous devinez.

Guide de diagnostic rapide (premier/deuxième/troisième)

Premier : établir le type de redémarrage en 5 minutes

1. Était-ce ordonné ? Vérifiez le journal systemd pour une séquence d’arrêt et les lignes de raison « reboot ».
2. Était-ce un plantage ? Cherchez panic/oops/watchdog et si les logs s’arrêtent brusquement.
3. Était-ce lié à l’alimentation ? Comparez les logs OS avec les SEL du BMC et les événements de l’hyperviseur. L’absence de logs d’arrêt OS signifie souvent que le système n’a pas eu voix au chapitre.

Deuxième : décider quelle piste est faisant autorité

• Serveur physique : SEL du BMC + logs noyau + MCE sont rois.
• VM : événements hyperviseur + journal du guest + erreurs de disque virtuel.
• Instance cloud : historique de redémarrages du fournisseur + logs du serial console + journal du guest.

Troisième : isoler le domaine de la défaillance

• Calcul : MCE, blocages, throttling thermique, microcode, watchdog.
• Mémoire : tempêtes de ECC corrigées, défaillances DIMM, poison, bizarreries NUMA.
• Stockage : réinitialisation de contrôleur NVMe, réinitialisations de lien SATA, abort ext4/xfs, oscillations multipath, timeouts de firmware.
• Réseau : réinitialisations de firmware de NIC pouvant bloquer le noyau dans les pilotes, surtout sous charge.
• Alimentation : PSU, PDU, UPS, maintenance du datacenter, câble lâche (oui, ça arrive encore).

Règle rapide : si le journal s’arrête en plein milieu d’une phrase, suspectez une coupure d’alimentation ou un reset dur. S’il contient une séquence d’arrêt propre, suspectez des humains, de l’automatisation, ou un panic gracieux avec politique de redémarrage.

Blague #1 : Un « redémarrage aléatoire » est comme un tour de magie — la diversion marche jusqu’à ce que vous regardiez l’autre main (IPMI SEL).

Carte des sources de logs : qui sait quoi, et quand

1) systemd-journald : la narration, avec des notes de bas de page

Sur la plupart des distributions modernes, journald est votre chronologie principale. Il tague les entrées par boot ID, peut afficher le boot précédent, et capture souvent aussi les messages du noyau. Mais ce n’est pas magique : si la machine perd l’alimentation, le journal peut ne pas se vider sur disque. Cette absence est en elle-même une preuve.

2) Tampon circulaire du noyau (dmesg) : l’audio de la scène du crime

dmesg est une vue du tampon circulaire du noyau. Il est utile pour les problèmes de pilotes, les réinitialisations de lien de stockage et les traces de panic. Mais après un redémarrage, dmesg montre ce démarrage à moins que vous n’utilisiez les logs noyau stockés par le journal pour le boot précédent.

3) /var/log/wtmp (last) et /var/log/btmp : le registre des visiteurs

last peut vous dire quand le système a démarré et qui s’est connecté. C’est grossier, mais rapide, et il survit à pas mal de chaos. Si wtmp manque, est mal pivoté ou corrompu, c’est un autre indice.

4) BMC / IPMI SEL : le journal intime du matériel

Les contrôleurs de gestion de serveurs tiennent un System Event Log (SEL) : cycles d’alimentation, watchdog, événements thermiques, irrégularités de tension. C’est le journal que l’OS ne peut pas falsifier. Si le SEL dit « Power Unit lost AC », arrêtez de discuter avec lui.

5) Crash dumps (kdump) : l’autopsie

Si vous avez kdump configuré, un crash du noyau peut laisser un vmcore. Ce n’est pas un simple luxe. C’est la différence entre « peut-être un pilote » et « voici la pile exacte et le verrou ».

6) Logs de la couche stockage : où les redémarrages se déguisent en « problèmes applicatifs »

Les erreurs de stockage précèdent souvent les redémarrages d’une manière que l’on manque. Réinitialisations NVMe, timeouts SCSI, aborts de journal ext4, et accrochages de firmware de contrôleur peuvent bloquer le système jusqu’à ce que le watchdog le redémarre. Si vos logs contiennent de longues pauses I/O avant le redémarrage, votre redémarrage était probablement une histoire de stockage déguisée en noyau.

Tâches pratiques : commandes, sorties, décisions (12+)

Ci‑dessous des tâches pratiques à exécuter sur un système réel. Pour chacune : quoi lancer, ce que signifie la sortie, et quelle décision en tirer. Exécutez-les dans cet ordre approximatif quand vous êtes sous pression.

Tâche 1 : Confirmer les heures de redémarrage et le compte approximatif

cr0x@server:~$ uptime
 10:18:02 up 1 day,  2:41,  2 users,  load average: 0.54, 0.62, 0.70

Signification : Cela vous donne seulement l’heure du dernier démarrage. Pas la raison.

Décision : Si l’uptime est anormalement bas, vous avez besoin des logs du boot précédent (-b -1) immédiatement.

Tâche 2 : Utiliser wtmp pour voir les redémarrages et arrêts

cr0x@server:~$ last -x | head -n 12
reboot   system boot  6.8.0-41-generic Mon Feb  3 07:36   still running
shutdown system down  6.8.0-41-generic Mon Feb  3 07:35 - 07:36  (00:01)
reboot   system boot  6.8.0-41-generic Sun Feb  2 22:11 - 07:35  (09:24)
crash    system down  6.8.0-41-generic Sun Feb  2 22:10 - 22:11  (00:01)

Signification : « shutdown » indique un arrêt ordonné consigné par init/systemd. « crash » peut montrer un arrêt non propre.

Décision : S’il n’y a pas de « shutdown » avant « reboot », suspectez une coupure d’alimentation, un bouton reset, un cycle d’alimentation BMC, ou un blocage dur.

Tâche 3 : Trouver des indices sur la raison du redémarrage dans le journal du boot précédent

cr0x@server:~$ journalctl -b -1 -p warning --no-pager | tail -n 30
Feb 02 22:09:44 server kernel: nvme nvme0: I/O 987 QID 5 timeout, aborting
Feb 02 22:09:45 server kernel: nvme nvme0: Abort status: 0x371
Feb 02 22:09:49 server kernel: INFO: task kworker/u64:2 blocked for more than 120 seconds.
Feb 02 22:10:12 server kernel: watchdog: BUG: soft lockup - CPU#23 stuck for 22s! [ksoftirqd/23:93]
Feb 02 22:10:13 server kernel: Kernel panic - not syncing: softlockup: hung tasks

Signification : Classique : timeouts de stockage → tâches noyau bloquées → watchdog lockup → panic.

Décision : Arrêtez de chasser un « kernel panic aléatoire ». Traitez le chemin stockage/NVMe comme suspect principal.

Tâche 4 : Vérifier si le journal est persistant (crucial pour les post-mortems)

cr0x@server:~$ grep -R "^[# ]*Storage=" /etc/systemd/journald.conf
#Storage=auto

Signification : auto utilise le stockage persistant si /var/log/journal existe ; sinon volatile.

Décision : Si vous n’avez pas /var/log/journal, créez-le et redémarrez journald. Sans persistance, les crashs paraissent « mystérieux » parce que vous avez jeté le passé.

Tâche 5 : Lister les boots et aligner la chronologie

cr0x@server:~$ journalctl --list-boots | head
-2 2c6c0a2a0b1f4cc2b4e0a3f57a8d8f55 Sun 2026-02-02 12:01:17 UTC—Sun 2026-02-02 22:11:01 UTC
-1 91f5d1f5e72a4a00b2b0c2b3f9edaa4c Sun 2026-02-02 22:11:10 UTC—Mon 2026-02-03 07:36:01 UTC
 0 7bb2c1fdc77a4c1e9c3ce2c1b6a11e0b Mon 2026-02-03 07:36:10 UTC—Mon 2026-02-03 10:18:20 UTC

Signification : Les boot IDs vous permettent de pivoter précisément et de comparer « fin du boot -1 » avec « début du boot 0 ».

Décision : Identifiez le boot qui s’est mal terminé, puis inspectez les 5 dernières minutes de ce boot et les 2 premières minutes du suivant.

Tâche 6 : Récupérer les dernières minutes du boot précédent (là où le corps est enterré)

cr0x@server:~$ journalctl -b -1 --since "10 min before shutdown" --no-pager | tail -n 80
Feb 02 22:09:41 server systemd[1]: Started Daily apt download activities.
Feb 02 22:09:44 server kernel: nvme nvme0: I/O 987 QID 5 timeout, aborting
Feb 02 22:10:12 server kernel: watchdog: BUG: soft lockup - CPU#23 stuck for 22s! [ksoftirqd/23:93]
Feb 02 22:10:13 server kernel: Kernel panic - not syncing: softlockup: hung tasks
Feb 02 22:10:13 server kernel: Rebooting in 5 seconds..

Signification : Si vous voyez « Rebooting in 5 seconds, » le noyau a choisi de redémarrer (comportement panic). Si le log s’arrête brusquement, il ne l’a pas fait.

Décision : Le panic implique une voie de crash ; commencez les vérifications kdump et le tri des pilotes/firmware.

Tâche 7 : Chercher des requêtes explicites d’arrêt/reboot (humains et automatisation)

cr0x@server:~$ journalctl -b -1 -u systemd-logind --no-pager | grep -E "Power key|reboot|shutdown" | tail -n 20
Feb 02 22:07:03 server systemd-logind[933]: Power key pressed short.
Feb 02 22:07:03 server systemd-logind[933]: System is rebooting.

Signification : Quelqu’un a appuyé sur le bouton d’alimentation (ou le châssis/BMC a envoyé l’événement).

Décision : Corrélez avec les logs d’accès physique, les sessions BMC, et le SEL. N’accusez pas le noyau de ce qu’un doigt a fait.

Tâche 8 : Vérifier les resets watchdog (matériel ou logiciel)

cr0x@server:~$ journalctl -k -b -1 --no-pager | grep -i watchdog | tail -n 30
Feb 02 22:10:12 server kernel: watchdog: BUG: soft lockup - CPU#23 stuck for 22s! [ksoftirqd/23:93]
Feb 02 22:10:13 server kernel: NMI watchdog: Watchdog detected hard LOCKUP on cpu 7

Signification : Les messages watchdog indiquent des blocages CPU prolongés. Souvent causés par des deadlocks de pilote, des tempêtes d’interruption, ou des stalls I/O qui bloquent des threads noyau.

Décision : Si le watchdog est impliqué, commencez à chasser la source amont du blocage (timeouts de stockage, réinitialisations NIC, bugs noyau connus) plutôt que de traiter le watchdog comme la cause.

Tâche 9 : Vérifier les Machine Check Exceptions (MCE) et signaux ECC mémoire

cr0x@server:~$ journalctl -k -b -1 --no-pager | grep -iE "mce|machine check|hardware error" | tail -n 40
Feb 02 22:08:21 server kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 8: b200000000070005
Feb 02 22:08:21 server kernel: mce: [Hardware Error]: TSC 0 ADDR fef1a140 MISC d012000100000000
Feb 02 22:08:21 server kernel: mce: [Hardware Error]: PROCESSOR 2:a20f12 TIME 1706911701 SOCKET 0 APIC 0 microcode 0x2f

Signification : Les erreurs matérielles peuvent être corrigées (pas de redémarrage) ou fatales (panic/reset). Des erreurs corrigées répétées sont malgré tout exploitables ; ce sont le « voyant moteur ».

Décision : Si un MCE apparaît près du redémarrage, impliquez le fournisseur/support matériel et vérifiez l’état des DIMM/CPU/VRM. Ne « contournez » pas la physique.

Tâche 10 : Sur serveurs physiques, lire l’IPMI SEL pour événements d’alimentation et thermiques

cr0x@server:~$ ipmitool sel list | tail -n 12
2a0 | 02/02/2026 | 22:09:58 | Power Unit #0x01 | Power lost | Asserted
2a1 | 02/02/2026 | 22:10:02 | Power Unit #0x01 | Power restored | Asserted
2a2 | 02/02/2026 | 22:10:05 | System Event | System Boot Initiated | Asserted

Signification : Le SEL confirme un événement AC/power. Les logs OS peuvent ressembler à un crash parce qu’ils se sont arrêtés brusquement, mais la cause réelle était « pas d’électricité ».

Décision : Escaladez vers les services/filière d’alimentation (PDU/UPS), vérifiez les alimentations redondantes, et inspectez les journaux de changement du datacenter. Le debug noyau est une perte de temps ici.

Tâche 11 : Vérifier si kdump a capturé un vmcore

cr0x@server:~$ ls -lh /var/crash
total 2.1G
drwxr-xr-x 2 root root 4.0K Feb  2 22:10 127.0.1.1-2026-02-02-22:10:14
-rw------- 1 root root 2.1G Feb  2 22:12 vmcore
-rw-r--r-- 1 root root  18K Feb  2 22:12 vmcore-dmesg.txt

Signification : Vous avez un dump de crash. C’est de l’or : vous pouvez identifier le thread qui a planté, les verrous et les modules impliqués.

Décision : Conservez-le (copiez-le hors hôte), puis analysez-le avec des outils crash (ou remettez-le au support noyau). Ne redémarrez pas cinq fois de plus et n’écrasez pas la preuve.

Tâche 12 : Détecter l’OOM killer et les événements de pression mémoire

cr0x@server:~$ journalctl -b -1 -k --no-pager | grep -iE "oom-killer|Out of memory|Killed process" | tail -n 30
Feb 02 21:58:34 server kernel: Out of memory: Killed process 24891 (java) total-vm:18742000kB, anon-rss:14230000kB
Feb 02 21:58:34 server kernel: oom_reaper: reaped process 24891 (java), now anon-rss:0kB, file-rss:0kB

Signification : L’OOM killer n’est pas un redémarrage en soi, mais il peut en cascade provoquer des resets watchdog si des démons critiques meurent, ou si le système thrash.

Décision : Si l’OOM précède le redémarrage, corrigez les limites mémoire, cgroups, paramètres d’overcommit, et stratégie de swap. Vérifiez aussi si un watchdog externe a redémarré après la mort d’un service.

Tâche 13 : Vérifier les erreurs de système de fichiers qui peuvent forcer un remount-ro ou des blocages

cr0x@server:~$ journalctl -b -1 -k --no-pager | grep -iE "EXT4-fs error|XFS.*corruption|Buffer I/O error|blk_update_request" | tail -n 40
Feb 02 22:09:31 server kernel: blk_update_request: I/O error, dev nvme0n1, sector 2039488 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Feb 02 22:09:33 server kernel: EXT4-fs error (device nvme0n1p2): ext4_find_entry:1539: inode #2: comm systemd: reading directory lblock 0
Feb 02 22:09:33 server kernel: EXT4-fs (nvme0n1p2): Remounting filesystem read-only

Signification : Des erreurs de stockage ont remonté jusqu’au système de fichiers. Un remount en lecture seule peut faire tomber des services, puis watchdog ou orchestration peut redémarrer.

Décision : Traitez-le comme un incident de fiabilité stockage. Exécutez SMART/NVMe health, examinez le firmware du contrôleur, et planifiez un fsck si nécessaire.

Tâche 14 : Vérifier la santé NVMe et le journal d’erreurs (précurseur fréquent de redémarrage)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | sed -n '1,25p'
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 47 C
available_spare                     : 100%
available_spare_threshold           : 10%
percentage_used                     : 4%
media_errors                        : 12
num_err_log_entries                 : 98
warning_temp_time                   : 0
critical_comp_time                  : 0

Signification : Les media_errors et le nombre d’entrées du journal d’erreurs qui augmentent se corrèlent fortement avec les timeouts et les réinitialisations de contrôleur.

Décision : Si media_errors et num_err_log_entries sont non triviaux et en hausse, planifiez le remplacement du disque et vérifiez la compatibilité du firmware. N’attendez pas que « ça empire ». Ça le fera.

Tâche 15 : Vérifier les réinitialisations de lien SATA/SAS (si pas NVMe)

cr0x@server:~$ journalctl -k -b -1 --no-pager | grep -iE "link is slow to respond|hard resetting link|SATA link down" | tail -n 50
Feb 02 22:08:58 server kernel: ata3.00: failed command: READ FPDMA QUEUED
Feb 02 22:08:59 server kernel: ata3: hard resetting link
Feb 02 22:09:05 server kernel: ata3: link is slow to respond, please be patient (ready=0)

Signification : Le lien de stockage est instable. Cela peut geler les I/O et provoquer des cascades de blocages.

Décision : Inspectez le câblage, le backplane et le firmware de la HBA. Ce n’est pas une situation « réinstaller l’OS ».

Tâche 16 : Vérifier si l’heure a sauté ou des problèmes RTC (peut casser le raisonnement chronologique)

cr0x@server:~$ journalctl -b -1 --no-pager | grep -iE "Time has been changed|System clock time|rtc" | tail -n 20
Feb 02 22:11:12 server systemd-timesyncd[612]: System clock time unset or jumped backwards, restoring from recorded timestamp: 2026-02-02 22:11:11 UTC

Signification : Les sauts d’heure peuvent faire paraître les redémarrages plus tôt/plus tard, ce qui ruine la corrélation avec les logs BMC ou hyperviseur.

Décision : Corrigez la synchronisation horaire (NTP/chrony), vérifiez la pile RTC/firmware, et faites attention en alignant les événements entre systèmes.

Tâche 17 : Confirmer les derniers paquets/kernel mis à jour autour de la fenêtre de redémarrage

cr0x@server:~$ journalctl -b -1 --no-pager | grep -iE "apt|dnf|yum|transaction|linux-image|kernel" | tail -n 30
Feb 02 22:05:02 server unattended-upgrades[21122]: Installing: linux-image-6.8.0-41-generic
Feb 02 22:05:48 server unattended-upgrades[21122]: Packages that will be upgraded: linux-image-generic

Signification : Une mise à jour du noyau peut déclencher des workflows de redémarrage (directement ou via orchestration), ou introduire une régression.

Décision : Si le redémarrage s’aligne avec des mises à jour, validez les politiques de redémarrage, et envisagez de figer/retourner la version du noyau pour un sous-ensemble canari si vous observez de nouveaux crashes.

Trois mini-histoires d’entreprise tirées des tranchées des redémarrages

Mini-histoire 1 : L’incident causé par une mauvaise supposition

Ils avaient un cluster de serveurs de bases de données physiques. Un nouvel ingénieur d’astreinte a vu « Kernel panic » dans les logs du boot précédent et a fait ce que beaucoup font sous stress : blâmer le noyau et commencer à préparer un rollback des mises à jour.

C’était un récit confiant. Trop confiant. Le journal s’est arrêté brusquement quelques secondes après la ligne de panic, et il n’y avait pas de séquence d’arrêt propre. Ils ont supposé que cela signifiait que le panic était la cause et que le redémarrage en était l’effet.

Quelqu’un a finalement lancé ipmitool sel list. Le SEL montrait perte et restauration d’alimentation — deux fois — dans la même minute. La ligne de kernel panic ? Elle venait d’un test antérieur, non lié, où panic-on-oops avait été activé temporairement et jamais désactivé. Le « redémarrage aléatoire » était un événement d’alimentation. La ligne de panic n’était que du bruit de fond proche dans le temps.

La vraie cause racine était en amont : une sortie PDU avec un relais défaillant. La configuration PSU redondante du serveur était correcte, mais les deux PSU étaient branchés sur la même rangée PDU « pour l’instant » pendant une maintenance des mois plus tôt. Personne n’a mis à jour la documentation. Tout le monde a mis à jour ses opinions.

La réparation du PDU et la répartition des alimentations ont arrêté les redémarrages immédiatement. Revenir en arrière sur le noyau aurait été du théâtre — réconfortant, visible, et faux.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une équipe poursuivait la latence. Ils ont optimisé les performances : réglages agressifs des C-state CPU dans le BIOS, désactivation de certaines fonctions d’économie d’énergie, et renforcement de l’interruption coalescing sur les NIC. Les benchmarks se sont améliorés, les courbes semblaient plus propres, et le changement a été validé parce que c’était « juste un tuning de perf ».

Deux semaines plus tard, des redémarrages sporadiques ont commencé. Pas assez fréquents pour être évidents. Assez fréquents pour ruiner la confiance. La suspicion initiale s’est portée sur l’application, bien sûr. Puis sur le noyau. Puis sur le stockage. Puis le réseau. La course habituelle au blâme.

Le vrai problème : le tuning a augmenté la sensibilité à un bug de firmware dans le chemin watchdog/gestion thermique de la plateforme. Sous certains motifs de charge, le BMC interprétait mal un sondage de capteur retardé comme un blocage et envoyait un reset. Les logs OS semblaient propres — pas d’arrêt — parce que l’OS n’a jamais eu l’information. Le SEL montrait des resets watchdog, mais personne ne collectait centralement les SEL.

Ils sont revenus sur les réglages BIOS et ont mis à jour le firmware BMC. Les redémarrages ont cessé. La performance a légèrement baissé. La stabilité est revenue de façon spectaculaire. La leçon n’était pas « ne jamais optimiser ». C’était « considérez le firmware et la gestion d’alimentation comme des dépendances de production, pas comme un terrain de jeu pour jouer au ingénieur matériel ».

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une autre organisation avait une habitude qui semblait douloureusement ennuyeuse : journalisation persistante journald, kdump activé sur tous les nœuds bare‑metal, et un job nocturne qui extrayait l’IPMI SEL dans un système central. Pas d’héroïsme. Pas de « on le fera après le prochain sprint ». C’était déjà fait.

Quand une flotte a commencé à redémarrer sous charge maximale, le premier appel incident était calme. Ils ont récupéré journalctl -b -1 sur quelques nœuds et ont vu des schémas NVMe timeout cohérents. Puis ils ont vérifié le SEL : pas d’événements d’alimentation. Puis les dumps de crash : un sous‑ensemble avait des vmcores avec des piles pointant vers le chemin de récupération du pilote NVMe.

Cela a réduit le périmètre à « interaction firmware/driver de stockage sous charge ». Ils ont coordonné une mise à jour firmware progressive et réduit temporairement la profondeur de queue sur les nœuds affectés. Pas de devinettes. Pas de connaissance tribale. Juste des preuves.

Le résultat n’était pas un uptime magique. C’était un incident contenu : moins de redémarrages surprises, une escalade fournisseur claire, et une trace papier qui justifiait la fenêtre de maintenance. Les pratiques ennuyeuses n’empêchent pas toutes les défaillances. Elles empêchent la seconde défaillance : l’incapacité à comprendre ce qui s’est passé.

Blague #2 : Si vous ne stockez pas les logs de façon persistante, votre serveur redémarrera avec la même assurance qu’un chat qui pousse un verre sur la table — sans remords, sans explication.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom : « Aucun log n’indique le redémarrage »

Cause racine : journal volatile (pas de stockage persistant) ou perte d’alimentation/reset dur empêchant la vidange des logs.

Correctif : Activez journald persistant (/var/log/journal), augmentez la fréquence de flush du journal si nécessaire, et collectez SEL BMC/logs hyperviseur pour couvrir les cas d’alimentation/reset.

2) Symptom : « Ça redémarre toujours sous charge I/O »

Cause racine : timeouts de stockage (réinitialisations contrôleur NVMe, firmware HBA, instabilité multipath) provoquant des tâches bloquées et watchdog/panic.

Correctif : Inspectez les logs noyau pour les timeouts, vérifiez SMART/NVMe, validez les versions firmware, réduisez la profondeur de queue en mitigation, et planifiez le remplacement matériel quand les compteurs d’erreurs augmentent.

3) Symptom : « Kernel panic dans les logs, donc c’est forcément un bug noyau »

Cause racine : causalité inversée. Le panic peut être secondaire à des erreurs matérielles ou à un reset forcé ; parfois panic-on-oops est activé, transformant des défauts de pilote en redémarrages.

Correctif : Confirmez avec SEL et MCE ; vérifiez /proc/sys/kernel/panic et les réglages panic-on-oops ; capturez un vmcore et analysez les stacks.

4) Symptom : « Les redémarrages surviennent après des mises à jour mais pas immédiatement »

Cause racine : régression de noyau/driver déclenchée par une charge spécifique ; ou automatisation qui redémarre selon un calendrier après patch.

Correctif : Corrélez les timestamps de mise à jour avec les boot IDs ; vérifiez les logs d’orchestration ; rollback du noyau pour un sous‑ensemble canari et comparez la stabilité.

5) Symptom : « La VM redémarre mais les logs guest sont propres »

Cause racine : reset de l’hyperviseur, crash de l’hôte, ou cycle d’alimentation VM. Le guest OS n’a jamais vu d’arrêt.

Correctif : Utilisez les logs d’événements de l’hyperviseur et les journaux d’audit de la plane de gestion ; traitez-le comme un incident d’infrastructure, pas d’OS invité.

6) Symptom : « Le système de fichiers a été remonté en lecture seule avant le redémarrage »

Cause racine : erreurs du dispositif bloc sous-jacent ; le système de fichiers s’est protégé, les services ont échoué, puis watchdog ou orchestration a redémarré pour « guérir ».

Correctif : Diagnostiquez la couche bloc (SMART/NVMe, câblage, contrôleur), lancez fsck en maintenance, et corrigez le problème de fiabilité du stockage en priorité.

7) Symptom : « Rien d’évident, mais le SEL montre des resets watchdog »

Cause racine : le watchdog matériel a déclenché à cause d’un blocage système, souvent lié à un deadlock de pilote, une tempête d’interruption ou un bug de firmware.

Correctif : Mettez à jour BIOS/BMC/microcode ; vérifiez les versions noyau pour des bugs de lockup connus ; activez kdump ; n’ajustez NMI watchdog qu’après avoir compris la cause racine.

8) Symptom : « Des OOM kills apparaissent avant le redémarrage »

Cause racine : l’épuisement mémoire déclenche des défaillances en cascade ; un watchdog externe ou l’orchestration redémarre le nœud après la mort des services.

Correctif : Implémentez des limites mémoire (cgroups), dimensionnez correctement les instances, ajoutez du swap avec précaution, et ajustez le score OOM pour les services critiques.

Listes de contrôle / plan étape par étape

Étape par étape : investigation d’un hôte unique (30–60 minutes)

1. Confirmez le nombre de boots et le timing : last -x, journalctl --list-boots.
2. Inspectez la fin du boot précédent : journalctl -b -1 avec -p warning d’abord, puis le contexte complet.
3. Classifiez le redémarrage : ordonné vs abrupt (présence d’une séquence d’arrêt, ou coupure des logs).
4. Vérifiez le noyau pour panic/oops/watchdog : grep pour « panic », « oops », « watchdog », « blocked for more than ».
5. Vérifiez les signaux matériels : lignes MCE ; si physique, événements SEL pour alimentation/thermal/watchdog.
6. Vérifiez le stockage : timeouts, réinitialisations, erreurs système de fichiers, données SMART/NVMe.
7. Vérifiez la pression mémoire : lignes OOM killer ; activité swap si vous la consignez.
8. Vérifiez les changements : mises à jour, runs de gestion de configuration, changements firmware, tâches planifiées autour de l’événement.
9. Décidez de l’action suivante : mitiger (réduire la charge, retirer le nœud du service), préserver les preuves (vmcore/logs), escalader (matériel/fournisseur).

Checklist flotte : quand de nombreux nœuds redémarrent (et que tout le monde crie)

• Choisir trois nœuds : un qui a redémarré, un qui ne l’a pas fait, un borderline. Comparez les logs côte à côte.
• Rechercher des signatures communes : mêmes messages de pilote, même modèle de stockage, même firmware, même rack, même build du noyau.
• Diviser par domaine de défaillance : si un seul rack, suspectez l’alimentation/réseau ; si un seul modèle de stockage, suspectez le firmware ; si un seul noyau, suspectez une régression.
• Arrêter l’hémorragie : vider les nœuds, réduire la profondeur de queue, désactiver des flags problématiques, suspendre les redémarrages automatisés.
• Conserver les preuves centralement : copiez les segments /var/log/journal, dumps SEL, vmcores. Les incidents sont temporaires ; les preuves sont optionnelles sauf si vous les rendez obligatoires.

Checklist configuration : quoi mettre en place avant qu’un redémarrage n’arrive

• Journal persistant sur tous les nœuds ; dimensionnez-le correctement.
• Envoi centralisé des logs (et vérifiez-le en interrogeant les logs du dernier boot).
• kdump activé là où c’est faisable, et surveillé pour la création de vmcore.
• Scraping SEL pour le bare metal ; stockez hors hôte.
• Journalisation des changements : mises à jour noyau, firmware, actions d’orchestration, et événements d’audit « qui a redémarré ».

Faits intéressants et contexte historique (parce que l’histoire se répète)

• Fait 1 : wtmp est une tradition Unix depuis des décennies ; c’est grossier, mais toujours l’un des moyens les plus rapides de repérer des motifs de redémarrage.
• Fait 2 : Le tampon circulaire du noyau était historiquement volatile ; le journal systemd a rendu la récupération des messages noyau inter‑boots beaucoup plus simple sur de nombreuses distributions.
• Fait 3 : Les Machine Check Exceptions (MCE) sont un mécanisme au niveau CPU ; Linux ne fait que les rapporter. Si MCE dit « hardware error », ce n’est pas métaphorique.
• Fait 4 : Les watchdogs existent parce que les systèmes bloqués ne peuvent pas être considérés fiables pour se reprendre. Ce sont des outils brusques : utiles, mais ils masquent les causes racines en redémarrant le patient.
• Fait 5 : Le comportement panic anciennement était souvent « halt and wait ». Les défauts de production modernes rebootent souvent après panic pour restaurer le service rapidement — parfois trop rapidement pour capturer les preuves.
• Fait 6 : Les logs SEL basés IPMI vivent en dehors de l’OS. C’est pourquoi ils sont si précieux quand l’OS ne s’est pas arrêté proprement.
• Fait 7 : Les timeouts de stockage se sont améliorés, mais les piles NVMe modernes peuvent encore se bloquer sous certaines combinaisons firmware/driver, surtout quand la récupération d’erreur entre en collision avec un fort niveau de queueing.
• Fait 8 : Les erreurs ECC « corrigées » ne sont pas inoffensives. Une tempête d’erreurs corrigées peut précéder des défaillances non corrigibles et des redémarrages, et peut aussi dégrader les performances.
• Fait 9 : Les journaux et logs ne sont pas garantis d’être vidés sur perte d’alimentation ; c’est pourquoi une journalisation fiable combine persistance et envoi hors hôte.

FAQ

1) Comment distinguer une coupure d’alimentation d’un crash noyau ?

La coupure d’alimentation/reset dur montre généralement une fin abrupte des logs sans séquence d’arrêt. Confirmez avec IPMI SEL (physique) ou événements hyperviseur (VM). Le crash noyau laisse souvent des lignes panic/oops/watchdog et parfois un vmcore kdump.

2) Quelle est la commande la plus utile pour « le boot précédent » ?

journalctl -b -1. Associez-la à -p warning pour réduire le bruit et à --since pour vous concentrer sur les dernières minutes.

3) Pourquoi je vois « Kernel panic » mais la raison du redémarrage reste floue ?

Parce que le panic peut être un symptôme, pas une cause. Vous avez besoin du contexte amont : timeouts stockage, erreurs matérielles MCE, blocages, ou signaux de reset externes. Vérifiez aussi si panic-on-oops était activé.

4) Les redémarrages aléatoires viennent-ils plutôt du logiciel ou du matériel ?

En pratique : un mélange, mais le matériel/alimentation/firmware sont sous‑diagnostiqués parce que les gens regardent seulement les logs OS. Si les logs OS manquent ou sont coupés, assumez que l’OS n’était pas aux commandes.

5) Ma VM « redémarre » mais il n’y a pas d’arrêt dans les logs du guest. Pourquoi ?

L’hyperviseur peut réinitialiser la VM comme si on tirait la prise. Les logs guest ne montreront pas un arrêt gracieux. Vous avez besoin des événements de l’hôte et des logs d’audit de la plane de gestion.

6) Activer kdump vaut‑il la mémoire réservée ?

Pour les systèmes où les crashs noyau ont de l’importance, oui. La mémoire réservée est une prime d’assurance. Sans vmcore, vous restez souvent avec des preuves circonstancielles et des reproches croisés entre fournisseurs.

7) Comment les resets watchdog se relient-ils aux problèmes de stockage ?

Les stalls I/O peuvent bloquer les threads noyau suffisamment longtemps pour que le watchdog considère le système comme figé. Le watchdog est le messager ; les timeouts de stockage peuvent être le message.

8) La corruption de système de fichiers peut‑elle provoquer des redémarrages ?

Les systèmes de fichiers essaient généralement de protéger les données en remontant en lecture seule ou en arrêtant des composants. Le redémarrage survient souvent ensuite : les services échouent, l’orchestration redémarre le nœud, ou le noyau panique à cause d’erreurs bloc sous-jacentes.

9) Pourquoi mes logs manquent juste avant le redémarrage ?

Soit vous utilisez un journal volatile, soit le disque est devenu indisponible, soit le système a perdu l’alimentation. L’absence de logs est un point de donnée : traitez‑la comme un « reset probable » jusqu’à preuve du contraire.

Conclusion : prochaines étapes réalisables aujourd’hui

Si vos serveurs « redémarrent aléatoirement », vous ne traitez pas de l’aléatoire. Vous traitez d’un manque de preuves, d’une attention mal placée, ou des deux. Réparez d’abord les preuves.

1. Rendez journald persistant et vérifiez que vous pouvez interroger journalctl -b -1 après un redémarrage.
2. Activez kdump lorsque c’est pratique, et alertez sur la création de vmcore.
3. Collectez le SEL BMC hors hôte pour le bare metal ; c’est votre détecteur de mensonge pour les événements power/reset.
4. Standardisez un runbook de triage : journal du boot précédent, SEL/hyperviseur, MCE, erreurs stockage — toujours dans cet ordre.
5. Quand vous trouvez la cause, changez quelque chose de durable : mises à jour firmware, corrections d’alimentation, politique de remplacement du stockage, ou stratégie de versions du noyau. Pas seulement un postmortem Slack et une promesse.

L’objectif n’est pas de devenir détective des redémarrages par hobby. L’objectif est que le prochain « il a juste redémarré » se transforme en une réponse en deux captures d’écran et une demande de correction qui tient réellement.