为什么 Linux kdump 不写入 /var/crash？

Question

又出事了！我有 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是包含默认设置的 vanilla 文件。大多数行都被注释掉了，只有两个活动行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 崩溃恢复服务：

   然后在 shell 提示符下键入以下命令：

   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. 但现在，我被困住了。

Answer 1

游戏有点晚了，但如果您需要kdump为将来进行配置：

我认为 path 指令指定来自指定分区或文件系统的路径。默认情况下，这是根 FS。如果你有一个单独的分区/etc/fstab用于/var当你的系统正常引导它会混淆崩溃目录。即如果您要正常启动并且unmount /var您会看到crash/[UniqCoreDir]. 您可以通过ext4 /PATH/TO/DEVICE在kdump.conf. 您也可以使用不会安装的不同路径。

只是一个猜测，但可能有许多 vmcores 埋在/var.

Answer 2

在 /boot/ 中拆开您的 kdump initrd 检查以查看其尝试转储到的最终路径。

• 我认为“path”选项有点奇怪，我可能会将其保留为默认值或明确将其设置为 /var/crash

• 你有某种看门狗来重新启动机器吗？这也可能会阻止在启动之前通过重新启动计算机来创建核心。