linux kdump保存的目录,为什么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 ~]#

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 #

>但现在,我被困住了.