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

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

又发生了!我有 4 台服务器定期崩溃,并且系统日志或串行控制台上没有打印任何信息。

此外,Linuxkdump 服务没有将核心转储写入的默认位置/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 [email protected]
    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 [email protected]
    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. 但现在我陷入困境。

答案1

有点晚了,但如果你需要kdump为未来进行配置:

我认为路径指令指定了从指定分区或文件系统的路径。默认情况下,这是根文件系统。如果您在 中有单独的分区,/etc/fstab它将/var在系统正常启动时混淆崩溃目录。即,如果您正常启动,unmount /var您将看到crash/[UniqCoreDir]。您可以通过ext4 /PATH/TO/DEVICE在 中添加指令来调整这一点kdump.conf。您也可以使用不会被覆盖的其他路径。

只是猜测,但可能有许多 vmcores 被埋没/var

答案2

将 /boot/ 中的 kdump initrd 拆开,检查其尝试转储到的最终路径。

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

  • 您是否有某种看门狗来重启机器?这也可能通过在启动前重启机器来阻止创建核心。

相关内容