Mengapa Linux kdump tidak menulis ke / var / crash?


10

Itu terjadi lagi! Saya memiliki 4 server yang mogok secara berkala, dan tidak ada informasi yang dicetak ke log sistem atau konsol serial.

Selain itu, layanan Linux kdump tidak menulis dump inti ke lokasi default /var/crash.

  • Bisakah Anda membantu saya mencari tahu mengapa?
  • Apakah penting jika filesystem root saya adalah volume LVM?

Inilah yang saya coba.

  1. Sistem saya adalah Scientific Linux 6.5 dengan kernel terbaru.

    [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. File tersebut /etc/kdump.confadalah file vanilla yang berisi pengaturan default. Sebagian besar baris dikomentari, hanya ada dua baris aktif untuk pathdan 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. Saya memastikan bahwa kdumplayanan berjalan, dan itu kdumptidak perlu membangun kembali 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. Kemudian, saya memaksakan crash Kernel menggunakan perintah-perintah ini yang dipinjam dari RHEL6 Deployment Guide: Bab 29. Layanan Pemulihan Crash kdump :

    Kemudian ketik perintah berikut di prompt shell:

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

    Ini akan memaksa kernel Linux crash

  5. Sistem macet. Saya dapat melihat kemajuan pada konsol serial saya. Saya melihat pesan itu Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2, tetapi segera setelah itu saya melihat pesan aneh itu Usage: fsck.ext4, yang kelihatannya seperti sesuatu yang secara tidak sengaja memanggil fsckbukan apa yang seharusnya dilakukan. Saya tidak melihat adanya kesalahan memori atau apa pun.

    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. Dan kemudian sistem reboot (yang merupakan default).

  7. Ketika sistem kembali online, tidak ada apa-apa di dalamnya /var/crash. Saya berasumsi bahwa crash dump tidak ditulis.

    [root@host1 ~]# ls -lA /var/crash/
    total 0
    [root@host1 ~]#
    
  8. Saya tahu bahwa dump crash dapat bekerja secara umum. Jika saya meminta kdumpuntuk menyalin core dump ke sistem lain dengan konfigurasi berikut, kdump akan berhasil menulis core dump ke host lain:

    path vmcore
    ssh user@hostb.example.org
    sshkey /root/.ssh/kdump_id_rsa
    
  9. Jika saya set default shelldi /etc/kdump.confdan membangun kembali initrd, dan kemudian sistem crash lagi saya mendapatkan error sedikit lebih informatif tentangmount: 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. Tapi sekarang, saya mandek.


Apa merek / model server?
ewwhite

Ini adalah Supermicro dengan motherboard X9DRW4, dan bios terbaru.
Stefan Lasiewski

Kekecewaan. Saya mengalami crash yang serupa pada HP ProLiants dengan kernel RHEL6 terbaru. Saya ingin tahu apakah ini masalah yang lebih dalam.
ewwhite

Bagi saya, ini terlihat seperti bug. Tapi saya tidak ingat seperti apa hasilnya.
Stefan Lasiewski

1
Hai. Apakah Anda menyelesaikan masalah ini? Saya menghadapi masalah yang sangat mirip.
Chul-Woong Yang

Jawaban:


5

Sedikit terlambat ke gim tetapi jika Anda perlu mengkonfigurasi kdump untuk masa depan:

Saya pikir direktif jalur menunjuk jalur dari partisi atau sistem file yang ditunjuk. Secara default ini adalah root fs. Jika Anda memiliki partisi terpisah di fstab untuk / var itu akan mengaburkan direktori crash ketika sistem Anda boot secara normal. yaitu jika Anda boot dengan normal dan unmount / var Anda akan melihat crash / [UniqCoreDir]. Anda dapat menyesuaikan ini dengan menambahkan direktif "ext4 / PATH / TO / DEVICE" di kdump.conf. Anda juga dapat menggunakan jalur berbeda yang tidak akan dipasang.

Hanya tebakan tetapi mungkin ada sejumlah vmcores yang terkubur di bawah / var.


2

Pisahkan initrd kdump Anda di / boot / centang untuk melihat path terakhir yang ingin dibuang.

  • Saya pikir opsi "path" agak aneh, saya mungkin akan membiarkannya ke default atau mengaturnya secara eksplisit ke / var / crash

  • Apakah Anda memiliki semacam pengawas me-reboot mesin? ini juga dapat mencegah inti dibuat dengan me-reboot mesin sebelum dimulai.


Saya akan memeriksa initrd dan melihat apa yang saya temukan. The pathpilihan di # 2 adalah jalan default ( /var/crash).
Stefan Lasiewski

Tidak, saya tidak memiliki pengawas me-reboot mesin. Ternyata pengontrol LSI + Samsung SSD dibekukan secara berkala karena alasan yang tidak kita pahami sepenuhnya.
Stefan Lasiewski

Apakah Anda mendapatkan umpan balik, karena itu cukup gila, mungkin masalah penarikan daya menjatuhkan tegangan terlalu rendah?
Tanpa Nama
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.