Почему Linux kdump не пишет в / var / crash?

Это случилось снова! У меня есть 4 сервера, которые периодически выходят из строя, и в системных журналах или на последовательной консоли нет информации.

Кроме того, Linux служба kdump не записывает дампы ядра в расположение по умолчанию /var/crash.

• Вы можете помочь мне понять, почему?
• Имеет ли значение, является ли моя корневая файловая система томом LVM?

Вот что я пробовал.

1. Моя система - это Scientific Linux 6.5 с последним ядром.

   [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. Файл /etc/kdump.conf это стандартный файл, содержащий настройки по умолчанию. Большинство строк закомментировано, есть только две активные строки для path и 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 служба работает, и что kdump не нужно перестраивать мой 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. Затем я вызываю сбой ядра, используя эти команды, заимствованные из Руководство по развертыванию RHEL6: Глава 29. Служба восстановления после сбоя kdump:

   Затем введите в командной строке следующие команды:

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

   Это приведет к сбою ядра Linux

5. Система вылетает. Я могу следить за прогрессом на своей последовательной консоли. Я вижу сообщение Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2, но сразу после этого я вижу странное сообщение Usage: fsck.ext4, что похоже на то, что что-то случайно вызывает fsck вместо того, что он должен делать. Я не вижу упоминания об ошибке нехватки памяти или чего-то еще.

   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. Затем система перезагружается (по умолчанию).

7. Когда система снова работает, в ней ничего нет. /var/crash. Предполагаю, что аварийный дамп не писался.

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

8. Знаю, что аварийные дампы вообще могут работать. Если я скажу kdump чтобы скопировать дамп ядра в другую систему со следующей конфигурацией, kdump успешно запишет дамп ядра на другой хост:

   path vmcore
   ssh user@hostb.example.org
   sshkey /root/.ssh/kdump_id_rsa
   

9. Если я установлю default shell в /etc/kdump.conf и пересобираю initrd, а затем снова выхожу из строя. Я получаю чуть более информативную ошибку о 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. Но теперь я застрял.