Kernel panics et données de crash sous Linux : journal du démarrage précédent, pstore et netconsole

Ce que c'est

Lorsqu'un système Linux subit un panic puis redémarre, ou qu'on le redémarre à froid après un blocage, les traces se trouvent à plusieurs endroits, dont la résistance au crash varie :

• Le journal du démarrage précédent : si le stockage de journald est persistant (Storage= dans journald.conf), les messages écrits jusqu'au crash sont conservés sur disque. journalctl -b -1 -k sélectionne le démarrage précédent (-b -1) et uniquement les messages du noyau (-k/--dmesg : "Show only kernel messages"). C'est la première chose à vérifier ; aucune configuration particulière n'est nécessaire, hormis un journal persistant.
• pstore : le sous-système pstore du noyau écrit un enregistrement d'oops ou de panic dans un petit support persistant avant l'arrêt de la machine. Il peut s'agir de ramoops (une zone de RAM réservée via les paramètres du noyau ou le device tree, qui survit à un reset à chaud mais pas à une coupure d'alimentation), de variables UEFI ou du stockage du firmware de la plate-forme. Cela ne fonctionne que si un tel support est présent et activé. Au démarrage suivant, les enregistrements apparaissent sous forme de fichiers dans /sys/fs/pstore/ ; lorsque systemd-pstore.service est activé, il les écrit ensuite dans le journal et, par défaut, les déplace vers /var/lib/systemd/pstore/.
• netconsole : un module du noyau (ou un pilote intégré) qui envoie les messages du journal noyau en UDP à une machine à l'écoute, en temps réel. Il se configure avec un paramètre netconsole= de la forme [src-port]@[src-ip]/[dev],[tgt-port]@<tgt-ip>/[tgt-mac]. Comme il transmet les messages au fur et à mesure de leur génération, il peut capturer un panic qui n'atteint jamais le stockage local. En contrepartie, il faut un pilote réseau encore fonctionnel au moment du panic, un chemin réseau et un récepteur déjà en cours d'exécution ; la livraison UDP n'est pas garantie.
• kdump, traité ailleurs dans cette série, est encore différent : après un crash, il bascule par kexec vers un second noyau réservé et écrit un dump mémoire complet (vmcore) destiné à une analyse ultérieure, et non un simple extrait de journal.

Pourquoi c'est important

Chaque source répond à une question différente. Le journal montre ce qui a été consigné jusqu'au crash, dans un format familier. pstore résiste à des crashs si précoces ou si graves que rien n'a été écrit sur disque, mais ne contient qu'un enregistrement réduit et borné. netconsole résiste à un disque local qui ne répond plus, mais nécessite l'interface réseau et un récepteur. kdump donne l'image la plus complète, mais demande une préparation préalable et reste relativement lourd pour des panics rares.

Comment l'appliquer

• Commencer par journalctl -b -1 -k --no-pager après tout redémarrage inexpliqué ; un résultat vide ou une liste de démarrages courte signifie que le journal n'était pas persistant pour ce démarrage.
• Après un crash, vérifier /sys/fs/pstore/ et /var/lib/systemd/pstore/ (leur lecture exige les droits root), même si le journal ne contient rien ; la présence d'un enregistrement prouve directement que pstore a capturé le panic.
• Configurer netconsole à l'avance sur les systèmes où les panics sont par ailleurs difficiles à diagnostiquer, en le pointant vers une machine où un récepteur tourne déjà.
• Réserver kdump aux systèmes où un dump complet justifie le coût en mémoire et en configuration, et non simplement parce que pstore ou netconsole sont aussi configurés.

Pièges

• Supposer que le journal a conservé quelque chose : avec Storage=auto et sans répertoire /var/log/journal/, il est volatil et -b -1 n'affiche simplement rien. mkdir -p /var/log/journal suivi de systemctl restart systemd-journald le rend persistant à partir de ce moment.
• Laisser d'anciens enregistrements dans /sys/fs/pstore/ sans rien pour les archiver : les supports sont de petite taille (l'espace des variables UEFI en particulier) et ramoops écrase les enregistrements plus anciens ; il faut donc copier puis supprimer les enregistrements après chaque incident.