Onde estão os logs de pânico do kernel?

Eu tenho um problema com o Handbrake / ffmpeg. Após aproximadamente 5 minutos de transcodificação, o computador trava. Tenho certeza de que é um pânico do kernel porque o caps-lock começa a piscar.

Existem algumas perguntas lógicas sobre o que fazer e outras sobre erros específicos, mas estou realmente procurando uma coisa: o que aconteceu antes de tudo morrer ?!

Eu verifiquei /var/log/kern.loge tudo o que vejo ao longo do tempo sou eu colocando um DVD e, alguns minutos depois, o sistema inicializando. Sem erros, sem aviso de pânico.

Existe alguma maneira de forçar o pânico a ser registrado? Tenho certeza de que posso reproduzir isso (isso aconteceu 100% das vezes que tentei recentemente), por isso, embora prefira "apenas funcionou", estou feliz o suficiente para reiniciar algumas vezes, se isso puder encontre a causa do pânico.

Todos os logs do sistema no Ubuntu são gerenciados pelos rsyslogquais mantém sua configuração em /etc/rsyslog.confe /etc/rsyslog.d/.

Para mais informações sobre como configurar rsysloge as opções possíveis, visite o rsyslog.conf man page.

Ao abrir, /etc/rsyslog.d/50-default.confvocê pode ver que uma das linhas contém

*.*;auth,authpriv.none -/var/log/syslog*

Significando que o arquivo que você está procurando neste caso é um dos grandes /var/log/sysloglogs que você provavelmente terá.

Você pode ver que o nome do arquivo também começa com a -, isso significa que o arquivo é armazenado em cache antes da gravação, é ótimo, mas pode deixar um log incorreto. O que você quer é que o log seja gravado assim que houver um problema. Remova o traço e reinicie ou recarregue rsysloge, em seguida, deixe o computador travar novamente, verifique /var/log/syslog.

Se realmente é um pânico do kernel, não será gravado em um log por métodos normais. Como o kernel caiu nesse momento, escrever no sistema de arquivos é uma operação arriscada - não é mais possível confiar em grande parte do kernel; portanto, escrever nos logs pode realmente estar espalhando porcaria aleatória sobre o seu gerenciador de inicialização!

Em vez disso, você pode despejar o conteúdo da memória no seu swap e depois depurá-lo mais tarde. Isso é conhecido como travamento do kernel / core dump.

O Wiki do Ubuntu tem um CrashdumpRecipe que pode ser útil - embora pareça um pouco desatualizado, acho que não deveria ter mudado muito.

Porta serial

A porta serial é um mecanismo simples de comunicação de baixo nível entre computadores.

Vantagens:

• configuração simples uma vez (se você tiver o hardware)
• confiável, uma vez que a transmissão de dados depende apenas de uma API de fios e kernel simples, que é menos provável de ser afetada pelo pânico do que o subsistema TCP / IP.

Desvantagens:

• a maioria dos laptops modernos não tem mais a porta serial (exposta?) para economizar espaço. Mas desktops e máquinas virtuais ainda funcionam.
• você também precisa de um segundo computador com porta serial para receber os dados, mas esse é o caso de basicamente todas as placas de desenvolvimento incorporadas, como o Raspberry Pi.
• limitado pelo comprimento do cabo serial da camada física, diferentemente das redes TCP / IP que são ilimitadas. No entanto, isso pode ser resolvido com um dispositivo que faz interface entre serial e TCP / IP. Mas existem dispositivos que se convertem entre os dois.

A porta serial fica assim:

e no RPI está disponível através do GPIO.

Em seguida, se você tiver o hardware necessário, conecte-se do segundo computador ao computador principal com:

screen /dev/ttyS0 115200

Isso realmente lhe dá uma concha.

Em seguida, na máquina principal, inicie a operação que entra em pânico.

Quando o pânico acontece, o despejo de pânico é transmitido para a segunda máquina e você pode ver tudo rolando a tela para cima no terminal.

Outros métodos

Existem também outros métodos que superam as limitações de hardware mencionadas acima, ao custo de serem mais complexas e menos confiáveis. Métodos notáveis:

• netdump: transmite o pânico pelo TCP / IP. Confia no subsistema TCP / IP não sendo corrompido.
• kdump: parece ser o mecanismo subjacente do linux-crashdump mencionado em: https://askubuntu.com/a/104793/52975 Inicializa um segundo kernel do Linux para examinar o kernel travado. O que poderia dar errado?! :-)

Veja também esta ótima resposta: https://unix.stackexchange.com/questions/60574/determining-cause-of-linux-kernel-panic

Depuração de etapas

Por fim, obter saída de pânico exige que algumas funcionalidades do kernel funcionem, e qualquer funcionalidade do kernel pode ser corrompida pelo pânico.

Mas quem precisa de pânico se você pode usar o GDB no kernel? Se você é tão hardcore, dê uma olhada:

• QEMU ou outras VMs: https://stackoverflow.com/a/42316607/895245
• JTAG

Todo problema cai quando você tem visibilidade total (e tempo suficiente!).