Perché Linux kdump non sta scrivendo su / var / crash?


10

È successo di nuovo! Ho 4 server che si bloccano periodicamente e non ci sono informazioni stampate sui registri di sistema o sulla console seriale.

Inoltre, il servizio kdump di Linux non sta scrivendo core dump nella posizione predefinita di /var/crash.

  • Potete aiutarmi a capire perché?
  • Importa se il mio filesystem di root è un volume LVM?

Ecco cosa ho provato.

  1. Il mio sistema è Scientific Linux 6.5 con l'ultimo 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. Il file /etc/kdump.confè il file vanilla che contiene le impostazioni predefinite. La maggior parte delle righe sono commentate, ci sono solo due righe attive per pathe 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. Garantisco che il kdumpservizio è in esecuzione e che kdumpnon è necessario ricostruire il mio 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. Quindi, forzo un arresto anomalo del kernel usando questi comandi presi in prestito dalla Guida alla distribuzione di RHEL6: Capitolo 29. Il servizio kdump Crash Recovery :

    Quindi digitare i seguenti comandi al prompt della shell:

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

    Questo costringerà il kernel di Linux a bloccarsi

  5. Il sistema si arresta in modo anomalo. Posso visualizzare i progressi sulla mia console seriale. Vedo il messaggio Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2, ma subito dopo vedo lo strano messaggio di Usage: fsck.ext4, che sembra che qualcosa stia chiamando accidentalmente fsckinvece di qualunque cosa dovrebbe fare. Non vedo alcuna menzione di un errore di memoria insufficiente o altro.

    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 quindi il sistema si riavvia (che è l'impostazione predefinita).

  7. Quando il sistema torna online, non c'è nulla in /var/crash. Presumo che la discarica non sia stata scritta.

    [root@host1 ~]# ls -lA /var/crash/
    total 0
    [root@host1 ~]#
    
  8. So che i crash dump possono funzionare in generale. Se dico kdumpdi copiare il core dump su un altro sistema con la seguente configurazione, kdump scriverà correttamente il core dump su un altro host:

    path vmcore
    ssh user@hostb.example.org
    sshkey /root/.ssh/kdump_id_rsa
    
  9. Se ho impostato default shellin /etc/kdump.confe ricostruire initrd, e poi mandare in crash il sistema di nuovo ottengo un errore un po 'più informativo sumount: 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. Ma ora sono bloccato.


Qual è la marca / modello del server?
ewwhite,

Questo è un Supermicro con una scheda madre X9DRW4 e l'ultimo bios.
Stefan Lasiewski,

Bummer. Sto riscontrando un arresto simile su HP ProLiants con il kernel RHEL6 più recente. Mi chiedo se sia un problema più profondo.
ewwhite,

A me sembra un bug. Ma non ricordo come dovrebbe essere l'output.
Stefan Lasiewski,

1
Ciao. Hai risolto questo problema? Sto affrontando un problema molto simile.
Chul-Woong Yang,

Risposte:


5

Un po 'in ritardo al gioco, ma se devi configurare kdump per il futuro:

Penso che la direttiva path indichi un percorso dalla partizione o dal file system designato. Di default questa è la radice fs. Se hai una partizione separata in fstab per / var, offuscherà la directory di crash quando il tuo sistema viene avviato normalmente. ad esempio, se avessi avviato normalmente e smontato / var, vedresti il ​​crash / [UniqCoreDir]. Puoi aggiustarlo aggiungendo una direttiva "ext4 / PATH / TO / DEVICE" in kdump.conf. Inoltre, è possibile utilizzare un percorso diverso che non verrà montato.

Solo un'ipotesi ma potrebbe avere un certo numero di vmcores sepolti in / var.


2

Metti da parte il tuo initrd di kdump in / boot / check per vedere il percorso finale a cui sta provando a scaricare.

  • Penso che l'opzione "path" sia un po 'strana, probabilmente la lascerei all'impostazione predefinita o la imposterei esplicitamente su / var / crash

  • Hai qualche tipo di watchdog che riavvia la macchina? ciò potrebbe anche impedire la creazione del core riavviando il computer prima dell'avvio.


Controllerò initrd e vedrò cosa trovo. L' pathopzione in # 2 è il percorso predefinito ( /var/crash).
Stefan Lasiewski,

No, non ho un cane da guardia che riavvia la macchina. Si scopre che il controller LSI + gli SSD Samsung si bloccano periodicamente per motivi che non capiamo del tutto.
Stefan Lasiewski il

Hai ricevuto feedback, perché è piuttosto folle, forse un problema di assorbimento di potenza che fa cadere la tensione troppo bassa?
Nessun nome utente
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.