12 votos

¿Por qué es Linux kdump no escribir en el directorio /var/crash?

Esto ha sucedido de nuevo! Tengo 4 servidores que se estrellan periódicamente, y no hay ninguna información impresa a los registros del sistema o de la consola serie.

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

  • Me puede ayudar a averiguar por qué?
  • Qué importa si mi sistema de ficheros root es un volumen LVM?

Aquí es lo que he intentado.

  1. Mi sistema es Scientific Linux 6.5 con la última versión del núcleo.

    [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.conf es el de vainilla archivo que contiene la configuración predeterminada. La mayoría de las líneas son comentarios, sólo hay dos líneas activas para path y core_collector.

    #net my.server.com:/export/tmp
    #net user@my.server.com
    path /var/crash
    core_collector makedumpfile -c --message-level 1 -d 31
    #core_collector scp
    
  3. Puedo asegurar que el kdump servicio se está ejecutando, y que kdump no necesita 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. Entonces, tengo la fuerza de un Kernel crash del uso de estos comandos tomado de la RHEL6 Guía de Implementación: Capítulo 29. El kdump Recuperación de un fallo del Servicio:

    A continuación, escriba los siguientes comandos en una terminal:

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

    Esto obligará a que el kernel de Linux se bloquee

  5. El sistema se bloquea. Puedo ver el progreso de mi serie de la consola. Veo el mensaje Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2, pero inmediatamente después de que veo el extraño mensaje de Usage: fsck.ext4, que de cierta forma se parece a algo es accidentalmente llamando fsck en lugar de lo que debería estar haciendo. No veo ninguna mención a un error 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, a continuación, reinicie el sistema (que es el predeterminado).

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

    [root@host1 ~]# ls -lA /var/crash/
    total 0
    [root@host1 ~]#
    
  8. Sé que los volcados puede trabajar en general. Si te digo kdump a copiar el volcado de núcleo a otro sistema con la siguiente configuración, kdump va a escribir correctamente el volcado de núcleo a otro host:

    path vmcore
    ssh user@hostb.example.org
    sshkey /root/.ssh/kdump_id_rsa
    
  9. Si he de poner default shell en /etc/kdump.conf y reconstruir initrd y, a continuación, bloquee el sistema de nuevo tengo un poco más de error 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. Pero ahora, estoy atascado.

5voto

nick Puntos 21

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

Creo que la ruta de acceso de la directiva designa a una ruta de acceso desde el sistema de archivos o partición designado. Por defecto, esta es la root de fs. Si usted tiene una partición separada en el fstab para /var va a ocultar el accidente de directorio cuando el sistema se arranca normalmente. es decir, si usted fuera a arrancar normalmente y desmontar /var usted podría ver el bloqueo/[UniqCoreDir]. Puede ajustar esto mediante la adición de un "ext4 /RUTA/A/DISPOSITIVO" directiva de kdump.conf. También se puede utilizar una ruta de acceso diferente que no va a ser montado.

Sólo una conjetura, pero podría tener un número de vmcores enterrados debajo de /var.

2voto

Wade Mealing Puntos 111

Separe su kdump initrd /boot/ comprobar para ver el final de la ruta que su tratando de volcar.

  • Creo que el "camino" de la opción es un poco raro, probablemente me deje el valor predeterminado o establecer de forma explícita en el directorio /var/crash

  • ¿Tiene algún tipo de watchdog de reiniciar la máquina ? esto también puede impedir el núcleo creado por reiniciar la máquina antes de que el se ha iniciado.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: