怎样定位linux宕机日志

在 Linux 系统“宕机”（死机、卡死、重启、Kernel Panic、OOM 等）后，定位日志是关键一步。下面按常用程度 + 场景给你一个系统性的排查路径。

一、先看系统日志（最常用）

1. 使用 journalctl（systemd 系统，最常见）

journalctl -xb

• -x：显示解释
• -b：本次启动日志
• 查看上一次启动（宕机前）：

journalctl -b -1

筛选关键错误：

journalctl -b -1 | grep -iE "error|panic|oom|kill|segfault|watchdog"

2. 传统日志文件（非 systemd 或老系统）

/var/log/messages
/var/log/syslog
/var/log/dmesg

查看：

less /var/log/messages
grep -i "panic" /var/log/messages

二、内核崩溃 / 死机（Kernel Panic）

1. dmesg（启动阶段信息）

dmesg | less
dmesg -T | grep -i panic

如果系统已重启，可看：

journalctl -k

2. kdump + crash（专业定位）

如果开启了 kdump：

ls /var/crash/
crash /usr/lib/debug/vmlinux /var/crash/xxx/vmcore

可看到：

• 崩溃时的调用栈
• 是哪个进程 / 驱动导致

三、内存耗尽（OOM Killer）

特征

• 系统突然卡死
• 然后某些进程被杀
• 或直接重启

日志关键字

grep -i "out of memory" /var/log/messages
journalctl | grep -i "oom"

示例：

Out of memory: Kill process 1234 (java)

四、硬件 / 电源 / 看门狗问题

1. 意外断电 / 假死

last reboot
who -b

异常重启：

reboot   system boot

2. 硬件错误（内存、CPU）

grep -i "mce" /var/log/messages
grep -i "hardware error" /var/log/messages

3. 看门狗复位

grep -i watchdog /var/log/messages

五、进程级宕机（不是系统宕机）

1. core dump

ulimit -c
ls -l core*

分析：

gdb ./app core
bt

2. 应用日志

• Java：hs_err_pid*.log
• Nginx：error.log
• 自定义：/var/log/xxx/

六、推荐的标准排查顺序

1. journalctl -b -1
2. dmesg -T | grep -i panic
3. grep OOM /var/log/messages
4. last reboot
5. 有 kdump → 分析 vmcore
6. 硬件日志（IPMI / BMC / dmesg MCE）

七、如果你愿意，我可以更具体帮你

你可以补充：

• 是 整机死机 / 重启 / 卡死？
• 是否有 kdump？
• 系统版本（uname -a）
• 宕机前在跑什么（数据库 / Java / 容器）？

我可以直接帮你“读日志”。