¿Por qué kdump de Linux no escribe en / var / crash?

Ha sucedido de nuevo! Tengo 4 servidores que se bloquean periódicamente, y no hay información impresa en los registros del sistema o en la consola en serie.

Además, el servicio kdump de Linux no escribe volcados de núcleo en la ubicación predeterminada de /var/crash.

• ¿Me pueden ayudar a entender por qué?
• ¿Importa si mi sistema de archivos raíz es un volumen LVM?

Esto es lo que he intentado.

1. Mi sistema es Scientific Linux 6.5 con el último kernel.

   [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. El archivo /etc/kdump.confes el archivo vainilla que contiene la configuración predeterminada. La mayoría de las líneas están comentadas, solo hay dos líneas activas para pathy 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. Me aseguro de que el kdumpservicio se esté ejecutando y que kdumpno sea necesario reconstruir mi 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. Luego, forzo un bloqueo del kernel utilizando estos comandos tomados de la Guía de implementación de RHEL6: Capítulo 29. El Servicio de recuperación de bloqueos de kdump :

   Luego escriba los siguientes comandos en el indicador de comandos de la shell:

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

   Esto obligará al núcleo de Linux a bloquearse

5. El sistema se bloquea. Puedo ver el progreso en mi consola serie. Veo el mensaje Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2, pero inmediatamente después veo el extraño mensaje de Usage: fsck.ext4, que parece que algo está llamando accidentalmente en fscklugar de lo que debería estar haciendo. No veo mención de un error de falta de memoria ni nada.

   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. Y luego el sistema se reinicia (que es el predeterminado).

7. Cuando el sistema vuelve a estar en línea, no hay nada /var/crash. Supongo que el volcado de memoria no fue escrito.

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

8. Sé que los volcados por caída pueden funcionar en general. Si le digo kdumpque copie el volcado del núcleo a otro sistema con la siguiente configuración, kdump escribirá con éxito el volcado del núcleo en otro host:

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

9. Si fijo default shellen /etc/kdump.confy reconstruir el initrd, y luego bloquear el sistema de nuevo consigo un error poco más informativo sobremount: 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. Pero ahora estoy atascado.

Un poco tarde para el juego, pero si necesita configurar kdump para el futuro:

Creo que la directiva de ruta designa una ruta desde la partición o el sistema de archivos designado. Por defecto esta es la raíz fs. Si tiene una partición separada en fstab para / var, ofuscará el directorio de bloqueo cuando su sistema se inicie normalmente. es decir, si iniciara normalmente y desmontara / var, vería el bloqueo / [UniqCoreDir]. Puede ajustar esto agregando una directiva "ext4 / PATH / TO / DEVICE" en kdump.conf. También podría usar una ruta diferente que no se montará.

Solo una suposición, pero podría tener varios vmcores enterrados bajo / var.

Separe su kdump initrd en / boot / check para ver la ruta final a la que intenta volcar.

• Creo que la opción "ruta" es un poco extraña, probablemente la dejaría por defecto o la establecería explícitamente en / var / crash

• ¿Tienes algún tipo de perro guardián que reinicie la máquina? Esto también puede evitar que se cree el núcleo reiniciando la máquina antes de que se inicie.