Panique du noyau : quand Linux dit « non » en public

Ce qu’est réellement une panique du noyau (et ce que ce n’est pas)

Une panique du noyau Linux, c’est le noyau admettant qu’il ne peut pas continuer en sécurité. Ce n’est pas « l’application a planté ». Ce n’est pas « la machine est lente ». C’est le cœur du système d’exploitation décidant que continuer risquerait de corrompre des données, de perdre la sécurité mémoire, ou d’entrer dans un interblocage permanent. Alors il s’arrête.

Les panics sont délibérées. Elles sont généralement déclenchées par un chemin de code qui appelle panic() (ou une exception irrécupérable qui y mène). Le noyau imprime ce qu’il connaît, souvent une trace de pile, l’état CPU, et la raison (parfois utile, parfois vexante). Vous verrez souvent une de ces lignes :

• « Kernel panic – not syncing: Attempted to kill init! » — PID 1 est mort ou devenu irrécupérable.
• « Kernel panic – not syncing: VFS: Unable to mount root fs » — le noyau ne peut pas monter le système de fichiers racine.
• « Fatal exception in interrupt » — quelque chose a cassé à un très mauvais moment.
• « BUG: unable to handle kernel NULL pointer dereference » — bug du noyau ou comportement fautif d’un pilote, peut-être corruption matérielle.
• « soft lockup » / « hard lockup » — CPU bloqué, le watchdog peut escalader en panic selon la configuration.

Ce que ce n’est pas :

• OOM kill — le noyau tuant un processus pour cause de pression mémoire est un comportement normal. Vous perdez une charge, pas le noyau. Une panique causée par OOM est rare et généralement liée à la configuration.
• Crash en espace utilisateur — systemd, java, nginx, votre script Python « critique »… aucun de ceux-là n’est une panique du noyau. C’est important, mais cela relève d’une autre chaîne d’outils.
• Réinitialisation matérielle — redémarrage soudain sans logs peut être dû à l’alimentation, au watchdog BMC, ou à un triple fault. Traitez cela différemment jusqu’à preuve du contraire.

Et oui, les panics ont tendance à se produire en public — pendant des déploiements, des fenêtres de maintenance, et des démonstrations exécutives. Le noyau a un sens de la comédie impeccable.

Une citation à garder sur votre bureau : « idée paraphrasée » — John Allspaw : la fiabilité vient de la conception des systèmes en supposant les défaillances, pas d’espérer qu’elles n’arrivent pas.

Blague n°1 : Une panique du noyau est la seule fois où votre serveur est vraiment honnête sur ses sentiments : « Je ne peux même pas. »

Faits intéressants et un peu d’histoire

Le contexte compte parce qu’une grande partie du comportement des panics est du bagage historique : anciens comportements par défaut, promesses de compatibilité, et des décennies de « ça va » empilées sur « ça brûle ». Voici quelques faits concrets qui apparaissent souvent dans les enquêtes réelles :

1. « Panic » est plus ancien que Linux. Les noyaux UNIX utilisaient des chemins de panic pour arrêter le système en cas de risque de corruption bien avant l’existence de Linux.
2. Linux a gardé le message lapidaire volontairement. Le noyau imprime directement sur les consoles et les lignes série parce que celles-ci ont tendance à fonctionner quand tout le reste est mort.
3. SysRq est un outil de survie, pas un jouet. Les touches Magic SysRq ont existé pour reprendre le contrôle lors de blocages ; c’est toujours l’un des rares outils de dernier recours quand l’espace utilisateur est grillé.
4. kdump n’a pas toujours été courant. Le dumping des crashs a mûri au fil des années ; le débogage Linux ancien souvent signifiait « reproduire via console série » et beaucoup de douleur.
5. « Oops » n’est pas « panic ». Un oops est une exception du noyau qui peut permettre de continuer ; un panic est le noyau refusant de continuer. Les équipes d’exploitation traitent les oops répétés comme des pré-panics.
6. Les watchdogs peuvent forcer des panics. Les watchdogs soft/hard existent parce que les blocages silencieux sont pires que les morts bruyantes en production.
7. initramfs a rendu le démarrage à la fois meilleur et plus fragile. Il permet un démarrage modulaire et un early userspace, mais ajoute aussi une nouvelle zone de défaillance : pilotes manquants, UUID erronés, hooks cassés.
8. Les modules hors arbre multiplient les risques. Les pilotes propriétaires et les modules qui ne suivent pas l’API interne du noyau sont des sources fréquentes de « marche jusqu’à ce que ça casse ».
9. Le stockage moderne est un champ de mines adjacent au noyau. NVMe, multipath, iSCSI, RDMA, et des systèmes de fichiers comme ZFS apportent performance et complexité. La complexité adore panique à 3h du matin.

Feuille de route pour un diagnostic rapide

Voici la séquence « arrêter l’hémorragie ». Faites-la de la même manière à chaque fois, même quand Slack hurle. Surtout quand Slack hurle.

Première étape : déterminer si c’était une panique, une réinitialisation ou un événement d’alimentation

• Y avait-il un message de panic sur la console/IPMI ? Si oui, c’est probablement une vraie panique.
• Avez-vous un vmcore ? Si oui, c’était un chemin de crash relativement contrôlé (panic ou déclenché par kdump).
• Aucun log du tout ? Soupçonnez d’abord l’alimentation, le watchdog firmware, la réinitialisation BMC, ou une défaillance matérielle.

Deuxième étape : classer la panique en une phrase

Vous voulez une étiquette rapide qui oriente les étapes suivantes :

• Panique au démarrage : VFS ne peut pas monter la racine, problèmes d’initramfs, cmdline du noyau erronée.
• Panique en runtime : bug de pilote, bug de système de fichiers, corruption mémoire, watchdog de blocage.
• Panique sur le chemin de données : timeouts stockage, réinitialisations NVMe, firmware HBA, tempêtes multipath, plantages ZFS.
• Matériel mémoire/CPU : MCE, erreurs EDAC, oops aléatoires sur des sous-systèmes non reliés.

Troisième étape : choisir la source de preuve la plus rapide

• Meilleur : vmcore + symboles debug vmlinux correspondants.
• Bon : journal persistant + sortie console de panic + dmesg du boot précédent.
• Acceptable : BMC System Event Log, logs console série, netconsole.
• Mauvais : « ça a rebooté, personne n’a rien vu. » (Vous corrigerez ça plus tard.)

Quatrième étape : décider de garder le nœud en ligne

• Événement isolé et pas de risque de corruption : relancer, capturer les logs, planifier une analyse approfondie.
• Répétition ou panique sur le chemin de stockage : mettre le nœud en quarantaine. Priorité : prévenir la corruption du système de fichiers et la propagation de la défaillance.
• Possible erreur matérielle mémoire : retirer la machine. Ne pas exécuter de charges critiques sur une machine qui pourrait mentir sur les bits.

Capturer les preuves : rendre les panics diagnostiquables

Les panics ne sont rarement « une fois et terminé ». Le noyau a paniqué pour une raison. Votre travail est de faire en sorte que le prochain laisse une preuve.

Kdump : la différence entre deviner et savoir

kdump réserve de la mémoire pour un crash kernel. Quand le noyau principal panique, il démarre le crash kernel et écrit un fichier vmcore. Ce dump est volumineux, lent, et précieux.

Mode de défaillance courant : vous avez « activé kdump » mais jamais testé, donc quand la vraie panique arrive, il n’écrit rien. Ce n’est pas un manque de surveillance ; c’est un manque de direction.

Logs persistants : journal et console

Faites en sorte que le système conserve les logs entre les redémarrages. Capturez aussi la sortie du noyau quelque part qui survive : logging console série, capture SOL BMC, netconsole, ou pstore.

Note pour les ingénieurs stockage : les panics peuvent être auto-infligés

Si votre racine est sur une pile de stockage complexe (dm-crypt + LVM + mdraid + multipath + iSCSI + thin provisioning), votre chemin de démarrage est une machine de Rube Goldberg. Ça peut fonctionner. Ça peut aussi échouer de façon spectaculaire.

Blague n°2 : Démarrer depuis un stockage réseau, c’est comme faire confiance à un parachute emballé par un comité — possible, mais vous voulez une checklist.

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

Voici de vraies tâches « faites ça maintenant ». Chacune indique ce que vous regardez et quelle décision en découle.

Task 1: Confirm previous boot crashed and why (journal)

cr0x@server:~$ journalctl -b -1 -k -p err..alert --no-pager | tail -n 40
Jan 21 02:13:19 server kernel: BUG: unable to handle page fault for address: ffff8a0a00000000
Jan 21 02:13:19 server kernel: #PF: supervisor read access in kernel mode
Jan 21 02:13:19 server kernel: Kernel panic - not syncing: Fatal exception
Jan 21 02:13:19 server kernel: CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.1.0-18-amd64 #1 Debian 6.1.76-1
Jan 21 02:13:19 server kernel: Call Trace:
Jan 21 02:13:19 server kernel:  ? nvme_complete_rq+0x2a/0xd0
Jan 21 02:13:19 server kernel:  ? blk_mq_end_request+0x2b/0x60

Ce que cela signifie : Le boot précédent s’est terminé par une exception du noyau ayant escaladé en panic. La pile mentionne le chemin de complétion NVMe.

Décision : Traiter comme une panique en runtime probablement liée au pilote/firmware de stockage. Mettre le nœud en quarantaine si c’est dans une flotte ; ne pas juste redémarrer et oublier.

Task 2: Check reboot reason and boot IDs (quick sanity)

cr0x@server:~$ last -x | head -n 8
reboot   system boot  6.1.0-18-amd64 Tue Jan 21 02:15   still running
crash    system crash 6.1.0-18-amd64 Tue Jan 21 02:13 - 02:15  (00:02)
reboot   system boot  6.1.0-18-amd64 Mon Jan 20 22:01 - 02:13  (04:12)

Ce que cela signifie : « crash » indique un arrêt non propre cohérent avec une panique ou une réinitialisation.

Décision : Si « crash » s’aligne avec les lignes de panic du journal, poursuivre l’analyse du noyau. Si le journal est vide, pivoter vers une enquête hardware/firmware.

Task 3: See if kdump produced a vmcore

cr0x@server:~$ ls -lh /var/crash
total 2.3G
drwxr-xr-x 2 root root 4.0K Jan 21 02:15 127.0.1.1-2026-01-21-02:15:08

Ce que cela signifie : Un répertoire de crash existe ; il contient probablement un vmcore et des métadonnées.

Décision : Préserver. Copier hors du nœud avant que des tâches de « nettoyage » ne s’exécutent, et avant qu’on réimage le serveur.

Task 4: Validate kdump service state (and whether it was armed)

cr0x@server:~$ systemctl status kdump-tools --no-pager
● kdump-tools.service - Kernel crash dump capture service
     Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled)
     Active: active (exited) since Tue 2026-01-21 02:16:01 UTC; 3min ago
       Docs: man:kdump-tools(8)
    Process: 612 ExecStart=/etc/init.d/kdump-tools start (code=exited, status=0/SUCCESS)

Ce que cela signifie : Le service est activé et semble sain maintenant. Ce n’est pas la preuve qu’il a fonctionné au moment du crash, mais c’est un début.

Décision : Si désactivé ou en échec, prioriser la fiabilité des dumps avant de chercher la cause racine. Pas de dump, pas de certitude.

Task 5: Confirm crashkernel reservation actually exists

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.1.0-18-amd64 root=UUID=8b2c1d90-0a0f-4db3-bf90-4b3d6f1c2f3e ro quiet crashkernel=512M

Ce que cela signifie : Mémoire réservée pour le kernel de crash via la ligne de commande du noyau.

Décision : Si absent, l’ajouter et redémarrer durant une fenêtre de maintenance. Sinon votre histoire « kdump activé » est une fiction.

Task 6: Check for Machine Check Exceptions (hardware canaries)

cr0x@server:~$ journalctl -k -b -1 | egrep -i "mce|machine check|hardware error|edac" | tail -n 20
Jan 21 02:12:57 server kernel: mce: [Hardware Error]: Machine check events logged
Jan 21 02:12:57 server kernel: EDAC MC0: 1 CE memory scrubbing error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0

Ce que cela signifie : Des erreurs ECC corrigées ont eu lieu. Une erreur corrigée n’est pas une condamnation immédiate ; ce sont les motifs qui comptent.

Décision : Si vous voyez des corrections répétées ou des erreurs non corrigées, traiter comme un défaut matériel. Ouvrir un ticket auprès du fournisseur et retirer le nœud des charges critiques.

Task 7: Inspect PCIe/NVMe error patterns before the panic

cr0x@server:~$ journalctl -k -b -1 | egrep -i "nvme|pcie|aer|reset|timeout" | tail -n 40
Jan 21 02:12:58 server kernel: nvme nvme0: I/O 487 QID 7 timeout, aborting
Jan 21 02:12:58 server kernel: nvme nvme0: Controller is down; will reset: CSTS=0x3
Jan 21 02:12:59 server kernel: pcieport 0000:00:1d.0: AER: Corrected error received: 0000:03:00.0
Jan 21 02:13:00 server kernel: nvme 0000:03:00.0: enabling device (0000 -> 0002)

Ce que cela signifie : Timeouts et réinitialisations de contrôleur précèdent souvent des panics si un pilote atteint un chemin bug ou si le périphérique se comporte mal.

Décision : Vérifier les combinaisons firmware/driver NVMe ; envisager mise à jour du firmware, mise à jour du noyau, ou échange du périphérique. Vérifier aussi les slots/backplane PCIe.

Task 8: Verify root filesystem and initramfs content (boot panics)

cr0x@server:~$ lsinitramfs /boot/initrd.img-6.1.0-18-amd64 | egrep -i "nvme|ahci|virtio|dm-crypt|lvm" | head
usr/lib/modules/6.1.0-18-amd64/kernel/drivers/nvme/host/nvme.ko
usr/lib/modules/6.1.0-18-amd64/kernel/drivers/md/dm-crypt.ko
usr/lib/modules/6.1.0-18-amd64/kernel/drivers/md/dm-mod.ko
usr/lib/modules/6.1.0-18-amd64/kernel/drivers/md/raid1.ko
usr/lib/modules/6.1.0-18-amd64/kernel/drivers/scsi/sd_mod.ko

Ce que cela signifie : Les pilotes d’early-boot sont présents. L’absence de modules de stockage ou de crypto en early-boot est un déclencheur classique de « VFS: unable to mount root ».

Décision : Si des modules requis manquent, reconstruire l’initramfs et vérifier la ligne de commande du noyau. Ne pas redémarrer en espérant que ça se corrige tout seul.

Task 9: Confirm block device identity and UUID mapping

cr0x@server:~$ blkid | head -n 6
/dev/nvme0n1p1: UUID="8b2c1d90-0a0f-4db3-bf90-4b3d6f1c2f3e" TYPE="ext4" PARTUUID="0f12c0d4-01"
/dev/nvme0n1p2: UUID="0d6d8a8c-0d90-4d8b-9d8b-7c8e6a6e2c1a" TYPE="swap" PARTUUID="0f12c0d4-02"

Ce que cela signifie : L’UUID existe et correspond à la cmdline (comparer avec /proc/cmdline).

Décision : Si mismatch, corriger la configuration du chargeur de démarrage. Si les noms de périphériques ont changé (commun avec HBAs/multipath), arrêter d’utiliser /dev/sdX dans les configs de boot.

Task 10: Inspect kernel taint status (is a third-party module involved?)

cr0x@server:~$ cat /proc/sys/kernel/tainted
0

Ce que cela signifie : 0 signifie non tainted : pas de flags connus comme modules propriétaires ou chargements forcés.

Décision : Si tainted est non nul, décoder et considérer les modules tiers comme suspects. La prise en charge change vite si vous exécutez du code hors arbre.

Task 11: Identify the exact kernel build and package provenance

cr0x@server:~$ uname -a
Linux server 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2025-12-18) x86_64 GNU/Linux

Ce que cela signifie : Version du noyau, packaging distribution, et date de build. C’est votre base pour rechercher des régressions connues.

Décision : Si la panique a commencé après une mise à jour du noyau, envisager un rollback comme containment pendant l’analyse, surtout pour des régressions de pilotes.

Task 12: Check filesystem integrity signals after reboot (don’t guess)

cr0x@server:~$ dmesg | egrep -i "EXT4-fs|XFS|BTRFS|ZFS|recovery|journal" | tail -n 30
[    2.911234] EXT4-fs (nvme0n1p1): recovery complete
[    2.911980] EXT4-fs (nvme0n1p1): mounted filesystem with ordered data mode. Quota mode: none.

Ce que cela signifie : Le système de fichiers a rejoué son journal proprement. Bonne nouvelle ; vérifiez néanmoins les données applicatives si nécessaire.

Décision : Si vous voyez des avertissements de corruption, planifier un fsck/xfs_repair hors ligne et garder le nœud hors service jusqu’à vérification.

Task 13: Check for lockups that might have escalated

cr0x@server:~$ journalctl -k -b -1 | egrep -i "soft lockup|hard lockup|watchdog" | tail -n 30
Jan 21 02:12:50 server kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [kworker/7:2:238]
Jan 21 02:13:12 server kernel: Kernel panic - not syncing: softlockup: hung tasks

Ce que cela signifie : Le watchdog du noyau a détecté un CPU bloqué et a paniqué. Souvent dû à des deadlocks dans des pilotes, des stalls de stockage, ou des tempêtes d’interruptions.

Décision : Traiter comme un problème noyau/driver ou un stall matériel. Vérifier la latence stockage, la distribution des IRQ, et les changements récents de pilotes. Ne pas « corriger » en désactivant le watchdog à moins d’aimer les blocages silencieux.

Task 14: Pull BMC/firmware event logs when panics are suspiciously quiet

cr0x@server:~$ ipmitool sel list | tail -n 8
  91 | 01/21/2026 | 02:13:18 | System Boot Initiated | Initiated by watchdog | Asserted
  92 | 01/21/2026 | 02:13:19 | Power Unit | Power off/down | Asserted
  93 | 01/21/2026 | 02:15:02 | Power Unit | Power cycle | Asserted

Ce que cela signifie : Un watchdog a initié un redémarrage/cycle d’alimentation. Cela peut provenir d’un blocage du noyau, d’une politique BMC, ou d’un défaut plateforme.

Décision : Si le BMC a déclenché des réinitialisations, enquêter sur la santé matérielle, la configuration du watchdog, et si l’OS était suffisamment vivant pour logger. Cela change complètement le récit de l’incident.

Task 15: Open the vmcore with crash (when you have real evidence)

cr0x@server:~$ crash /usr/lib/debug/boot/vmlinux-6.1.0-18-amd64 /var/crash/127.0.1.1-2026-01-21-02:15:08/vmcore
crash 8.0.2
VMLINUX: /usr/lib/debug/boot/vmlinux-6.1.0-18-amd64
DUMPFILE: /var/crash/127.0.1.1-2026-01-21-02:15:08/vmcore  [PARTIAL DUMP]
CPUS: 16
DATE: Tue Jan 21 02:13:19 2026
PANIC: "Kernel panic - not syncing: Fatal exception"
TASKS: 3247

Ce que cela signifie : Vous avez un dump exploitable et la chaîne de panic. Vous pouvez maintenant inspecter les piles, tâches, et l’état du noyau.

Décision : Si le vmcore s’ouvre proprement, arrêter les théories dans le chat et commencer à extraire une hypothèse de cause racine basée sur des preuves.

Task 16: Get the backtrace and identify the subsystem

cr0x@server:~$ crash -c "bt" /usr/lib/debug/boot/vmlinux-6.1.0-18-amd64 /var/crash/127.0.1.1-2026-01-21-02:15:08/vmcore
PID: 0      TASK: ffffffff81a13c80  CPU: 3   COMMAND: "swapper/3"
 #0 [ffffb3b740003d90] machine_kexec at ffffffff8105b2ad
 #1 [ffffb3b740003df0] __crash_kexec at ffffffff8112a7b2
 #2 [ffffb3b740003ec0] panic at ffffffff8122c1e5
 #3 [ffffb3b740003f40] oops_end at ffffffff810f3b9a
 #4 [ffffb3b740003f60] page_fault_oops at ffffffff8107d1d2
 #5 [ffffb3b740003fd0] exc_page_fault at ffffffff81c0167a
 #6 [ffffb3b7400040b0] asm_exc_page_fault at ffffffff81e00b2b
 #7 [ffffb3b740004140] nvme_complete_rq at ffffffff815a1e2a

Ce que cela signifie : Le contexte du plantage pointe vers la gestion de complétion NVMe. Cela ne prouve pas que NVMe est « le coupable », mais c’est votre meilleur indice.

Décision : Corréler avec les timeouts/réinitialisations NVMe, la version du firmware, et les problèmes connus du noyau. Envisager mise à jour firmware ou noyau, ou échange matériel pour confirmer.

Modes de défaillance qui provoquent réellement des panics

1) Au démarrage : impossible de monter la racine

Les panics mentionnant VFS, root=, initramfs, ou « not syncing » pendant le démarrage sont souvent des problèmes de configuration ou de packaging. Le noyau ne peut pas continuer parce qu’il ne trouve pas ou ne peut pas monter /. Causes possibles :

• Mauvais root=UUID= après remplacement de disque ou clonage.
• Initramfs sans pilotes de stockage (fréquent après des installations de noyau ou images personnalisées).
• Racine chiffrée/LVM où les hooks n’ont pas été construits, ou /etc/crypttab modifié sans régénérer l’initramfs.
• Changements de nommage multipath provoquant une confusion sur le périphérique racine.

Que faire : Confirmer la cmdline, vérifier les UUID, inspecter l’initramfs, et démarrer en rescue si nécessaire. Rebuilder l’initramfs est souvent la bonne correction. Réinstaller l’OS est généralement une solution paresseuse.

2) En runtime : chemins de pilote bogués (réseau, GPU, stockage, FS)

Les pilotes s’exécutent en espace noyau. Quand ils plantent, ils plantent avec des privilèges. Les pilotes de stockage sont particulièrement épicés car ils impliquent interruptions, mappage DMA, timeouts, et retries sous forte charge.

Que faire : Corréler la trace de panic avec les logs du noyau : réinitialisations, timeouts, messages AER, fluctuations de lien. Si vous voyez le noyau « tainted », traiter les modules hors arbre comme suspects.

3) Corruption mémoire (matériel ou logiciel) qui ressemble à tout

Les panics les plus irritants sont ceux qui n’attachent pas à un seul sous-système. Aujourd’hui c’est ext4. Demain c’est TCP. La semaine prochaine c’est l’allocateur de pages. Ce motif signifie souvent corruption mémoire — parfois bug du noyau, souvent matériel (DIMM, CPU, carte mère) ou réglages instables d’overclock/undervolt sur des serveurs « performance ».

Que faire : Chercher des signaux MCE/EDAC, lancer des tests mémoire en maintenance, échanger DIMMs/hôtes, et comparer signatures de crashs à travers les nœuds. Si plusieurs piles non liées apparaissent, arrêter de blâmer « le noyau » génériquement et traiter l’hôte comme suspect.

4) Panics induites par watchdogs suite à des blocages

Les soft lockups signifient que le scheduler du noyau n’avance pas sur un CPU. Les hard lockups sont pires. Les watchdogs existent parce que les blocages silencieux sont un poison opérationnel : votre nœud reste « up » mais ne fait rien.

Que faire : Ne pas désactiver les watchdogs comme premier réflexe. Enquêter sur ce qui tournait, les tempêtes d’IRQ, la latence stockage, et les deadlocks. Utiliser vmcore pour trouver tâches bloquées et verrous quand c’est possible.

5) Cas limites du système de fichiers et de la pile de stockage

Les systèmes de fichiers peuvent paniquer le noyau quand des invariants internes sont brisés (ou quand le noyau choisit d’arrêter plutôt que risquer la corruption). Certains sont plus « panique-compatibles » que d’autres, souvent par conception. Les piles de stockage peuvent déclencher des panics via des bugs, la pression mémoire, ou des problèmes de couche block.

Que faire : Traiter le chemin de stockage comme un système : firmware, câblage/backplane, erreurs PCIe, paramètres multipath, timeouts, profondeurs de file d’attente, et version du noyau. Une panique noyau liée au stockage est rarement « juste du stockage » ou « juste le noyau ». C’est l’interface entre les deux.

Trois mini-récits du monde de l’entreprise (anonymisés)

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Ils avaient une flotte de nœuds Linux démarrant depuis des NVMe locaux, avec un petit RAID1 pour la racine. Quelqu’un a remplacé un disque défaillant pendant une maintenance de routine. Tout allait bien : pas d’alertes, pas d’impact client, swap propre.

Puis au redémarrage suivant, le nœud est tombé dans une panique : VFS: Unable to mount root fs on unknown-block. L’on-call a supposé une « mauvaise mise à jour du noyau » parce que le reboot coïncidait avec du patching. Ils ont rollbacké le noyau. Même panic. Ils ont réinstallé le bootloader. Même panic. Ils ont commencé à maugréer sur les noyaux vendor et la malchance.

Le vrai problème était plus simple et plus embarrassant : la config du bootloader faisait référence au périphérique racine par un UUID obsolète copié depuis une image plus ancienne. Le système survivait parce que l’ancien disque existait encore et l’ordre de boot était « chanceux ». Le remplacement a changé l’énumération juste assez pour casser la chance.

La correction a été d’utiliser des identifiants stables systématiquement (UUID/PARTUUID partout), de reconstruire l’initramfs, et de valider que le chemin de boot correspond à la réalité. Le changement durable a été culturel : plus de configs de boot « ça ira ». Le boot fait partie de la production.

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

Une initiative de performance visait la latence IO dans un cluster d’analytics chargé. Quelqu’un a ajusté des paramètres NVMe, modifié les profondeurs de file, et activé une gestion d’alimentation CPU agressive pour « réduire le jitter ». Les benchmarks étaient excellents. Tout le monde était content.

Une semaine plus tard, des nœuds ont commencé à paniquer sous pic de charge. Les traces pointaient la voie de complétion du stockage et parfois le scheduler. C’était intermittent, impossible à reproduire en labo, et ne survenait que quand le système était à la fois CPU-bondé et IO-bondé. C’est la combinaison où les optimisations « presque sûres » meurent.

Après une analyse vmcore douloureuse et beaucoup de corrélations, ils ont trouvé le motif : une combinaison firmware/driver n’aimait pas les nouvelles transitions d’état d’alimentation à l’échelle. L’« optimisation » augmentait le taux de réinitialisations du contrôleur et provoquait une course sur un chemin de code rarement utilisé. La panique n’était pas due uniquement au réglage d’alimentation — c’était l’interaction.

La bonne action a été ennuyeuse : revenir sur le réglage de gestion d’alimentation, mettre à jour le firmware NVMe en rollout contrôlé, et épingler une version de noyau connue pour fonctionner avec ce matériel. La latence a empiré légèrement. La disponibilité s’est beaucoup améliorée. L’entreprise a préféré la disponibilité, étonnamment.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une plateforme liée aux paiements exploitait une flotte mixte avec un contrôle strict des changements. Leurs mises à jour noyau étaient palierées, leur configuration kdump testée chaque trimestre, et la sortie console série capturée centralement. Personne n’aimait ça. Tout le monde en bénéficiait.

Une nuit, un sous-ensemble de nœuds a paniqué après un flap du chemin de stockage durant une maintenance du datacenter. La panique est survenue vite, et les nœuds ont redémarré. Le service est resté disponible car l’ordonnanceur a drainé automatiquement les nœuds quand les heartbeats ont échoué.

Le lendemain, au lieu de disputes, ils avaient des artefacts : vmcores, logs console, et une timeline claire grâce au journal persistant. Les dumps montraient des tâches bloquées dans la couche block après des timeouts répétés, et les logs console capturaient des erreurs AER PCIe juste avant la panique.

La correction n’était pas un patch noyau magique. C’était remplacer un backplane défaillant et mettre à jour un bundle de firmware que le fournisseur recommandait discrètement. Le postmortem a été calme parce que les preuves étaient complètes. Les « pratiques ennuyeuses » n’ont pas empêché la défaillance, mais elles ont empêché le chaos — et c’est l’essentiel pour l’opérationnel.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: « Kernel panic – not syncing: VFS: Unable to mount root fs » after an update

Cause racine : Initramfs sans module de stockage/crypto requis, ou mismatch d’UUID de root après changement d’image.

Correctif : Démarrer un kernel rescue, vérifier l’intention de /proc/cmdline vs la réalité de blkid, reconstruire l’initramfs (dracut/update-initramfs), et réinstaller le bootloader si besoin.

2) Symptom: Random panics with unrelated stack traces across weeks

Cause racine : Corruption mémoire, souvent matérielle (DIMM) ou instabilité plateforme.

Correctif : Vérifier les logs MCE/EDAC, lancer des diagnostics mémoire, échanger DIMMs/hôtes, et ne pas laisser la machine en production « parce qu’elle a rebooté correctement ».

3) Symptom: Panic mentions « Attempted to kill init! »

Cause racine : PID 1 s’est planté (systemd ou init) ou a été tué suite à une défaillance catastrophique de l’espace utilisateur (racine pleine, binaires corrompus, libc cassée) ou bug noyau.

Correctif : Examiner le journal du boot précédent pour des défaillances espace utilisateur et erreurs de système de fichiers. Valider la santé du stockage. Si PID 1 est mort par SIGKILL dû à OOM, traiter la pression mémoire ; si dû à corruption disque, réparer et restaurer.

4) Symptom: Panic preceded by NVMe timeouts and resets

Cause racine : Bug firmware NVMe, intégrité signal PCIe, régression driver noyau, ou interaction avec la gestion d’alimentation.

Correctif : Corréler les réinitialisations avec la charge et la version du noyau ; mettre à jour le firmware ; envisager mise à jour/rollback du noyau ; vérifier les logs AER ; reseater/remplacer le périphérique ou le slot/backplane.

5) Symptom: « soft lockup » messages then panic

Cause racine : CPU bloqué à cause d’un deadlock de pilote, tempête d’interruptions, ou section non préemptible trop longue sous charge.

Correctif : Utiliser vmcore pour identifier threads et verrous bloqués ; vérifier distribution IRQ et erreurs périphériques ; mettre à jour le noyau si c’est un deadlock connu ; éviter de désactiver le watchdog comme « solution ».

6) Symptom: Panics only on one kernel version across the fleet

Cause racine : Régression noyau ou changement de valeurs par défaut (IOMMU, scheduler, comportement driver).

Correctif : Épingler un noyau connu bon comme mesure de confinement ; tester des versions candidates sur un anneau canari ; rassembler des dumps pour ouvrir un bug upstream/fournisseur avec preuves.

7) Symptom: No panic logs, just sudden reboot

Cause racine : Perte d’alimentation, reset BMC watchdog, bug firmware, ou crash noyau trop précoce pour logger.

Correctif : Récupérer les SEL du BMC, activer console série/netconsole/pstore, et vérifier crashkernel + kdump. Traiter « pas de logs » comme une défaillance d’infrastructure, pas un mystère à tolérer.

8) Symptom: Panic after enabling a “harmless” kernel module

Cause racine : Module hors arbre ou mal testé ; incompatibilité ABI ; noyau tainté causant instabilité.

Correctif : Retirer le module, revenir à la pile prise en charge par le fournisseur, et reproduire en staging. Si vous devez l’exécuter, épingler les versions du noyau et garder un plan de rollback pratiqué.

Listes de contrôle / plan pas à pas

Checklist A: When a node panics in production (first 30 minutes)

1. Contenir : retirer le nœud du load balancer / scheduler ; éviter les crash loops répétés qui usent les disques.
2. Préserver les preuves : confirmer /var/crash ; copier le répertoire de crash vers un stockage sûr ; snapshot des logs.
3. Collecter les logs noyau : journalctl -b -1 -k et dmesg du boot courant.
4. Vérifier les signaux hardware : logs MCE/EDAC, SEL BMC, motifs d’erreurs stockage.
5. Classer : démarrage vs runtime vs chemin stockage vs problème matériel aléatoire.
6. Choisir le containment : rollback noyau/driver, échange matériel, ou quarantaine pour analyse approfondie.

Checklist B: Make future panics diagnosable (one maintenance window)

1. Activer et tester kdump avec un crash contrôlé sur un nœud non critique.
2. S’assurer que la mémoire crashkernel est réservée et suffisante pour votre taille de RAM.
3. Activer un stockage persistant pour journald et vérifier que les logs du boot précédent survivent.
4. Configurer la capture de la console série ou SOL dans votre environnement.
5. Décider où stocker les vmcores et comment ils sont archivés (et qui peut les supprimer).
6. Établir des canaris de mise à jour du noyau et des procédures de rollback qui ne sont pas « prier et redémarrer ».

Checklist C: Storage-path hardening that reduces panic probability

1. Garder le firmware (NVMe/HBA/backplane) aligné avec les recommandations du fournisseur.
2. Standardiser les versions du noyau par génération matérielle ; éviter les « noyaux flocon de neige ».
3. Surveiller et alerter sur les précurseurs : timeouts NVMe, erreurs AER corrigées, réinitialisations de lien.
4. Définir des timeouts et politiques de retry sensés ; un tuning trop agressif peut déclencher des cas limites.
5. Tester les chemins de basculement (multipath, reconstruction RAID) sous charge, pas seulement en slides.

FAQ

1) What’s the difference between a kernel oops and a kernel panic?

Un oops est une exception du noyau qui peut permettre au noyau de continuer (parfois en mode dégradé). Une panic est le noyau qui s’arrête (ou redémarre) parce qu’il ne peut pas continuer en sécurité. Des oops répétés sont souvent le prélude à une panic.

2) Should I set the kernel to auto-reboot on panic?

Dans la plupart des environnements de production, oui : définir un délai raisonnable via kernel.panic pour que le nœud revienne et que votre ordonnanceur puisse remplacer la capacité. Mais associez cela à kdump et à des logs persistants ; redémarrer vite sans preuves, c’est juste de l’amnésie accélérée.

3) Can a full disk cause a kernel panic?

Pas directement dans la majorité des cas, mais cela peut provoquer des défaillances en espace utilisateur qui tuent des processus critiques (y compris PID 1), ce qui peut conduire à « Attempted to kill init ». Un disque plein peut aussi aggraver des chemins de récupération de corruption. Traiter un disque plein comme un bug sérieux de fiabilité.

4) If the stack trace mentions NVMe, is the NVMe drive definitely at fault?

Non. C’est un indice, pas un verdict. Les timeouts NVMe peuvent venir du firmware, du chemin PCIe, de la gestion d’alimentation, de régressions noyau, ou du périphérique lui-même. Corréler avec les resets/timeouts/logs AER et, idéalement, l’analyse du vmcore.

5) Why do panics happen more during heavy IO?

La charge IO forte met en jeu une concurrence complexe : interruptions, mappage DMA, contention de verrous, et récupération d’erreurs. Les bugs et le matériel marginal restent cachés jusqu’à ce que ces chemins soient fortement sollicités. La charge de production est un meilleur test que la plupart des labos.

6) Is it acceptable to disable watchdogs to stop “soft lockup” panics?

Comme confinement temporaire dans un scénario très spécifique, peut-être. Comme solution générale, non. Vous échangez une défaillance bruyante contre un blocage silencieux, ce qui est pire opérationnellement et plus difficile à détecter. Corriger le stall sous-jacent.

7) How do I know if my kernel is “tainted,” and why does it matter?

/proc/sys/kernel/tainted affiche un bitmask. Le taint signale souvent des modules propriétaires, des chargements forcés, ou d’autres conditions qui compliquent le support upstream et peuvent corréler avec l’instabilité. Si le noyau est tainted, scrutez d’abord les modules tiers.

8) Do containers or Kubernetes “cause” kernel panics?

Les conteneurs n’ont pas de privilèges noyau spéciaux, mais ils augmentent la charge, l’utilisation de fonctionnalités noyau (cgroups, overlayfs, réseau), et les motifs de stress. Kubernetes crée aussi un churn rapide qui peut exposer des conditions de course. La panique reste liée au noyau/driver/matériel — mais l’orchestration change l’étendue des dégâts.

9) What’s the single best investment to reduce time-to-root-cause?

Des dumps de crash fiables (kdump) plus une procédure testée pour les récupérer. Tout le reste — arguments, théories, « je l’ai vu une fois » — est plus lent.

Conclusion : prochaines étapes à faire cette semaine

Si vous exécutez Linux en production, vous n’éliminez pas les panics du noyau. Vous les rendez rares, diagnostiquables, et non catastrophiques.

• Choisissez un nœud et prouvez que kdump fonctionne de bout en bout : réservation, déclenchement, capture de vmcore, récupération.
• Faites survivre les logs aux redémarrages et capturez la sortie console quelque part de façon durable.
• Définissez le confinement pour les classes de panic : panics de démarrage, panics sur le chemin de stockage, panics suspectés matériellement.
• Arrêtez de deviner quand vous avez des preuves. Les vmcores transforment le drame en ingénierie.
• Auditez vos « optimisations » — surtout autour de la gestion d’alimentation et du tuning des files d’attente de stockage — car le noyau n’a aucune patience pour les subtilités non testées en vraie charge.

Et quand Linux dit « non » en public, il n’est pas impoli. Il refuse de corrompre vos données en silence. Respectez son honnêteté. Puis allez récupérer le dump.