kdump falha ao registrar o evento de falha do servidor

Question

Estou executando o Ubuntu Server 14.04 em uma máquina que está sofrendo falhas aleatórias sob carga. O servidor não é reiniciado independentemente, mas fica inacessível via conexão ssh ou KVM direta.

Eu suspeito de problemas de CPU, mas estou procurando uma arma fumegante, então estou seguindo as instruções aqui:

link

No entanto, nenhum arquivo de log aparece em /var/crash após uma falha natural ou induzida.

Detalhes:

(indiquei uma falha entre cada alteração descrita aqui, sem alteração).

Tudo correu bem até que cheguei a este passo:

$ cat /sys/kernel/kexec_crash_loaded
0

A saída esperada foi 1. Um pouco de pesquisa me levou a /etc/default/kdump-tools , onde eu defini USE_KDUMP=1 . Quando isso não funcionou, adicionei KDUMP_SYSCTL="kernel.panic=60 kernel.panic_on_oops=1" com base na documentação sysctl . Ainda sem alegria, então modifiquei o param diretamente com sysctl -w kernel.panic=60 para supostamente adicionar tempo extra para o kdump fazer o que ele faz.

Em todos os casos, eu corria:

echo c | sudo tee /proc/sysrq-trigger

O computador falharia e reinicializaria como esperado, mas tudo que vejo é isso:

$ ls /var/crash
kexec_cmd

/var/log/kern.log contém apenas entradas de log da inicialização, não das falhas. (Não tenho certeza se isso é esperado, mas eu pensei em mencioná-lo de qualquer maneira.)

Há algo errado com minha configuração?

    

Answer 1

Se /boot estiver em uma partição separada, o Kernel Crash Dump no Ubuntu falhará devido a um --- > bug que ainda existe em 14.04 Trusty, dá para acreditar? Pelo menos é o caso de eu usar o LVM e um /boot separado.

A solução alternativa é

1. unmount /boot e, em seguida, montá-lo em outro ponto de montagem, por ex. %código%
2. copie o conteúdo para /mnt (aquele no mesmo dispositivo de bloco que /boot ). por exemplo. %código%
3. Acione uma falha usando /
4. Se tudo correr bem, você verá o despejo de memória do kernel em rsync -axHAX --progress --stats /mnt/ /boot em formulários de (uname -r) -yyyymmddHHmm.crash e um diretório yyyymmddHHmm com dmesg e dump.

Se você quiser analisar o despejo de memória, precisará de echo c | sudo tee /proc/sysrq-trigger , executá-lo da seguinte forma:

/var/crash

Para mais informações sobre falhas, leia o manual.

BTW: NÃO se esqueça de recarregar a configuração do kdump-tools depois de alterar crash por crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/yyyymmddHHmm/dump.yyyymmddHHmm .

    

Answer 2

Talvez seja a memória reservada é muito pequena (meu problema causado por esse motivo).

Acho que você deve verificar a coisa certa em três etapas. Primeiro, verifique se a sua configuração é a seguinte [Dump do kernel do Ubuntu]: link

Segundo, dmesg|grep -i crash , para verificar se a memória reservada está ok.

Terceiro, service kdump-tools status para verificar se o kernel do kdump está OK.

Na terceira etapa, o log é muito importante, você pode ver /var/log/syslog para encontrar os logs. e depois identificar o motivo.