Perché Linux kdump non scrive a / var / crash?

È accaduto di nuovo! Ho 4 server che si bloccano periodicamente e non ci sono informazioni printingte nei registri di sistema o nella console seriale.

Inoltre, il servizio kdump Linux non sta scrivendo discariche di base alla posizione predefinita di /var/crash .

  • Puoi aiutarti a capire perché?
  • Va import se il mio filesystem di origine è un volume LVM?

Ecco quello che ho provato.

  1. Il mio sistema è Scientific Linux 6.5 con il kernel più 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. Il file /etc/kdump.conf è il file vanilla contenente le impostazioni predefinite. La maggior parte delle righe vengono commentate, ci sono solo due linee attive per il path e il 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. kdump che il servizio kdump sia in esecuzione e che kdump non ha bisogno di ribuild 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, forzare un crash del kernel utilizzando questi comandi presi in prestito dalla RHEL6 Deployment Guide: Capitolo 29. Il servizio di ripristino crash kdump :

    Quindi digitare i seguenti comandi al prompt di una shell:

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

    Ciò obbligherà il kernel Linux ad arrestarsi

  5. Il sistema si blocca. Posso vedere i progressi sulla mia console seriale. Vedo il messaggio Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2 , ma subito dopo vedo il strano messaggio di Usage: fsck.ext4 , che tipo di looks come qualcosa accidentalmente chiama fsck invece di qualunque dovrebbe fare. Non vedo nessuna menzione di un errore fuori memory o di qualunque altra cosa.

     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 poi il sistema si riavvia (che è il default).

  7. Quando il sistema ritorna in linea, non c'è niente in /var/crash . Suppongo che il dump di crash non sia stato scritto.

     [root@host1 ~]# ls -lA /var/crash/ total 0 [root@host1 ~]# 
  8. So che le discariche di crash possono funzionare in generale. Se dico a kdump di copiare il dump di base in un altro sistema con la seguente configuration, kdump scriverà con successo la dump di base ad un altro host:

     path vmcore ssh user@hostb.example.org sshkey /root/.ssh/kdump_id_rsa 
  9. Se posso impostare la default shell in /etc/kdump.conf e ribuild initrd e quindi bloccare nuovamente il sistema, ho un errore leggermente più informativo sul 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. Ma adesso sono bloccato.

  • Ubuntu 11.04 Server Crashing - command fallito: READ FPDMA QUEUED
  • APC XS 1300 Sovraccarico each notte alle 2:45
  • Server di Windows 2000 R2, crash, nessun file di dumping
  • Perdita di dati MySql - analisi post mortem - RackSpace Cloud Server
  • Log - Kernel server: INFO: task httpd: 000000 bloccato per più di 120 secondi
  • CORRUZIONE CRITICA DI STRUTTURA su Windows Server 2012 R2
  • Come fermare una rampa random in processi FCGI Uccidere il server
  • Imansible avviare kdump
  • 2 Solutions collect form web for “Perché Linux kdump non scrive a / var / crash?”

    Un po 'in ritardo per il gioco, ma se hai bisogno di configurare kdump per il futuro:

    Penso che la direttiva path indichi un path dalla partizione o dal file system designato. Per impostazione predefinita questa è la root fs. Se si dispone di una partizione separata in fstab per / var, si ignorerà la directory di crash quando il sistema viene avviato normalmente. vale a dire se si wheresse avviare normalmente e smontare / var si vedrebbe il crash / [UniqCoreDir]. È ansible regolare questa impostazione aggiungendo una direttiva "ext4 / PATH / TO / DEVICE" in kdump.conf. Inoltre si potrebbe usare un path diverso che non verrà montato sopra.

    Solo un'idea, ma potrebbe avere un certo numero di vmcores burried sotto / var.

    Estraete l'initrd di kdump in / boot / check per vedere il path finale che sta cercando di far uscire.

    • Penso che l'opzione "path" è un po 'strano, probabilmente lo lascio al predefinito o impostare esplicitamente su / var / crash

    • Avete una sorta di watchdog che riavvia la macchina? questo può anche impedire che il nucleo venga creato mediante il riavvio della macchina prima dell'avvio.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.