Linux服务器自动重启后，先别急着重装系统，第一优先执行 last reboot、journalctl --list-boots、journalctl -b -1 -p err，再按发行版查 /var/log/messages、/var/log/syslog、/var/log/kern.log，最后结合 IPMI/BMC 日志确认是内核崩溃、硬件故障、云平台迁移还是人为重启。
先建立时间线：Linux服务器自动重启怎么查看系统日志
服务器重启后,日志很多，最容易犯的错是上来就 grep error，更有效的做法是：先确认重启发生在几点，再看重启前几分钟发生了什么。
用 last 和 journalctl 定位上一次启动
登录后先执行几条基础命令：
last reboot | head -20 last -x | head -30 who -b uptime journalctl --list-boots --no-pager
last reboot 能列出历史重启时间。last -x 还会显示 shutdown、runlevel 切换。journalctl --list-boots 会列出每次启动会话，0 是当前，-1 是上一次，-2 是上上次。
如果系统使用 systemd，直接看上一次启动的错误日志：
journalctl -b -1 -p err..alert --no-pager journalctl -b -1 -k --no-pager | tail -200 journalctl -b -1 --since "2026-01-01 10:00:00" --until "2026-01-01 10:10:00"
关键点：journalctl -b -1 是排查自动重启最省力的入口。 但前提是 journal 日志已经持久化。/var/log/journal 不存在，重启后上一次日志可能只剩内存里的部分内容。
正常重启与异常重启的日志差异
不同重启类型,日志线索完全不同：
| 重启类型 | 典型线索 | 优先命令 |
|---|---|---|
| 正常重启 | shutdown、reboot、systemd 正常停止服务 | last -x、grep -i reboot /var/log/messages |
| 内核崩溃 | Kernel panic、Oops、BUG、watchdog | journalctl -b -1 -k、grep -iE "panic|Oops|BUG" |
| 硬件/电源 | IPMI SEL、ECC、CPU IERR、Power Supply | ipmitool sel list、mcelog |
| 云平台迁移 | 控制台系统事件、宿主机维护 | 云监控、云审计 |
| 人为操作 | sudo reboot、shutdown、auditd 记录 | grep -i reboot /var/log/secure |
先判断“怎么重启的”，再判断“为什么重启”。 如果日志里有完整的 shutdown 流程，多半是正常重启或人为触发，如果日志突然中断，下一次启动直接开始，那就要怀疑 panic、掉电、看门狗或宿主机故障。
服务器自动重启日志在哪个目录：不同发行版对照
Linux 发行版不同，日志路径也不同，找错文件，等于白忙。
CentOS、RHEL、Rocky、AlmaLinux
/var/log/messages：综合系统日志，重启线索常在这里。/var/log/dmesg：内核启动和硬件检测信息。/var/log/boot.log：启动过程日志。/var/log/secure：SSH、sudo、认证相关。/var/log/audit/audit.log：审计日志，能查到谁执行了 reboot。/var/log/kern.log：部分系统也会有内核日志。
Ubuntu、Debian
/var/log/syslog：综合系统日志。/var/log/kern.log：内核日志，panic、驱动错误优先看。/var/log/auth.log：认证和 sudo 操作。/var/log/boot.log：启动日志。/var/log/journal：systemd journal 持久化目录。
通用 journal 持久化设置
journalctl -b -1 提示找不到上一次启动，检查：
ls -ld /var/log/journal grep -E "^Storage" /etc/systemd/journald.conf df -h /var/log
需要持久化时：
mkdir -p /var/log/journal systemd-tmpfiles --create --prefix /var/log/journal systemctl restart systemd-journald
没有持久化 journal，也没有远程 syslog，自动重启后的关键日志很可能已经丢了。 业内专家指出，异常重启的排查不能只看一个日志文件，要把系统日志、内核日志、带外日志和云平台事件串起来看。
Linux服务器意外重启排查方法：内核、硬件、电源与云平台
时间线和日志路径确定后,就进入根因排查，建议按四条线走：内核、硬件、电源、云平台或人为操作。
内核 panic 与 OOM 要分开看
先搜内核错误：
grep -iE "kernel panic|Oops|BUG:|watchdog|hard lockup|soft lockup" /var/log/messages /var/log/syslog /var/log/kern.log journalctl -b -1 -k --no-pager | grep -iE "panic|Oops|BUG|RIP|Call Trace"
OOM 通常会杀掉进程，不一定重启整机，但如果内核参数设置了 panic_on_oom，或者关键服务连锁崩溃，也可能触发重启，检查：
grep -i oom /var/log/messages /var/log/syslog /var/log/kern.log sysctl kernel.panic kernel.panic_on_oom
有 kdump 的系统，崩溃转储通常在 /var/crash，可以用 crash 工具分析 vmcore，没有 kdump，就只能靠 dmesg -T、journal 和远程日志。
硬件和电源：带外日志更可靠
系统日志可能来不及写盘,带外管理日志反而更完整，常见命令：
ipmitool sel list ipmitool sel elist ipmitool chassis status ipmitool sensor list mcelog --client rasdaemon -f edac-util -v
SEL 里出现 Power Supply、ECC、CPU IERR、Watchdog、Temperature 等字样，方向基本能锁定到硬件或电源，北京、上海等机房还要关注机柜供电切换、UPS 切换记录，行业共识认为，先确定重启时间点，再倒推前几分钟的日志，比盲目全文搜索更高效。
云服务器和虚拟化场景
云主机看不到宿主机 IPMI，此时要看云控制台：
- 系统事件：实例重启、宿主机迁移、维护通知。
- 云监控：CPU、内存、磁盘、网络突刺。
- 云审计：是否有控制台重启、API 重启操作。
- 云助手日志：
/var/log/cloud-init.log、/var/log/cloud-init-output.log。
近年来,不少云服务器用户把自动重启误判为系统故障，实际是宿主机维护或迁移，据工信部公开的运维规范思路，日志留存和带外管理是服务器故障定位的基础能力。
人为操作与定时任务
查认证日志：
grep -iE "reboot|shutdown" /var/log/secure /var/log/auth.log ausearch -m SYSTEM_BOOT -ts recent ausearch -m USER_LOGIN -ts recent
再查定时任务和自动更新：
crontab -l ls -l /etc/cron. systemctl list-timers --all grep -R "reboot" /etc/cron /etc/systemd/system 2>/dev/null
Ubuntu 还要看 unattended-upgrades 和 needrestart 是否配置了自动重启。
免费查看Linux服务器重启日志命令有哪些
排查自动重启不一定需要付费工具,系统自带命令已经能覆盖大部分场景。
| 工具/命令 | 用途 | 是否重启后保留 |
|---|---|---|
last reboot |
查看重启历史 | 看 wtmp 是否轮转 |
journalctl -b -1 |
上一次启动日志 | 需持久化 journal |
dmesg -T |
内核消息 | 重启后可能不完整 |
sar -q |
历史负载 | 需 sysstat 提前开启 |
ipmitool sel list |
硬件事件 | 带外保留 |
mcelog |
CPU/内存硬件错误 | 需服务运行 |
lnav |
日志查看器 | 免费，适合多文件 |
最可靠的组合是：journal 持久化 + rsyslog 远程转发 + IPMI SEL。 可以配置远程日志：
# 在 /etc/rsyslog.conf 或 /etc/rsyslog.d/ 下增加 . @@10.0.0.100:514 systemctl restart rsyslog
TCP 转发比 UDP 更稳，远程日志服务器不要和业务服务器同机房、同电源。
北京机房Linux服务器自动重启怎么查日志：现场与远程两条路
如果服务器在北京机房,远程能 SSH 时先按上面的日志顺序查，SSH 进不去，就走带外 KVM、IPMI、iDRAC、iLO 或云控制台 VNC。
远程先收集证据
journalctl -b -1 --no-pager > /tmp/boot-1.log dmesg -T > /tmp/dmesg.log ipmitool sel list > /tmp/ipmi-sel.log cp /var/log/messages /var/log/syslog /var/log/kern.log /tmp/ 2>/dev/null tar czf /tmp/reboot-logs.tar.gz /tmp/boot-1.log /tmp/dmesg.log /tmp/ipmi-sel.log
不要急着重启,重启会覆盖部分环状日志，先保全证据。
现场检查重点
- 电源模块指示灯、冗余电源状态。
- 风扇、进风口温度、机柜温度。
- RAID 卡日志、硬盘掉线记录。
- iDRAC/iLO/IPMI SEL 事件时间。
- 机房 UPS、PDU、供电切换记录。
自动重启排查的核心不是找一条 error，而是还原重启前的时间线。 系统日志、内核日志、带外日志、云平台事件相互印证，才能避免误判。
Q&A：Linux服务器自动重启错误日志常见问题
Linux服务器自动重启后，journalctl -b -1 查不到上一次启动怎么办？
先确认 journal 是否持久化，检查 /var/log/journal 是否存在，/etc/systemd/journald.conf 里 Storage 是否为 persistent，如果没持久化，改配置并重启 systemd-journald，同时看 /var/log/messages、/var/log/syslog、/var/log/kern.log 是否还有记录，磁盘满、日志轮转过快、rsyslog 未运行，也会导致重启日志缺失。
云服务器自动重启，为什么本地日志看不到硬件错误？
因为云主机是虚拟机,CPU、内存、电源、宿主机故障由云厂商管理，本地只能看到虚拟化层内核日志、cloud-init 日志和云助手日志，应查云控制台系统事件、云监控报警、宿主机迁移记录、云审计操作，云厂商公开文档通常会说明系统事件类型和通知方式。
服务器自动重启日志看到 Kernel panic，下一步怎么确认原因？
先看 panic 前最后 200 行：
journalctl -b -1 -k --no-pager | tail -200 grep -iE "panic|Oops|BUG|RIP|Call Trace" /var/log/kern.log /var/log/messages
有 kdump 就分析 /var/crash 下的 vmcore；没有 kdump，就查内存、CPU、驱动、固件和 IPMI SEL，若日志里只有 panic，没有硬件事件，下一步应配置 kdump 和远程 syslog，等待复现，没有 kdump 和远程日志时，重启后现场日志可能被覆盖，只能依赖带外日志和云平台事件。
Linux服务器自动重启后，正确顺序是：先看重启时间线，再查发行版对应日志，最后用带外和云平台日志交叉验证。 把 journal 持久化、远程 syslog 和 IPMI SEL 提前配好，比事后翻日志更有效。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/linux%e6%9c%8d%e5%8a%a1%e5%99%a8%e8%87%aa%e5%8a%a8%e9%87%8d%e5%90%af%e6%80%8e%e4%b9%88%e6%9f%a5%e9%94%99%e8%af%af%e6%97%a5%e5%bf%97%ef%bc%8c%e5%a6%82%e4%bd%95%e6%8e%92%e6%9f%a5%e9%87%8d%e5%90%af/
