Linux 核心崩潰分析完整指南：kdump 部署、vmcore 收集與 crash 工具實戰

前言：為什麼需要 kdump？

Linux 核心雖穩定，但硬體錯誤、驅動缺陷、記憶體損壞仍可能觸發核心恐慌。kdump 利用 kexec 機制，在核心崩潰瞬間快速啟動一個預先載入的捕獲核心 (crash kernel)，將崩潰時的記憶體鏡像 (vmcore) 轉儲至本地磁碟、NFS 或 SSH 遠端，供事後分析根因。

一、kdump 部署步驟 (RHEL/CentOS 7/8)

1. 安裝必要套件

yum install -y kexec-tools crash kernel-debuginfo-$(uname -r)
# kernel-debuginfo 版本必須與執行中核心完全一致

2. 設定核心參數保留記憶體

編輯 /etc/default/grub，在 GRUB_CMDLINE_LINUX 追加：

crashkernel=384M-:128M
# 表示實體記憶體 > 384MB 時保留 128MB 給 crash kernel
# 不建議使用 crashkernel=auto (RHEL 8 已棄用)

重建 grub 設定並重啟：

grub2-mkconfig -o /boot/grub2/grub.cfg
reboot

3. 配置 kdump 轉儲目標 (/etc/kdump.conf)

path /var/crash                 # 本地儲存路徑
core_collector makedumpfile -c --message-level 1 -d 31
# -c 壓縮, -d 31 排除零頁/快取頁/使用者頁/自由頁等非必要頁面
# 可改為 NFS/SSH 遠端:
# nfs 192.168.1.100:/export/crash
# ssh user@192.168.1.100

4. 啟用並驗證服務

systemctl enable kdump.service --now
systemctl status kdump.service

5. 觸發測試 (謹慎操作，僅限測試環境)

echo c > /proc/sysrq-trigger
# 系統會崩潰重啟，重啟後檢查 /var/crash/ 是否生成 vmcore 檔案

二、crash 工具分析 vmcore 實戰

啟動 crash

crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/127.0.0.1-2023-10-01-10:00/vmcore

關鍵摘要欄位解讀

常用分析指令

實戰範例：bt 定位崩潰點

crash> bt
PID: 1728  TASK: ffff8800...  CPU: 2  COMMAND: "bash"
 #0 [ffff8800...] machine_kexec at ffffffff8103...
 #1 [ffff8800...] __crash_kexec at ffffffff810...
 #2 [ffff8800...] panic at ffffffff815...
 #3 [ffff8800...] sysrq_handle_crash+0x16 at ffffffff81...
 #4 [ffff8800...] __handle_sysrq at ffffffff81...
 #5 [ffff8800...] write_sysrq_trigger at ffffffff81...
 #6 [ffff8800...] proc_reg_write at ffffffff81...
 #7 [ffff8800...] vfs_write at ffffffff81...
 #8 [ffff8800...] ksys_write at ffffffff81...
 #9 [ffff8800...] __x64_sys_write at ffffffff81...
#10 [ffff8800...] do_syscall_64 at ffffffff81...
#11 [ffff8800...] entry_SYSCALL_64_after_hwframe at ffffffff81...
RIP: 00007f...  RSP: 00007f...  RFLAGS: 00000246
RAX: 0000000000000001  RBX: 0000000000000000  RCX: 0000000000000000
...
[exception RIP: sysrq_handle_crash+22]  ← 核心函式 sysrq_handle_crash 偏移 22 處觸發例外
CS: 0010 (CPL=0 核心模式)

堆疊顯示透過 /proc/sysrq-trigger 手動觸發崩潰 (測試用)。實際生產崩潰會顯示驅動函式、記憶體管理路徑等關鍵線索。

log 指令對照 dmesg 找線索

核心會印出 Call Trace 與 RIP，配合 bt 交叉驗證。

ps 觀察進程狀態

swapper (PID 0) 為每核心一個的排程器進程；崩潰進程 bash (PID 1728) 標記為活躍。

files 追蹤檔案操作

可見觸發崩潰前操作 /proc/sysrq-trigger。

三、核心錯誤分級與後續行動

• Bug：輕微邏輯錯誤，通常不影響運行。
• Oops：單一進程嚴重錯誤，核心殺死該進程並嘗試繼續；若持有鎖未釋放，系統進入不確定狀態。
• Panic：核心判定無法安全繼續，立即停機 (需 kdump 捕獲)。

深入分析需結合核心原始碼、addr2line 解析位址、git bisect 定位引入缺陷的提交。建立完整 kdump + crash 分析流程，是提升 Linux 系統可靠性的關鍵環節。