linux系统崩溃后，应依次解析systemd-journald日志、/var/log/kern.log、vmcore-dmesg（kdump启用时）、/var/log/syslog，并验证内核panic与core_pattern设置，以定位根本原因。
当 Linux 系统发生非预期崩溃（如内核 panic、系统卡死或自动重启）后，残留的日志是定位根本原因的关键依据。以下是针对常见崩溃场景开展日志解析的实操步骤：
一、提取 systemd-journald 崩溃前日志
systemd-journald 默认将内核与服务日志持久化存储于 /var/log/journal/，崩溃前最后数分钟的结构化日志可直接追溯时间线与异常服务。
1、使用 sudo journalctl 命令读取上次启动的完整日志流。
2、执行 sudo journalctl -b -1 --no-pager > /tmp/last_boot.log 将上一次启动日志导出为纯文本文件。
3、用 grep -i "panic\|oom\|segfault\|killed process" /tmp/last_boot.log 筛选高危关键词行。
4、定位到最早出现 Out of memory: Kill process 或 Kernel panic - not syncing 的时间戳及前后 50 行上下文。
二、分析 /var/log/kern.log 中的内核环缓冲区快照
/var/log/kern.log 由 rsyslog 或 systemd-journal-gateway 持久化记录，包含 dmesg 输出的原始内核消息，尤其适用于未启用 journald 持久化的轻量系统。
1、运行 sudo tail -n 200 /var/log/kern.log 查看末尾高频日志段。
2、使用 sudo dmesg -T | grep -A 5 -B 5 "Hardware error\|NMI watchdog\|machine check\|uncorrectable" 提取硬件级错误线索。
3、检查是否存在重复出现的 ata[0-9]\+.*timeout 或 nvme.*reset timeout，指向磁盘或 NVMe 控制器故障。
三、解码 vmcore-dmesg 日志（kdump 启用时）
若系统已配置 kdump 并成功捕获 vmcore，/var/crash/ 下的最新子目录中包含压缩的内存镜像和配套的 vmcore-dmesg.txt，该文件是内核崩溃瞬间的完整 ring buffer 快照，无需符号表即可读取关键堆栈。
1、进入最新崩溃目录：cd /var/crash/$(ls -t /var/crash | head -n1)。
2、解压日志：zcat vmcore-dmesg.txt.gz > /tmp/vmcore-dmesg.txt。
3、搜索 RIP: [a-f0-9]\+ 行，确认崩溃发生的具体函数地址。
4、查找紧邻的 Call Trace: 区块，逐行比对模块名与偏移量，例如 ? ext4_writepages+0x[0-9a-f]+/[0-9a-f]+ 暗示 ext4 文件系统层异常。
四、检查 /var/log/syslog 中服务级连锁失败痕迹
syslog 记录了用户空间守护进程的退出、超时与资源拒绝事件，常反映崩溃前的服务雪崩现象，例如数据库连接池耗尽引发 Web 服务拒绝响应，最终触发 OOM Killer。
1、执行 sudo awk '/systemd\[1\]:.*failed|CRITICAL|EMERG/ && $3 > "'$(date -d '1 hour ago' '+%b %d %H:')'00"' /var/log/syslog 查找一小时内严重级别事件。
2、筛选连续出现的 Failed to start [^ ]* 或 Unit .* entered failed state 条目。
3、比对时间戳，确认是否在内核 panic 日志出现前 2–3 分钟集中爆发多个单元失败。
五、交叉验证 /proc/sys/kernel/panic 和 kernel.core_pattern 设置
系统级崩溃行为受内核参数控制，解析日志前需确认当前配置是否允许有效捕获，避免因设置不当导致关键信息丢失。
1、运行 cat /proc/sys/kernel/panic 查看崩溃后自动重启秒数，值为 0 表示禁用自动重启，应能保留 panic 界面供拍照记录。
2、执行 sysctl kernel.core_pattern 查看核心转储路径，若返回 |/usr/lib/systemd/systemd-coredump 表明启用 systemd coredump 机制，对应日志位于 /var/lib/systemd/coredump/。
3、检查 ls -l /var/lib/systemd/coredump/core.* 是否存在近期生成的 coredump 文件，其文件名中包含 signal=11（SIGSEGV）或 signal=6（SIGABRT）标识终止信号类型。
