Kernel panics y datos de fallo en Linux: el journal del arranque anterior, pstore y netconsole

Qué es

Cuando un sistema Linux sufre un panic y se reinicia, o se apaga y enciende tras un bloqueo, las pruebas se encuentran en varios lugares con distinta capacidad de supervivencia:

• El journal del arranque anterior: si el almacenamiento de journald es persistente (Storage= en journald.conf), los mensajes escritos hasta el momento del fallo se conservan en disco. journalctl -b -1 -k selecciona el arranque anterior (-b -1) y solo los mensajes del kernel (-k/--dmesg: "Show only kernel messages"). Conviene consultarlo primero; no requiere más configuración que un journal persistente.
• pstore: el subsistema pstore del kernel escribe un registro del oops o del panic en un pequeño backend persistente antes de que la máquina se detenga. Este backend puede ser ramoops (una región de RAM reservada mediante parámetros del kernel o device tree, que sobrevive a un reinicio en caliente pero no a una pérdida de alimentación), variables UEFI o el almacenamiento del firmware de la plataforma. Solo funciona si hay un backend de este tipo presente y habilitado. Tras el siguiente arranque, los registros aparecen como archivos en /sys/fs/pstore/; si systemd-pstore.service está habilitado, los escribe en el journal y, por defecto, los mueve a /var/lib/systemd/pstore/.
• netconsole: un módulo del kernel (o controlador integrado) que envía los mensajes del registro del kernel por UDP a una máquina a la escucha, en tiempo real. Se configura con un parámetro netconsole= con el formato [src-port]@[src-ip]/[dev],[tgt-port]@<tgt-ip>/[tgt-mac]. Como transmite los mensajes a medida que se generan, puede capturar un panic que nunca llega al almacenamiento local. A cambio, exige un controlador de red que siga funcionando en el momento del panic, una ruta de red y un receptor ya en ejecución; además, la entrega por UDP no está garantizada.
• kdump, tratado en otro artículo de esta serie, es distinto: tras un fallo hace kexec a un segundo kernel reservado y escribe un volcado completo de memoria (vmcore) para analizarlo después, en lugar de un extracto del registro.

Por qué importa

Cada fuente responde a una pregunta diferente. El journal muestra lo que se registró hasta el fallo, en un formato conocido. pstore sobrevive a fallos tan tempranos o graves que no se llegó a volcar nada a disco, pero solo guarda un registro pequeño y limitado. netconsole sobrevive a un disco local que no responde, pero necesita la interfaz de red y un receptor. kdump ofrece la imagen más completa, pero requiere configuración previa y resulta relativamente pesado para panics poco frecuentes.

Cómo aplicarlo

• Empieza con journalctl -b -1 -k --no-pager después de cualquier reinicio inexplicado; un resultado vacío o una lista de arranques corta indica que el journal no fue persistente en ese arranque.
• Tras un fallo, revisa /sys/fs/pstore/ y /var/lib/systemd/pstore/ (para leerlos se necesita root) aunque el journal no contenga nada; un registro allí es una prueba directa de que pstore capturó el panic.
• Configura netconsole con antelación en los sistemas donde, de otro modo, los panics serían difíciles de diagnosticar, apuntando a una máquina que ya tenga un receptor en ejecución.
• Reserva kdump para los sistemas en los que un volcado completo justifique el coste de memoria y de configuración, y no lo uses solo porque pstore o netconsole también estén configurados.

Trampas

• Dar por hecho que el journal conservó algo: con Storage=auto y sin el directorio /var/log/journal/, es volátil y -b -1 simplemente no muestra nada. Ejecutar mkdir -p /var/log/journal y después systemctl restart systemd-journald lo hace persistente a partir de ese momento.
• Dejar registros antiguos en /sys/fs/pstore/ sin que nada los archive: los backends son pequeños (el espacio de variables UEFI en particular) y ramoops sobrescribe los registros más antiguos, así que conviene copiar y eliminar los registros después de cada incidente.