wordpress站长主题,变现流量推广app,曲靖程序网站建设,章丘市网站建设seoCentos7.9操作系统kdump crash文件未生成问题 一、背景说明1、问题背景 二、排查思路1、先了解下crashkernelcrashkernel设置方式示例如何配置crashkernel验证crashkernel配置 2、再了解下kdump2.1 Kdump 的基本概念2.1.1. 生产内核#xff08;Production Kernel#xff09;2… Centos7.9操作系统kdump crash文件未生成问题 一、背景说明1、问题背景 二、排查思路1、先了解下crashkernelcrashkernel设置方式示例如何配置crashkernel验证crashkernel配置 2、再了解下kdump2.1 Kdump 的基本概念2.1.1. 生产内核Production Kernel2.1.2. 捕获内核Capture Kernel2.1.3. Ramdisk2.1.4. ELF 文件 2.2 Kdump 的工作原理2.2.1. Kexec 机制2.2.2. 内核空间kexec_load()2.2.3. 用户空间kexec-tools 2.3 Kdump 的工作流程2.3.1. 预留内存2.3.2. 生产内核运行2.3.3. 系统崩溃2.3.4. 捕获内核启动2.3.5. 数据转储2.3.6. 数据分析1. GDB2. Crash使用 gdb 分析 vmcore 文件1. 准备工作2. 分析内存内容3. 分析崩溃原因使用 crash 分析 vmcore 文件1. 准备工作2. 使用 crash 命令3. 经典场景分析案例案例 1内核崩溃由于内存损坏案例 2内核崩溃由于驱动程序问题案例 3内核崩溃由于系统资源耗尽 2.4 Kdump 的应用场景Kdump 的优势 三、解决方案1. 方案一调整crashkernel(需重启系统)1.1 低内存预留的重要性1.2高内存预留的重要性1.3为什么两者都需要预留1.4 模拟crash 2、方案二 (验证次数较少) 修改kdumpctl2.1 替换cmdline2.2 模拟crash 四、总结 一、背景说明
1、问题背景
近期公司一台线上服务器系统出现崩溃已经配置了kdump但未生成相关的crash文件。服务器配置 浪潮SA5212M5Gold5118*2 内存配置为128GB.
[roottest-99-230 log]# cat /etc/default/grub
GRUB_TIMEOUT5
GRUB_DISTRIBUTORCentOS Linux
GRUB_DEFAULTsaved
GRUB_DISABLE_SUBMENUtrue
GRUB_TERMINAL_OUTPUTconsole
GRUB_CMDLINE_LINUXcrashkernel169M biosdevname0 net.ifnames0 rhgb quiet
GRUB_DISABLE_RECOVERYtrue
GRUB_GFXPAYLOAD_LINUXtext
[roottest-99-230 log]#[roottest-99-230 log]# grep -rn crash /var/log/messages
3410:Aug 5 05:43:58 test-99-230 kernel: Command line: BOOT_IMAGE/vmlinuz-3.10.0-1160.el7.x86_64 rootUUID87afdba4-8e9d-4349-a068-23ac53d18164 ro crashkernel169M biosdevname0 net.ifnames0 rhgb quiet
3529:Aug 5 05:43:58 test-99-230 kernel: Reserving 169MB of memory at 576MB for crashkernel (System RAM: 130563MB)
3814:Aug 5 05:43:58 test-99-230 kernel: Kernel command line: BOOT_IMAGE/vmlinuz-3.10.0-1160.el7.x86_64 rootUUID87afdba4-8e9d-4349-a068-23ac53d18164 ro crashkernel169M biosdevname0 net.ifnames0 rhgb quiet
4269:Aug 5 05:43:58 test-99-230 kernel: crash memory driver: version 1.1
4552:Aug 5 05:43:59 test-99-230 kernel: megaraid_sas 0000:5e:00.0: firmware crash dump#011: no
5951:Aug 5 06:18:47 test-99-230 kernel: Command line: BOOT_IMAGE/vmlinuz-3.10.0-1160.el7.x86_64 rootUUID87afdba4-8e9d-4349-a068-23ac53d18164 ro crashkernel169M biosdevname0 net.ifnames0 rhgb quiet
6070:Aug 5 06:18:47 test-99-230 kernel: Reserving 169MB of memory at 576MB for crashkernel (System RAM: 130563MB)
6355:Aug 5 06:18:47 test-99-230 kernel: Kernel command line: BOOT_IMAGE/vmlinuz-3.10.0-1160.el7.x86_64 rootUUID87afdba4-8e9d-4349-a068-23ac53d18164 ro crashkernel169M biosdevname0 net.ifnames0 rhgb quiet
6810:Aug 5 06:18:47 test-99-230 kernel: crash memory driver: version 1.1从crashkernel169M中可以看出配置的第二内核内存是169MB通过不断模拟触发crash场景最终定位本次未产生crash文件根因为
第二内核预留的内核较小导致第二内核在运行期间加载驱动时内存不够使用发生oom内存溢出现象
因为OS本身已经使能kdump所以在内核发生崩溃后会启动crashdump服务即会加载第二内核。
但是第二内核在启动过程中因为前期为其crashkernel预留的内存不够在加载驱动时发生oom内存溢出因此vmcore生成失败。二、排查思路
1、先了解下crashkernel
在Linux操作系统中kdump是一个用于捕获系统崩溃转储crash dump的机制。为了使kdump能够正常工作系统需要预留一部分内存这部分内存称为crashkernel。 crashkernel参数用于指定在系统启动时预留多少内存用于崩溃转储。这些预留的内存不会被操作系统的其他部分使用确保在系统崩溃时kdump有足够的资源来保存内存转储。
以下是crashkernel参数的几种常见设置方式及其示例 自动预留内存 (crashkernelauto) crashkernelauto这种设置允许系统根据总内存自动配置预留的内存量。这是最简单的一种设置方式适用于大多数用户。 固定预留内存 (crashkernelsize) crashkernel128M这种方式明确指定预留内存的大小例如128MB。这种设置方式适用于已知需要多少内存用于kdump的情况。 可变预留内存 (crashkernelrange1:size1,range2:size2) crashkernel512M-2G:64M,2G-:128M这种设置方式根据系统的总内存来预留不同大小的内存。例如当系统总内存小于512MB时不预留内存在512MB到2GB之间时预留64MB大于2GB时预留128MB。 偏移预留内存 (crashkernelsizeoffset) crashkernel128M16M这种方式从指定的偏移地址例如16MB开始预留指定大小的内存例如128MB。如果offset参数设置为0或完全省略kdump会自动偏移预留内存。对于一般用户来说这种方式通常不指定offset因为很难确定预留内存的起始位置。 可变预留偏移预留内存 (crashkernelrange1:size1,range2:size2offset) crashkernel512M-2G:64M,2G-:128M16M这种方式结合了可变预留和偏移预留的特点。例如从16MB开始预留内存根据系统总内存的不同预留64MB或128MB。
crashkernel设置方式示例
设置方式示例示例含义自动预留crashkernelauto允许基于系统的总内存自动地配置预留内存,确切的值crashkernel128M预留128M内存可变预留crashkernel512M-2G:64M,2G-:128M系统总内存小于512M时不预留在512M-2G时预留64M大于2G预留128M偏移预留crashkernel128M16M从16 MB开始预留128 MB内存。如果offset参数设置为0或完全省略kdump会自动偏移预留内存。不过offset一般不指定对于一般用户来讲很难确定预留内存的起始位置。可变预留偏移预留crashkernel512M-2G:64M,2G-:128M16M从16MB开始预留内存预留64M或者128M取决于系统总内存的大小。
如何配置crashkernel
配置crashkernel参数需要修改引导加载程序如GRUB的配置文件。以下是配置步骤 打开GRUB配置文件 sudo vi /etc/default/grub找到GRUB_CMDLINE_LINUX这一行并添加crashkernel参数。例如 GRUB_CMDLINE_LINUXcrashkernel512M-2G:64M,2G-:128M更新GRUB配置 sudo grub2-mkconfig -o /boot/grub2/grub.cfg重启系统使配置生效 sudo reboot验证crashkernel配置
重启系统后可以通过以下命令验证crashkernel配置是否生效
dmesg | grep -i crashkernel2、再了解下kdump
Kdump 是 Linux 系统中一种强大的内核崩溃转储工具它的出现大大增强了系统管理员对系统崩溃的诊断能力。自 2005 年首次推出以来Kdump 已成为许多 Linux 系统中不可或缺的组件帮助用户在系统崩溃后获取重要的内存转储信息。本文将详细介绍 Kdump 的工作原理、实现机制、以及如何有效地使用它来排查系统崩溃问题。
2.1 Kdump 的基本概念
2.1.1. 生产内核Production Kernel
生产内核是系统正常运行时的内核它负责处理所有的系统调用、驱动程序和用户空间的请求。在正常情况下生产内核负责维护系统的稳定性和性能。
2.1.2. 捕获内核Capture Kernel
捕获内核是一个特殊的内核在系统崩溃时启动用于收集生产内核的内存数据。捕获内核在生产内核崩溃后被引导以便在不干扰生产内核的情况下保存内存转储数据。
2.1.3. Ramdisk
Ramdisk 是一种将内存区域虚拟化为硬盘驱动器的机制。通过使用 ramdisk可以大幅提高读写速度因为数据直接存储在内存中而不需要经过传统的磁盘 I/O 操作。在 Kdump 中ramdisk 用于存储捕获内核和相关的数据。
2.1.4. ELF 文件
ELFExecutable and Linkable Format文件是一种标准的文件格式用于存储可执行文件、目标代码和共享库。在 Kdump 中ELF 文件用于存储内存的转储数据以便进行后续分析。
2.2 Kdump 的工作原理
Kdump 的工作原理依赖于 Kexec 机制。Kdump 的核心思想是预留一部分内存来加载捕获内核并在系统崩溃时启动捕获内核来处理内存转储。以下是 Kdump 的详细工作流程
2.2.1. Kexec 机制
Kexec 是一种快速启动机制它允许在当前运行的内核环境下直接启动另一个内核而无需经过传统的 BIOS 启动过程。Kexec 的实现包括两个主要组成部分
内核空间系统调用kexec_load()这是一个系统调用用于将捕获内核和其 ramdisk 加载到当前内核中。kexec_load() 接受捕获内核的地址并将其加载到生产内核中。用户空间工具kexec-tools这是一个用户空间工具集用于执行 Kexec 相关操作。kexec-tools 包含 kexec 程序它负责调用 kexec_load() 并传递捕获内核的地址。
2.2.2. 内核空间kexec_load()
在内核空间kexec_load() 系统调用用于将捕获内核和 ramdisk 加载到内存中。该调用将捕获内核的内存映像和 ramdisk 存储位置传递给生产内核。生产内核在运行过程中保留一部分内存用于加载捕获内核。
当系统崩溃时生产内核会调用 machine_kexec() 函数这通常是一个硬件相关的函数用于引导捕获内核。捕获内核会从生产内核的内存中读取崩溃数据并生成 /proc/vmcore 文件该文件包含生产内核的内存映像。
2.2.3. 用户空间kexec-tools
在用户空间kexec-tools 工具集用于准备和加载捕获内核。kexec-tools 包含以下组件
kexec这是一个用户空间程序负责调用 kexec_load() 并将捕获内核和 ramdisk 加载到生产内核中。kexec 还负责配置捕获内核的启动参数和内存位置。purgatory这是一个小型的用户空间程序用于处理在崩溃时捕获内核的启动。它负责将捕获内核和 ramdisk 加载到内存中并传递必要的启动信息。
2.3 Kdump 的工作流程
Kdump 的工作流程包括以下几个步骤
2.3.1. 预留内存
在系统启动时crashkernel 参数用于指定用于捕获内核的内存量。例如crashkernel128M 表示预留 128MB 的内存给捕获内核。这个预留内存区域必须在系统启动时配置以确保系统在崩溃时能够启动捕获内核。
2.3.2. 生产内核运行
生产内核正常运行处理所有的系统调用和用户请求。生产内核会定期将捕获内核和 ramdisk 加载到预留内存中并配置捕获内核的启动参数。
2.3.3. 系统崩溃
当系统出现崩溃、死锁或死机时生产内核会触发 machine_kexec() 函数。这会启动捕获内核并将生产内核的内存映像转储到 /proc/vmcore 文件中。
2.3.4. 捕获内核启动
捕获内核会从生产内核的内存中读取崩溃数据并生成 /proc/vmcore 文件。捕获内核和 ramdisk 组成一个微环境用于处理和存储内存转储数据。
2.3.5. 数据转储
捕获内核的 ramdisk 中的脚本会执行数据转储操作将 /proc/vmcore 文件中的数据保存到磁盘或网络存储中。这些数据可以用于后续的分析和调试。
2.3.6. 数据分析
使用工具如 gdb、crash 等分析工具对生成的 vmcore 文件进行分析。这些工具可以帮助用户定位系统崩溃的原因并提供详细的崩溃报告。在系统发生崩溃时vmcore 文件是分析和诊断问题的关键。这个文件包含了崩溃时的内存映像提供了有关内核状态的重要信息。使用 gdb 和 crash 等工具我们可以深入分析 vmcore 文件找出系统崩溃的原因.
1. GDB
GDBGNU Debugger是一种强大的调试工具广泛用于调试应用程序和内核。它支持查看内存、设置断点、执行代码等操作适用于深入分析和诊断内核崩溃问题。
2. Crash
crash 是专门用于分析内核崩溃转储的工具它提供了多种命令用于查看内核数据结构、内存内容、线程状态等信息。相比于 GDBcrash 更加专注于内核级别的调试和分析。
使用 gdb 分析 vmcore 文件
1. 准备工作
首先确保你已经安装了 gdb 和适用于你内核版本的调试符号通常是内核的调试符号包。将 vmcore 文件和内核映像vmlinux 文件放在同一目录下。
gdb /path/to/vmlinux /path/to/vmcore2. 分析内存内容
使用 GDB可以查看内存内容、内核数据结构等。以下是一些常用的命令 查看内存 (gdb) x/10x 0xc0000000这个命令可以查看从地址 0xc0000000 开始的 10 个内存单元的内容。 查看内核符号 (gdb) info symbol 0xc0000000这个命令可以查看指定地址的符号信息。 设置断点并运行 (gdb) break function_name
(gdb) continue设置断点并继续执行用于调试内核崩溃时的代码执行路径。
3. 分析崩溃原因 查看内核调用栈 (gdb) bt打印调用栈信息帮助了解崩溃发生时的调用路径。 检查特定的数据结构 (gdb) p data_structure打印特定数据结构的内容帮助检查是否存在异常。
使用 crash 分析 vmcore 文件
1. 准备工作
确保你已经安装了 crash 工具并且已经下载了与内核版本匹配的调试符号。
crash /path/to/vmlinux /path/to/vmcore2. 使用 crash 命令
crash 提供了多种命令来分析内核崩溃数据 查看系统信息 crash sysinfo显示系统信息包括内核版本、CPU 信息和内存布局。 查看内核线程列表 crash ps列出系统中所有的内核线程帮助识别崩溃时的活动线程。 查看内核堆栈 crash bt打印内核调用栈类似于 GDB 中的 bt 命令。 查看特定进程的信息 crash proc显示系统中的进程信息包括每个进程的状态和内存使用情况。 查看内存内容 crash x /10x 0xc0000000显示从地址 0xc0000000 开始的 10 个内存单元的内容。
3. 经典场景分析案例
案例 1内核崩溃由于内存损坏
假设在分析 vmcore 文件时发现系统因为内存损坏导致崩溃。以下是分析步骤 查看内存内容 crash x /20x 0xc0000000检查崩溃时的内存内容寻找异常值。 检查调用栈 crash bt确认崩溃发生时的调用路径查找可能导致内存损坏的代码。 查看特定数据结构 crash p memory_structure检查相关内存数据结构的内容确认是否有损坏或异常情况。
案例 2内核崩溃由于驱动程序问题
假设系统崩溃由于一个驱动程序引发的错误。以下是分析步骤 查看系统信息 crash sysinfo确认系统和内核版本确保与驱动程序版本匹配。 查看内核调用栈 crash bt分析调用栈信息找到崩溃时涉及的驱动程序代码。 查看进程状态 crash ps查找崩溃时活跃的进程确认是否涉及问题驱动程序。
案例 3内核崩溃由于系统资源耗尽
假设系统崩溃由于资源耗尽。以下是分析步骤 查看系统资源使用情况 crash sysinfo检查系统的内存和 CPU 使用情况确认是否存在资源耗尽的情况。 查看内核线程 crash ps查找系统崩溃时活跃的线程确认是否有线程占用过多资源。 检查内存分配 crash kmem -i查看内核内存分配情况确认是否存在资源泄漏或异常分配。
2.4 Kdump 的应用场景
假设你在生产环境中运行一个关键应用系统突然出现无响应的情况没有明显的日志记录且监控数据看起来正常。这时Kdump 可以发挥重要作用 配置 Kdump首先确保系统已配置 Kdump并且 crashkernel 参数已正确设置。例如crashkernel128M 表示为捕获内核预留了 128MB 的内存。 触发崩溃可以通过模拟崩溃例如使用 sysrq 触发 panic来测试 Kdump 是否能够正确捕获和转储内存。 分析崩溃数据崩溃后捕获内核会生成 /proc/vmcore 文件。使用 crash 工具分析 vmcore 文件找出导致崩溃的原因。 故障排查通过分析内存转储数据可以找到崩溃的根本原因比如某个驱动程序或内核模块的问题并进行修复。
Kdump 的优势
实时数据捕获Kdump 能够在系统崩溃时实时捕获内存数据提供详细的崩溃信息。高效转储通过使用 ramdisk可以大幅提高数据转储的速度。详细分析生成的 vmcore 文件可以通过 gdb 和 crash 等工具进行详细的分析帮助开发者和管理员找到系统崩溃的原因。
三、解决方案
1. 方案一调整crashkernel(需重启系统)
通过上面分析结合日志
32489:Aug 5 19:51:35 dlp2-99-230 kernel: megaraid_sas 0000:5e:00.0: firmware crash dump#011: no
33775:Aug 5 20:00:45 dlp2-99-230 kernel: Command line: BOOT_IMAGE/vmlinuz-3.10.0-1160.el7.x86_64 rootUUID87afdba4-8e9d-4349-a068-23ac53d18164 ro crashkernel768M biosdevname0 net.ifnames0 rhgb quiet
33894:Aug 5 20:00:45 dlp2-99-230 kernel: Reserving 256MB of low memory at 1264MB for crashkernel (System low RAM: 1539MB)
33895:Aug 5 20:00:45 dlp2-99-230 kernel: Reserving 768MB of memory at 132336MB for crashkernel (System RAM: 130563MB)
34180:Aug 5 20:00:45 dlp2-99-230 kernel: Kernel command line: BOOT_IMAGE/vmlinuz-3.10.0-1160.el7.x86_64 rootUUID87afdba4-8e9d-4349-a068-23ac53d18164 ro crashkernel768M biosdevname0 net.ifnames0 rhgb quiet
34635:Aug 5 20:00:45 dlp2-99-230 kernel: crash memory driver: version 1.1
34919:Aug 5 20:00:46 dlp2-99-230 kernel: megaraid_sas 0000:5e:00.0: firmware crash dump#011: no此处说明
Firmware Crash Dump: megaraid_sas 0000:5e:00.0: firmware crash dump#011: no 这行日志表明 megaraid_sas 控制器的固件不支持生成 crash dump 文件。固件设置中可能未启用相关功能或该控制器本身不支持该特性。 该相关问题再红帽知识库也曾复现(但当前还不能完全确认是 firmware crash dump#011: no导致crash文件未生成) Reserving 256MB of low memory at 1264MB for crashkernel (System low RAM: 1539MB) 表示系统在低内存区域从 1264MB 开始预留了 256MB 内存。Reserving 768MB of memory at 132336MB for crashkernel (System RAM: 130563MB) 表示系统在高内存区域从 132336MB 开始预留了 768MB 内存。这里再说明下为什么需要高、低内存区域都要预留 在 kdump 机制中低内存和高内存的预留是为了确保系统在崩溃后能够成功启动捕获内核并生成内存转储文件。以下是低内存和高内存均需要预留的原因
1.1 低内存预留的重要性 设备驱动和DMA内存: 许多设备驱动和DMA直接内存访问操作需要使用低内存通常是低于 4GB 的内存区域。这些设备在捕获内核启动时仍需要工作以便在崩溃时能够正常操作。 中断处理和内存映射: 系统中的许多中断处理程序和内存映射操作都依赖于低内存。为了确保捕获内核能够正常处理中断和内存映射低内存预留是必需的。
1.2高内存预留的重要性 内存转储空间: 高内存高于 4GB 的内存区域预留用于存储内核崩溃转储文件。这些转储文件可能非常大因此需要大量的高内存来保存所有的崩溃数据。 内核数据结构: 捕获内核需要访问和使用大量的内核数据结构这些数据结构通常分布在高内存区域。预留高内存确保这些数据结构在捕获内核启动时可用。
假设我们有一台具有 128GB 内存的服务器设置 crashkernel768M 来预留内存以备内核崩溃时使用。 低内存预留: Reserving 256MB of low memory at 1264MB for crashkernel (System low RAM: 1539MB) 系统在低内存区域预留了 256MB用于捕获内核启动时需要的设备驱动和DMA操作。 高内存预留: Reserving 768MB of memory at 132336MB for crashkernel (System RAM: 130563MB) 系统在高内存区域预留了 768MB用于存储内核崩溃转储文件和必要的内核数据结构。
1.3为什么两者都需要预留 低内存需求: 捕获内核的引导和基础服务通常需要低内存支持确保最基本的设备和中断处理功能正常。 高内存需求: 大量的崩溃数据需要在高内存中存储避免占用低内存区域导致设备和基础服务无法正常运行。
预留低内存和高内存的做法是为了确保在系统崩溃后捕获内核能够成功启动并生成完整的内存转储文件。低内存用于设备驱动和基础服务高内存用于存储崩溃数据和必要的内核数据结构。这种双重预留机制确保了捕获内核在各种硬件环境和崩溃情况下的可靠性。
有了上述分析 进行调整操作
[rootdlp2-99-230 log]# cat /etc/default/grub
GRUB_TIMEOUT5
GRUB_DISTRIBUTORCentOS Linux
GRUB_DEFAULTsaved
GRUB_DISABLE_SUBMENUtrue
GRUB_TERMINAL_OUTPUTconsole
GRUB_CMDLINE_LINUXcrashkernel768M biosdevname0 net.ifnames0 rhgb quiet # 768M 或者 512M
GRUB_DISABLE_RECOVERYtrue
GRUB_GFXPAYLOAD_LINUXtext
您在 /var/spool/mail/root 中有邮件
[rootdlp2-99-230 log]# grub2-mkconfig -o /boot/grub2/grub.cfg
[rootdlp2-99-230 log]# reboot
[rootdlp2-99-230 log]# cat /proc/cmdline # 验证
BOOT_IMAGE/vmlinuz-3.10.0-1160.el7.x86_64 rootUUID87afdba4-8e9d-4349-a068-23ac53d18164 ro crashkernel768M biosdevname0 net.ifnames0 rhgb quiet
[rootdlp2-99-230 log]#1.4 模拟crash
什么是 sysrq sysrq 是 Linux 内核中的一个功能通过它可以直接向内核发送特定的命令进行如重启、内存转储、文件系统同步等操作。这个功能在调试和诊断系统问题时非常有用。
[rootdlp2-99-230 log]# systemctl status kdump # 确保kdump服务正常
● kdump.service - Crash recovery kernel armingLoaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)Active: active (exited) since 一 2024-08-05 12:01:11 CST; 1h 31min agoProcess: 2638 ExecStart/usr/bin/kdumpctl start (codeexited, status0/SUCCESS)Main PID: 2638 (codeexited, status0/SUCCESS)Tasks: 0Memory: 0BCGroup: /system.slice/kdump.service8月 05 12:01:06 dlp2-99-230 systemd[1]: Starting Crash recovery kernel arming...
8月 05 12:01:11 dlp2-99-230 kdumpctl[2638]: kexec: loaded kdump kernel
8月 05 12:01:11 dlp2-99-230 kdumpctl[2638]: Starting kdump: [OK]
8月 05 12:01:11 dlp2-99-230 systemd[1]: Started Crash recovery kernel arming.
您在 /var/spool/mail/root 中有邮件
[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]# cat /etc/kdump.conf | grep -v #path /var/crash
core_collector makedumpfile -l --message-level 1 -d 31
[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]#[rootdlp2-99-230 log]#
[rootdlp2-99-230 log]# echo 1 | sudo tee /proc/sys/kernel/sysrq # 该命令将 1 写入 /proc/sys/kernel/sysrq 文件中启用所有 sysrq 功能。
[rootdlp2-99-230 log]# echo c | sudo tee /proc/sysrq-trigger # 一旦启用了 sysrq 功能可以通过以下命令触发内核崩溃 将 c 字符写入 /proc/sysrq-trigger 文件中告诉内核立即触发崩溃 (Crash)。这将导致系统崩溃并重启。查看生成的文件
[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]# ls
vmcore vmcore-dmesg.txt
[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]# pwd
/var/crash/127.0.0.1-2024-08-05-11:56:35
[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]# ls
vmcore vmcore-dmesg.txt
[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]# ll
总用量 1682440
-rw------- 1 root root 1722502368 8月 5 11:56 vmcore
-rw-r--r-- 1 root root 311479 8月 5 11:56 vmcore-dmesg.txt
[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]## 这里说明下有可能不生成vmcore相关文件 是因为kdump时加载的 Modules 出现问题可以罗列出module把最可能有问题的三方模块进行屏蔽使用blacklist命令具体操作可以参考红帽的官方文档说明
[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]# tail -n 30 vmcore-dmesg.txt # 相关模块
[ 296.149234] Modules linked in: cfg80211 rfkill xt_multiport iptable_raw ip_set_hash_ip ip_set_hash_net veth ipip tunnel4 ip_tunnel xt_set ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport ip_set dummy nvidia_uvm(OE) ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6_tables iptable_mangle xt_comment xt_mark ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink iptable_nat nf_nat_ipv4 xt_addrtype iptable_filter xt_conntrack nf_nat br_netfilter bridge LeoFS(OE) nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 yrfs_693(OE) yrfs_610(OE) dns_resolver LeoNET(POE) yrfs_63x(OE) nfs yrfs_6641(OE) lockd grace fscache tcp_diag inet_diag overlay(T) yrfs(OE) uio_pci_generic uio vfio_pci vfio_iommu_type1 vfio cuse fuse 8021q garp mrp stp llc bonding rdma_ucm(OE)
[ 296.149555] rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) nf_conntrack_ipv4 nf_defrag_ipv4 ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack ib_umad(OE) sunrpc dm_mirror dm_region_hash dm_log dm_mod iTCO_wdt iTCO_vendor_support skx_edac coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd pcspkr sg i2c_i801 lpc_ich joydev mei_me mei ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter knem(OE) ip_tables xfs libcrc32c nvidia_drm(POE) nvidia_modeset(POE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) nvidia(POE) sd_mod crc_t10dif crct10dif_generic ast i2c_algo_bit drm_kms_helper ttm syscopyarea sysfillrect sysimgblt fb_sys_fops mlx5_core(OE) ahci crct10dif_pclmul crct10dif_common crc32c_intel libahci drm i40e megaraid_sas
[ 296.149872] mlxfw(OE) psample libata auxiliary(OE) devlink mlx_compat(OE) ptp pps_core drm_panel_orientation_quirks wmi nfit libnvdimm xpmem(OE)
[ 296.149929] CPU: 20 PID: 11510 Comm: bash Kdump: loaded Tainted: P OE ------------ T 3.10.0-1160.el7.x86_64 #1
[ 296.149962] Hardware name: Inspur SA5212M5/YZMB-00882-102, BIOS 4.0.3 03/29/2018
[ 296.149985] task: ffff90eb19a46300 ti: ffff90eb456d4000 task.ti: ffff90eb456d4000
[ 296.150008] RIP: 0010:[ffffffffad274856] [ffffffffad274856] sysrq_handle_crash0x16/0x20
[ 296.150039] RSP: 0018:ffff90eb456d7e58 EFLAGS: 00010246
[ 296.150056] RAX: ffffffffad274840 RBX: ffffffffadae74a0 RCX: 0000000000000000
[ 296.150078] RDX: 0000000000000000 RSI: ffff90fc8e4138d8 RDI: 0000000000000063
[ 296.150099] RBP: ffff90eb456d7e58 R08: ffffffffade0487c R09: 00000000ffffffff
[ 296.150120] R10: 0000000000000df2 R11: 0000000000000df1 R12: 0000000000000063
[ 296.150142] R13: 0000000000000000 R14: 0000000000000004 R15: 0000000000000000
[ 296.150164] FS: 00007f62dc667740(0000) GS:ffff90fc8e400000(0000) knlGS:0000000000000000
[ 296.150188] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 296.150207] CR2: 0000000000000000 CR3: 0000001eeefe0000 CR4: 00000000007607e0
[ 296.150228] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 296.150251] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 296.150272] PKRU: 55555554
[ 296.150282] Call Trace:
[ 296.150296] [ffffffffad27507d] __handle_sysrq0x10d/0x170
[ 296.150315] [ffffffffad2754e8] write_sysrq_trigger0x28/0x40
[ 296.150337] [ffffffffad0c6d40] proc_reg_write0x40/0x80
[ 296.150357] [ffffffffad04db50] vfs_write0xc0/0x1f0
[ 296.150375] [ffffffffad04e92f] SyS_write0x7f/0xf0
[ 296.150395] [ffffffffad593f92] system_call_fastpath0x25/0x2a
[ 296.150414] Code: eb 9b 45 01 f4 45 39 65 34 75 e5 4c 89 ef e8 e2 f7 ff ff eb db 0f 1f 44 00 00 55 48 89 e5 c7 05 81 36 7d 00 01 00 00 00 0f ae f8 c6 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 fe
[ 296.151439] RIP [ffffffffad274856] sysrq_handle_crash0x16/0x20
[ 296.152316] RSP ffff90eb456d7e58
[ 296.153205] CR2: 0000000000000000
[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]#2、方案二 (验证次数较少) 修改kdumpctl
该方案的优势是无需重启操作系统即可再下一次崩溃时生成对应的crash文件. kdumpctl 工具用于管理 kdump 服务允许管理员启动、停止、检查 kdump 的状态并重新加载配置。、
2.1 替换cmdline
修改 kdump 的 cmdline 参数可以通过编辑相关配置文件来实现。把remove_cmdline_param()和append_cmdline()方法直接修改成直接输出方式即$cmdline的值就是BOOT_IMAGE/vmlinuz-3.10.0-1160.el7.x86_64 rootUUID87afdba4-8e9d-4349-a068-23ac53d18164 ro crashkernel768M biosdevname0 net.ifnames0 rhgb quiet
[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]# cat /proc/cmdline
BOOT_IMAGE/vmlinuz-3.10.0-1160.el7.x86_64 rootUUID87afdba4-8e9d-4349-a068-23ac53d18164 ro crashkernel768M biosdevname0 net.ifnames0 rhgb quiet
[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]#
# remove_cmdline_param kernel cmdline param1 [param2] ... [paramN]
# Remove a list of kernel parameters from a given kernel cmdline and print the result.
# For each arg in the removing params list, arg and argxxx will be removed if exists.
remove_cmdline_param()
{local cmdline$1shiftfor arg in $; docmdlineecho $cmdline | \sed -e s/\b$arg[^ ]*//g \-e s/^$arg\b//g \-e s/[[:space:]]$arg\b//g \-e s/\s\/ /gdoneecho $cmdline
}#
# This function appends argument $2$3 to string ($1) if not already present.
#
append_cmdline()
{local cmdline$1local newstr${cmdline/$2/}# unchanged str implies argument wasnt thereif [ $cmdline $newstr ]; thencmdline${cmdline} ${2}${3}fiecho $cmdline
}[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]# cat /proc/cmdline
BOOT_IMAGE/vmlinuz-3.10.0-1160.el7.x86_64 rootUUID87afdba4-8e9d-4349-a068-23ac53d18164 ro crashkernel768M biosdevname0 net.ifnames0 rhgb quiet[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]# current_cmdline$(cat /proc/cmdline)
[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]# echo Current cmdline: $current_cmdline
Current cmdline: BOOT_IMAGE/vmlinuz-3.10.0-1160.el7.x86_64 rootUUID87afdba4-8e9d-4349-a068-23ac53d18164 ro crashkernel768M biosdevname0 net.ifnames0 rhgb quiet[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]# new_cmdline$(remove_cmdline_param $current_cmdline crashkernel)
[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]# echo Cmdline after removing crashkernel: $new_cmdline
Cmdline after removing crashkernel: BOOT_IMAGE/vmlinuz-3.10.0-1160.el7.x86_64 rootUUID87afdba4-8e9d-4349-a068-23ac53d18164 ro biosdevname0 net.ifnames0 rhgb quiet[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]# updated_cmdline$(append_cmdline $new_cmdline crashkernel 768M)
[rootdlp2-99-230 127.0.0.1-2024-08-05-11:56:35]# echo Updated cmdline: $updated_cmdline
Updated cmdline: BOOT_IMAGE/vmlinuz-3.10.0-1160.el7.x86_64 rootUUID87afdba4-8e9d-4349-a068-23ac53d18164 ro biosdevname0 net.ifnames0 rhgb quiet crashkernel768M
2.2 模拟crash
参考1.4模拟crash该方案更加便捷但是缺点也非常明显不利于统一管理也有可能会带来其他kdumpctl周边问题。
四、总结
针对公司近期遇到的Centos7.9操作系统kdump crash文件vmcore未生成问题可能也有多种原因针对该现象最好的办法就是分析日志根据日志的异常和kdump的实现原理去分析推测可能卡住的地方。具体的crashkernel预留可参考调整 crashkernel 参数https://blog.csdn.net/qq_28513801/article/details/140925575 如有任何疑问或需要进一步的帮助请随时留言讨论。
