必须组合查日志、看上下文、交叉比对时间点才能确定重启原因：先用 who -b 获取精确重启时间锚点，再通过 journalctl -b -1、dmesg 和 /var/log/messages 等多源日志协同分析，覆盖软件崩溃、oom、硬件故障等全场景。

没有单一命令能直接告诉你“重启原因”，必须组合查日志、看上下文、交叉比对时间点。

先确认最近一次重启的确切时间

别跳步——很多排查失败，是因为连“什么时候重启的”都没对准。用 who -b 最快最可靠，它直接读内核启动时间戳，不受日志轮转或权限影响：

• who -b 输出如 system boot 2026-06-09 03:17，这就是你所有后续排查的时间锚点
• last reboot -n 1 也能看，但依赖 /var/log/wtmp，普通用户可能无权读，得加 sudo
• uptime 只能估算，误差可能达几分钟，不建议作为唯一依据

用 journalctl 锁定上一次启动的完整日志流

现代 Linux（systemd）的日志主入口是 journalctl，-b -1 是查“上一次启动”的黄金参数：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• journalctl -b -1 -p err：只看错误级日志，快速定位崩溃源头
• journalctl -b -1 | grep -i "reboot\|shutting down\|panic\|oom\|watchdog"：关键词扫描，覆盖常见诱因
• 如果重启前有明显卡顿或负载飙升，加 --since "2026-06-09 03:10:00" 精确截取重启前 5–10 分钟日志

深挖内核层线索，尤其是 OOM 和硬件错误

systemd 日志可能只记录“正在关机”，真正死因藏在内核环缓冲区里：

• dmesg -T -L | grep -i "killed process"：找到被 OOM Killer 杀掉的进程名和 PID，这是“内存耗尽→系统僵死→自动重启”的典型链路
• dmesg -T | grep -A2 -B2 "BERT\|mce\|thermal"：BERT 是 BIOS 错误记录表，mce 是机器校验异常（内存/PCIe 硬件故障），thermal 是过热强制关机
• dmesg -T | tail -n 100：重启后立即执行，看最后几条是否含 Restarting system 或 Machine restart

交叉验证系统级日志，防日志丢失或覆盖

journal 可能被配置为内存存储或定期清理，/var/log/messages 或 /var/log/syslog 是更持久的备份：

• RHEL/CentOS 系统：grep -i "shutting down\|system boot\|out of memory" /var/log/messages
• Debian/Ubuntu 系统：grep -i "shutting down\|system boot\|kernel panic" /var/log/syslog
• 重点看“shutting down”前后的 5 行：grep -B2 -A3 "shutting down" /var/log/messages，常能捕获服务崩溃、磁盘 I/O hang 等前兆

真正难的不是命令怎么敲，而是把 who -b 给出的时间、journalctl -b -1 里的错误、dmesg 中的硬件警告、以及 /var/log/messages 里最后一行业务日志，拼成一条时间线。漏掉任意一环，都可能把“硬盘坏道导致内核 panic”误判成“管理员手抖敲了 reboot”。