Kernel panics e dados de falha no Linux: journal do boot anterior, pstore e netconsole

O que é

Quando um sistema Linux entra em panic e reinicia, ou é desligado e religado depois de travar, as evidências ficam em alguns lugares com características de sobrevivência diferentes:

• O journal do boot anterior: se o armazenamento do journald for persistente (Storage= em journald.conf), as mensagens gravadas até a falha sobrevivem em disco. journalctl -b -1 -k seleciona o boot anterior (-b -1) e apenas as mensagens do kernel (-k/--dmesg: "Show only kernel messages"). Verifique isto primeiro; não exige nenhuma configuração especial além de um journal persistente.
• pstore: o subsistema pstore do kernel grava um registro de oops ou panic em um pequeno backend persistente antes de a máquina cair — ramoops (uma região de RAM reservada por parâmetros do kernel ou device tree, que sobrevive a um reset a quente, mas não a uma perda de energia), variáveis UEFI ou armazenamento do firmware da plataforma. Só funciona se esse backend existir e estiver habilitado. Depois do boot seguinte, os registros aparecem como arquivos em /sys/fs/pstore/; onde o systemd-pstore.service está habilitado, ele os grava no journal e, por padrão, os move para /var/lib/systemd/pstore/.
• netconsole: um módulo do kernel (ou driver embutido) que envia as mensagens do log do kernel via UDP, em tempo real, a uma máquina que esteja escutando. É configurado com um parâmetro netconsole= no formato [src-port]@[src-ip]/[dev],[tgt-port]@<tgt-ip>/[tgt-mac]. Como transmite as mensagens à medida que são geradas, pode capturar um panic que nunca chega ao armazenamento local — ao custo de exigir um driver de rede que ainda funcione no momento do panic, um caminho de rede e um receptor já em execução; a entrega por UDP não é garantida.
• kdump, tratado em outro artigo desta série, é algo diferente: após uma falha, faz kexec para um segundo kernel reservado e grava um dump completo da memória (vmcore) para análise posterior, em vez de um trecho de log.

Por que importa

Cada fonte responde a uma pergunta diferente. O journal mostra o que foi registrado até a falha, em um formato familiar. O pstore sobrevive a falhas tão precoces ou graves que nada chegou a ser gravado em disco, mas guarda apenas um registro pequeno e limitado. O netconsole sobrevive a um disco local sem resposta, mas precisa da interface de rede e de um receptor. O kdump oferece o quadro mais completo, mas exige preparação prévia e é relativamente pesado para panics raros.

Como aplicar

• Comece com journalctl -b -1 -k --no-pager após qualquer reinício inexplicado; um resultado vazio ou uma lista de boots curta indica que o journal não foi persistente naquele boot.
• Depois de uma falha, verifique /sys/fs/pstore/ e /var/lib/systemd/pstore/ (ler esses locais exige root), mesmo que o journal não tenha nada; um registro ali é evidência direta de que o pstore capturou o panic.
• Configure o netconsole com antecedência em sistemas em que os panics são difíceis de diagnosticar de outra forma, apontando para uma máquina que já esteja executando um receptor.
• Reserve o kdump para sistemas em que um dump completo da falha justifique o custo de memória e de configuração, e não apenas porque pstore ou netconsole também estão configurados.

Armadilhas

• Presumir que o journal guardou algo: com Storage=auto e sem o diretório /var/log/journal/, ele é volátil e -b -1 simplesmente não mostra nada. mkdir -p /var/log/journal seguido de systemctl restart systemd-journald o torna persistente a partir daí.
• Deixar registros antigos em /sys/fs/pstore/ sem que nada os arquive: os backends são pequenos (o espaço de variáveis UEFI em particular) e o ramoops sobrescreve registros mais antigos; por isso, copie e remova os registros após cada incidente.