当Linux服务器发生宕机，无论是内核崩溃、硬件故障还是资源耗尽导致的非预期重启，系统都会在可用的情况下把关键现场信息记录到特定位置。搞清楚这些日志分别在哪，是事后排错的第一步。不同发行版、不同启动方式（systemd或sysvinit）以及是否配置了kdump，都会影响日志的最终落盘路径。
一、常规系统日志路径
大多数基于systemd的Linux发行版（如CentOS 7及以上、Ubuntu 16.04及以上）默认使用journald统一管理日志，但也会同步写入传统文本文件。最常见的宕机前后记录位于/var/log目录下。其中/var/log/kern.log专门存放内核打印的信息，如果宕机前内核发生了oops或soft lockup，这里通常会有函数调用栈。Debian系发行版偏好此文件，而RHEL系则多使用/var/log/messages来记录包括内核在内的综合信息。
需要注意的是，如果系统已经完全死锁，这些文件可能不会实时刷盘。因为文件系统缓存未回写，最后一次记录可能停留在崩溃前几分钟。此时不能仅凭文件末尾时间判断故障点，而应结合其他持久化机制。对于使用sysvinit的老系统，/var/log/syslog也是重要参考，它类似messages但更偏向用户态服务报错。
/var/log/kern.log：Ubuntu/Debian内核日志/var/log/messages：CentOS/RHEL综合日志/var/log/syslog：通用系统日志（部分发行版）
二、systemd journal的上一启动记录
若系统采用systemd，单纯看文本文件可能漏掉早期启动或崩溃瞬间的日志，因为journald将数据存为二进制。通过journalctl命令可以读取上一次启动（即宕机那次）的日志。使用journalctl -b -1能列出崩溃前最后一次引导的全部记录，配合-p err可只显示错误级别以上信息。这种方式比翻文本文件更可靠，因为journald支持按引导ID隔离，不会混淆多次重启。
实际操作时可先执行journalctl --list-boots查看历史引导序号，再用对应的偏移量读取。例如journalctl -b -1 -k只显示上次启动的内核日志，适合分析驱动崩溃。如果宕机发生在系统还未完全起来时，journal可能只捕获到少量initrd阶段信息，这时就要依赖下面的kdump或dmesg了。
# 查看历史启动列表 journalctl --list-boots # 读取上一次启动的全部日志 journalctl -b -1 # 仅看上次启动的内核错误 journalctl -b -1 -k -p err
三、内核崩溃转储与kdump
当内核发生严重错误（panic）且配置了kdump服务时，系统会启用备用内核将内存快照导出为vmcore文件。默认路径通常为/var/crash，目录下按时间生成子目录，里面包含vmcore及辅助脚本。分析该文件需要crash工具，它能还原崩溃时的进程状态、内存布局和寄存器值，是定位驱动内存越界的首选证据。
如果/var/crash为空，说明kdump未启用或预留内存不足。可在/etc/default/grub中为内核添加crashkernel=auto参数并更新grub后重启生效。没有vmcore时，只能靠kern.log里的栈回溯做粗略判断。对于云服务器，部分厂商把vmcore自动上传到对象存储，本地反而看不到，需要去控制台下载。
# 检查kdump状态 systemctl status kdump # 查看崩溃目录 ls -lh /var/crash/ # 使用crash分析（需安装crash和内核调试包） crash /var/crash/127.0.0.1-2023/vmcore /usr/lib/debug/lib/modules/$(uname -r)/vmlinux
四、dmesg环形缓冲区与硬件日志
如果系统没配置持久化journal，重启后dmesg命令显示的是本次启动的环缓冲，但上次宕机前的片段可能随内存清空丢失。不过某些发行版会通过systemd-journald或rsyslog把dmesg落盘到/var/log/dmesg。此外，硬件层如IPMI或服务器带外管理（BMC）会独立记录电源丢失、内存ECC错误，这些不在操作系统文件系统里，而要通过ipmitool sel list读取。
对于watchdog造成的重启，内核日志常仅留下watchdog: BUG: soft lockup字样，此时操作系统文件无更多细节，必须结合BMC的硬件日志判断是否是CPU过热。在虚拟机环境，hypervisor层日志（如KVM的/var/log/libvirt/qemu）也能侧面反映客户机宕机前的资源抢占情况。
| 日志类型 | 常见路径 | 适用场景 |
|---|---|---|
| 文本内核日志 | /var/log/kern.log | Debian系内核oops |
| 综合消息日志 | /var/log/messages | RHEL系通用记录 |
| 二进制journal | /run/log/journal或/var/log/journal | systemd上次启动 |
| 崩溃转储 | /var/crash | kdump内存快照 |
| 硬件事件 | IPMI SEL（非文件） | 断电、ECC故障 |
五、快速排错建议
遇到宕机，建议按序排查：先journalctl -b -1看上次引导错误；再检查/var/log/kern.log或messages末尾；若有kdump则分析/var/crash下的vmcore；最后用ipmitool确认硬件无告警。切忌一上来就重装，很多内存故障通过日志能直接看到地址报错。
日常应提前开启kdump并预留足够内存，同时配置rsyslog远程转发，这样即使本地磁盘损坏也能从日志服务器拿到宕机前记录。养成定期看dmesg和BMC事件的习惯，能在真正宕机前发现苗头。