必须组合last、journalctl、dmesg和系统日志交叉比对时间点与异常信号：先用last -x确认关机/重启事件及时间戳，再用journalctl -b -1查上一次启动上下文，结合dmesg -T挖内核死因，最后以/var/log/messages或syslog兜底验证。
没有单一命令能直接告诉你“为什么关机或重启”，必须组合 last、journalctl、dmesg 和系统日志交叉比对时间点与异常信号。
用 last -x 快速确认历史关机/重启事件
这是最轻量、权限要求最低的起点，它读取 /var/log/wtmp，不依赖 systemd 或日志持久化设置：
-
last -x列出所有关机（shutdown）、重启（reboot）和运行级变更（runlevel）记录，按时间倒序排列 - 关注
shutdown system down行末的时间戳，它代表关机发生时刻；reboot system boot行末则是重启启动时刻 - 若某次关机后紧接着出现
crash（如pdsyw tty1 :0 Wed Mar 25 13:30 - crash (00:27)），说明不是正常关机，而是内核崩溃或强制断电 - 普通用户可直接执行，无需 sudo；但
/var/log/wtmp权限受限时可能只显示部分记录
用 journalctl -b -1 查上一次启动的完整上下文
systemd 系统的日志主入口，但前提是日志已持久化——否则 -b -1 可能为空或不可靠：
- 先运行
journalctl --disk-usage：若输出为0B或提示“No journal files”，说明日志仅存内存，-b -1无效，需先启用持久化：sudo mkdir -p /var/log/journal/ && sudo systemctl restart systemd-journald - 倒序查看末尾 100 行：
journalctl -b -1 -n 100 -r，重点找是否出现Reached target Power-Off、systemd-shutdown或Syncing filesystems—— 这些是正常关机标志 - 若末尾突然中断、无 shutdown 相关条目，或出现
Kernel panic、watchdog、Timed out waiting for device，大概率是崩溃或硬件卡死导致硬重启 - 搜索关键错误：
journalctl -b -1 | grep -E "(Failed|killed process|aborted|Dependency failed|nvme.*error)"
用 dmesg -T 挖内核层真实死因
systemd 日志常只记“正在关机”，真正触发重启的线索往往藏在内核环缓冲区里，尤其是 OOM、硬件故障这类底层问题：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 重启后**立即**执行
dmesg -T，越晚执行越可能被新日志覆盖；/var/log/messages或/var/log/syslog是它的持久化备份 - 查 OOM 杀手证据：
dmesg -T | grep -i "killed process"，输出含进程名和 PID，是内存耗尽→系统僵死→自动重启的铁证 - 查硬件异常：
dmesg -T | grep -A2 -B2 "BERT\|mce\|thermal"，其中BERT表示 BIOS 级 ECC 内存错误，mce是 CPU/PCIe 机器校验异常，thermal是过热强制关机 - 确认是否真重启完成：
dmesg -T | tail -n 20，末尾出现Restarting system或Machine restart才算闭环；若只有Kernel panic无后续，则可能是 panic 后未自动重启
交叉验证 /var/log/messages 或 /var/log/syslog
journal 可能被轮转、清理或配置为内存存储，而传统文本日志更持久，是兜底依据：
- RHEL/CentOS 系统查：
grep -B2 -A3 "shutting down" /var/log/messages，重点关注“shutting down”前后的几行，常能捕获磁盘 I/O hang、服务崩溃等前兆 - Debian/Ubuntu 系统查：
grep -i "kernel panic\|out of memory\|system boot" /var/log/syslog - 不要只搜
reboot，很多异常重启根本不会在 syslog 里写这个词；要结合who -b给出的精确重启时间，用grep -A5 -B5 "2026-10-01 14:16"截取附近日志 - 注意日志时间可能与系统实际时间不同步，尤其在虚拟机或 NTP 未同步时，优先信
who -b的内核时间戳
真正难的不是命令怎么敲，而是把 who -b 的时间锚点、journalctl -b -1 里的服务超时、dmesg 中的 mce 错误、以及 /var/log/messages 里最后一行业务日志，拼成一条可信的时间链。任何一环缺失或矛盾，都得回头检查日志是否被覆盖、持久化是否启用、或时间是否同步。
