又发生了!我有 4 台服务器定期崩溃,并且系统日志或串行控制台上没有打印任何信息。
此外,Linuxkdump 服务没有将核心转储写入的默认位置/var/crash
。
- 你能帮我找出原因吗?
- 如果我的根文件系统是 LVM 卷,这有关系吗?
这是我尝试过的。
我的系统是具有最新内核的 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)
该文件
/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
我确保
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 ~]#
然后,我使用从RHEL6 部署指南:第 29 章 kdump 崩溃恢复服务:
然后在 shell 提示符下输入以下命令:
echo 1 > /proc/sys/kernel/sysrq echo c > /proc/sysrq-trigger
这将导致 Linux 内核崩溃
系统崩溃。我可以在串行控制台上查看进度。我看到了消息
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
然后系统重新启动(这是默认设置)。
当系统恢复在线时, 中没有任何内容
/var/crash
。我认为没有写入崩溃转储。[root@host1 ~]# ls -lA /var/crash/ total 0 [root@host1 ~]#
我知道崩溃转储通常可以工作。如果我使用
kdump
以下配置将核心转储复制到另一个系统,kdump 将成功将核心转储写入另一台主机:path vmcore ssh [email protected] sshkey /root/.ssh/kdump_id_rsa
如果我设置
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 #
但现在我陷入困境。
答案1
有点晚了,但如果你需要kdump
为未来进行配置:
我认为路径指令指定了从指定分区或文件系统的路径。默认情况下,这是根文件系统。如果您在 中有单独的分区,/etc/fstab
它将/var
在系统正常启动时混淆崩溃目录。即,如果您正常启动,unmount /var
您将看到crash/[UniqCoreDir]
。您可以通过ext4 /PATH/TO/DEVICE
在 中添加指令来调整这一点kdump.conf
。您也可以使用不会被覆盖的其他路径。
只是猜测,但可能有许多 vmcores 被埋没/var
。
答案2
将 /boot/ 中的 kdump initrd 拆开,检查其尝试转储到的最终路径。
我认为“路径”选项有点奇怪,我可能会将其保留为默认值或明确设置为 /var/crash
您是否有某种看门狗来重启机器?这也可能通过在启动前重启机器来阻止创建核心。