为什么Linux kdump没有写入/ var / crash？

它再次发生了！我有4台服务器定期崩溃,并且没有信息打印到系统日志或串行控制台.

此外,Linux kdump service没有将核心转储写入/ 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 user@my.server.com
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 Deployment Guide: Chapter 29. The kdump Crash Recovery Service借来的这些命令强制内核崩溃：

Then type the following commands at a shell prompt:

06003

This will force the Linux kernel to crash

>系统崩溃.我可以在串口控制台上查看进度.我看到消息保存到本地文件系统UUID = e7abcdeb-1987-4c69-a867-fabdceffghi2,但在此之后我立刻看到了一条奇怪的用法消息：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 user@hostb.example.org
sshkey /root/.ssh/kdump_id_rsa

>如果我在/etc/kdump.conf中设置默认shell并重建initrd,然后再次崩溃系统我得到一个关于mount的更多信息错误：在/ etc / fstab中找不到/ mnt

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 #

>但现在,我被困住了.

解决方法

游戏有点晚,但如果你需要为未来配置kdump：

我认为path指令指定了指定的分区或文件系统的路径.默认情况下,这是根fs.如果在fstab中有一个单独的分区用于/ var,它将在系统正常引导时对崩溃目录进行模糊处理.即如果你正常启动并卸载/ var你会看到崩溃/ [UniqCoreDir].您可以通过在kdump.conf中添加“ext4 / PATH / TO / DEVICE”指令来调整它.您也可以使用不会安装的其他路径.

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

原文地址：https://www.jb51.cc/linux/401634.html

为什么Linux kdump没有写入/ var / crash？

解决方法

相关推荐