Linux服务器自动重启怎么查错误日志，如何排查重启原因？

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，更有效的做法是：先确认重启发生在几点，再看重启前几分钟发生了什么。

加载中

【应急响应】Linux篇-排查系统日志

助安社区

2万5928

原视频地址

用 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 流程，多半是正常重启或人为触发，如果日志突然中断，下一次启动直接开始，那就要怀疑 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服务器重启日志命令有哪些

排查自动重启不一定需要付费工具,系统自带命令已经能覆盖大部分场景。

最可靠的组合是：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 提前配好，比事后翻日志更有效。