Por que o kdump do Linux não está gravando em / var / crash?

Question

Já aconteceu de novo! Tenho 4 servidores que estão travando periodicamente e não há informações impressas nos logs do sistema ou no console serial.

Além disso, o serviço do kdump do Linux não está gravando os core dumps no local padrão de /var/crash .

• Você pode me ajudar a descobrir por quê?
• Importa se o meu sistema de arquivos raiz é um volume LVM?

Aqui está o que eu tentei.

1. Meu sistema é o Scientific Linux 6.5 com o kernel mais recente.

   [root@host1 ~]# uname -r
   2.6.32-431.11.2.el6.x86_64
   [root@host1 ~]# cat /etc/issue
   Scientific Linux release 6.5 (Carbon)
   

2. O arquivo /etc/kdump.conf é o arquivo baunilha que contém as configurações padrão. A maioria das linhas está comentada, existem apenas duas linhas ativas para path e core_collector .

   #net my.server.com:/export/tmp
   #net [email protected]
   path /var/crash
   core_collector makedumpfile -c --message-level 1 -d 31
   #core_collector scp
   

3. Garanto que o serviço kdump esteja em execução e que kdump não precise reconstruir meu initrd .

   [root@host1 ~]# chkconfig --list kdump
   kdump           0:off   1:off   2:off   3:on    4:on    5:on    6:off
   [root@host1 ~]# /etc/init.d/kdump restart
   Stopping kdump:                                            [  OK  ]
   Starting kdump:                                            [  OK  ]
   [root@host1 ~]# 
   

4. Então, eu forço uma falha no Kernel usando esses comandos emprestados do Guia de Implantação do RHEL6: Capítulo 29. O Serviço de Recuperação de Falhas do kdump :

   Then type the following commands at a shell prompt:

   echo 1 > /proc/sys/kernel/sysrq
   echo c > /proc/sysrq-trigger
   

   This will force the Linux kernel to crash

5. O sistema trava. Eu posso ver o progresso no meu console serial. Eu vejo a mensagem Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2 , mas imediatamente depois eu vejo a mensagem estranha de Usage: fsck.ext4 , que parece que algo está acidentalmente chamando fsck em vez de o que deveria estar fazendo. Não vejo nenhuma menção a um erro de falta de memória ou qualquer coisa.

   host1.example.org login: SysRq : Trigger a crash
   BUG: unable to handle kernel NULL pointer dereference at (null)
   ...
   ... skipping 50 lines of output
   ...
   Creating block device ram8
   Creating block device ram9
   Creating Remain Block Devices
   Making device-mapper control node
   Scanning logical volumes
     Reading all physical volumes.  This may take a while...
     No volume groups found
     No volume groups found
   Activating logical volumes
     No volume groups found
     No volume groups found
   Free memory/Total memory (free %): 58272 / 116616 ( 49.9691 )
   Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2
   Usage: fsck.ext4 [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
           [-I inode_buffer_blocks] [-P process_inode_size]
           [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
           [-E extended-options] device
   
   Emergency help:
    -p                   Autom
   

6. E então o sistema é reinicializado (que é o padrão).

7. Quando o sistema volta a ficar online, não há nada em /var/crash . Presumo que o despejo de memória não foi escrito.

   [root@host1 ~]# ls -lA /var/crash/
   total 0
   [root@host1 ~]#
   

8. Eu sei que os despejos de memória podem funcionar em geral. Se eu disser kdump para copiar o dump principal para outro sistema com a seguinte configuração, o kdump irá gravar com sucesso o dump principal para outro host:

   path vmcore
   ssh [email protected]
   sshkey /root/.ssh/kdump_id_rsa
   

9. Se eu definir default shell em /etc/kdump.conf e reconstruir o initrd e, em seguida, travar o sistema novamente, recebo um erro um pouco mais informativo sobre mount: can't find /mnt in /etc/fstab

   Free memory/Total memory (free %): 58272 / 116616 ( 49.9691 )
   Saving to the local filesystem UUID=e720481b-1987-4c69-a867-f2b4cba3b312
   Usage: fsck.ext4 [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
   [-I inode_buffer_blocks] [-P process_inode_size]
   [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
   [-E extended-options] device
   
   Emergency help:
    -p                   Automatic repair (no questions)
    -n                   Make no changes to the filesystem
    -y                   Assume "yes" to all questions
    -c                   Check for bad blocks and add them to the badblock list
    -f                   Force checking even if filesystem is marked clean
    -v                   Be verbose
    -b superblock        Use alternative superblock
    -B blocksize         Force blocksize when looking for superblock
    -j external_journal  Set location of the external journal
    -l bad_blocks_file   Add to badblocks list
    -L bad_blocks_file   Set badblocks list
   mount: can't find /mnt in /etc/fstab
   dropping to initramfs shell
   exiting this shell will reboot your system
   /sys/block #
   

10. Mas agora estou preso.

Answer 1

Um pouco atrasado para o jogo, mas se você precisar configurar o kdump para o futuro:

Acho que a diretiva path designa um caminho da partição ou do sistema de arquivos designado. Por padrão, essa é a raiz fs. Se você tiver uma partição separada no fstab para / var, ela irá ofuscar o diretório de falha quando o sistema for inicializado normalmente. ou seja, se você fosse inicializar normalmente e desmontar / var, você veria o travamento / [UniqCoreDir]. Você pode ajustar isso adicionando uma diretiva "ext4 / PATH / TO / DEVICE" no kdump.conf. Você também pode usar um caminho diferente que não será montado.

Apenas um palpite, mas pode ter vários vmcores enterrados em / var.

    

Answer 2

Separe seu initrd do kdump em / boot / check para ver o caminho final que ele está tentando copiar.

• Eu acho que a opção "path" é um pouco estranha, eu provavelmente a deixaria com o padrão ou a configuraria explicitamente como / var / crash

• Você tem algum tipo de cão de guarda reiniciando a máquina? isso também pode impedir que o núcleo seja criado pela reinicialização da máquina antes que ela seja iniciada.