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

这又发生了！ 我有4个定期崩溃的服务器，并且没有信息打印到系统日志或串行控制台。

此外，Linux kdump服务不会将核心转储写入/var/crash的默认位置。

• 你能帮我弄清楚为什么？
• 如果我的根文件系统是LVM卷，这有什么关系吗？

这是我试过的。

1. 我的系统是具有最新内核的Scientific Linux 6.5。

   • 什么会导致服务器上的所有服务closures，但仍然响应ping？ 以及如何弄清楚
   • 戴尔PowerEdge服务器死机，如何修复？ 发生了什么？ 里面的信息
   • 我的php-fpmconfiguration有什么问题？
   • 如何区分RHEL7上的崩溃和重启？
   • 服务器在系统日志中用ascii NUL字符崩溃（^ @ ^ @ ^ @ …）

    [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 [email protected] path /var/crash core_collector makedumpfile -c --message-level 1 -d 31 #core_collector scp 

3. 我确保kdump服务正在运行，并且kdump不需要重build我的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提示下input以下命令：

    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的奇怪消息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使用以下configuration将核心转储复制到另一个系统，kdump将成功将核心转储写入另一个主机：

    path vmcore ssh [email protected] sshkey /root/.ssh/kdump_id_rsa 

9. 如果我在/etc/kdump.conf设置了default shell并且重新/etc/kdump.conf initrd，然后再次崩溃了，我得到了一些关于mount: can't find /mnt in /etc/fstab信息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. 但现在，我卡住了。