Kernel Panic não copia arquivos de log

Question

Eu estava jogando um jogo no Steam e de repente tive um pânico no kernel. Eu desliguei o computador manualmente e inicializei de volta no Linux Mint 17.1 (Cinnamon) de 64 bits, e fui verificar meus arquivos de log em /var/log/ , mas não consegui encontrar nenhuma referência ou qualquer tipo de mensagem relacionada ao pânico do kernel que aconteceu.

É estranho porque nunca descartou o núcleo ou até mesmo anotou isso nos arquivos de log. Como posso ter certeza de que um núcleo é sempre descartado no caso de um pânico do kernel acontecer de novo? Não faz qualquer sentido porque nada foi registrado quando ocorreu um pânico no kernel. Olhando em volta no Google, as pessoas sugerem ler /var/log/dmesg , /var/log/syslog , /var/log/kern.log , /var/log/Xorg.log etc ... mas nada. Nem mesmo no arquivo .Xsession-errors .

Aqui estão algumas fotografias da tela:

Eu sempre posso tirar uma foto da tela quando e se isso acontecer de novo, mas eu só quero ter certeza de que posso obtê-la para despejar o núcleo e criar um arquivo de log em um pânico do kernel.

    

Answer 1

Para ter certeza de que sua máquina gera um arquivo "core" quando ocorre uma falha no kernel, você deve confirmar as configurações de "sysctl" da sua máquina.

IMO, as seguintes devem ser as configurações (mínimo) em /etc/sysctl.conf :

kernel.core_pattern = /var/crash/core.%t.%p
kernel.panic=10
kernel.unknown_nmi_panic=1

Execute sysctl -p depois de fazer alterações no arquivo /etc/sysctl.conf . Você provavelmente também deve mkdir /var/crash , se ainda não existir.

Você pode testar as informações acima gerando um despejo manual usando a chave SysRq (a combinação de teclas para descarregar o núcleo é Alt + SysRq + C ).

    

Answer 2

Quando o kernel entra em pane, significa que algo deu errado no kernel. Escrever arquivos de log e core dumps requer o uso dos drivers para o dispositivo de armazenamento em bloco (seu disco) e o sistema de arquivos (o espaço deve ser alocado e o tamanho do arquivo de log deve ser atualizado). Dado que os serviços que são fornecidos pelo kernel são necessários para escrever arquivos, e o kernel sabe que está em um estado quebrado, ele não pode gravar os arquivos ou registrar qualquer coisa, porque não está mais em um estado seguro, então fazendo qualquer operação pode piorar as coisas e danificar / destruir seu sistema de arquivos. Então você não pode ter o kernel escrito no log nem despejar um core dump quando entrar em pânico.

Agora, o que você pode fazer, se quiser, é configurar o sistema com um kernel de tratamento de falhas, que é um segundo kernel carregado na memória para o qual o controle pode ser transferido se o kernel principal falhar. Desde que o kernel tem drivers e tal, seria capaz de salvar um despejo de memória para você. Esta não é uma configuração muito comum, porém, e usada principalmente para sistemas high-end que exigem alta disponibilidade e onde uma falha é um problema muito sério que deve ser investigado.

Veja por exemplo a opção crashkernel em Kernel Crash Dump em ubuntu.com. (Observe que esta página diz que o mecanismo de despejo de memória do kernel está habilitado por padrão, começando com o Ubuntu 16.04.)

Acredito que o sistema realmente salva o dump em uma parte reservada da memória e depois reinicia, e o kernel salva a memória reservada no disco na próxima inicialização (já que o kernel recém-inicializado está em um estado sã e pode fazer isso).