如何查找Linux重启原因?

经常发生Linux系统以未计划的方式或由于未知的表面原因重新启动。找到并解决根本原因可以帮助防止此类问题的再次发生,并避免计划外的停机时间。

有几种方式可以找出triggered a reboot。在本文中,我们将讨论这些方式以及您如何利用Linux系统中的可用工具和日志来排除此类情况。

检查重启时间

您可以使用wholast命令检查系统重启的时间。

$ who -b
系统启动时间:2021-02-13 20:51

$ last -x | head | tac
abhishek pts/0 192.168.1.16 周六 2月 13 19:53 - 19:55 (00:02)
reboot 系统启动 3.10.0-1160.11.1 周六 2月 13 19:55 - 20:54 (00:58)
runlevel (到 lvl 3) 3.10.0-1160.11.1 周六 2月 13 19:55 - 20:04 (00:08)
abhishek pts/0 192.168.1.16 周六 2月 13 19:56 - 20:04 (00:07)
reboot 系统启动 3.10.0-1160.11.1 周六 2月 13 20:04 - 20:54 (00:49)
runlevel (到 lvl 3) 3.10.0-1160.11.1 周六 2月 13 20:04 - 20:51 (00:46)
abhishek pts/0 192.168.1.16 周六 2月 13 20:04 - 20:50 (00:46)
reboot 系统启动 3.10.0-1160.11.1 周六 2月 13 20:51 - 20:54 (00:03)
runlevel (到 lvl 3) 3.10.0-1160.11.1 周六 2月 13 20:51 - 20:54 (00:02)
abhishek pts/0 192.168.1.16 周六 2月 13 20:51 仍在登录
$

检查系统消息

您可以进一步将要诊断的重启与系统消息进行关联。

对于CentOS/RHEL系统,您将在/var/log/messages找到日志,而对于Ubuntu/Debian系统,它记录在/var/log/syslog中。您可以使用tail命令或您喜欢的文本编辑器来过滤或查找特定数据。

从下面的日志可以推断出,这些条目暗示着由管理员或root用户发起的关闭/重新启动。这些消息可能因操作系统类型和触发重新启动/关闭的方式而有所不同,但通过查看系统日志,您总是可以找到有用的信息,尽管它可能不足以每次准确找到原因。

2月 13 19:56:20 centos7vm chronyd[637]: 源72.30.35.89已更换为142.147.92.5
2月 13 20:00:40 centos7vm chronyd[637]: 已选择源162.159.200.123
2月 13 20:01:01 centos7vm systemd: 创建用户root的会话。
2月 13 20:01:01 centos7vm systemd: 启动用户root的会话。
2月 13 20:04:09 centos7vm systemd-logind: 系统正在关机。
2月 13 20:04:09 centos7vm systemd: 关闭LVM2轮询守护程序套接字。
2月 13 20:04:09 centos7vm systemd: 停止目标Multi-User System。

您可以使用以下命令之一来过滤系统日志:

sudo grep -iv ': starting|kernel: .*: Power Button|watching system buttons|Stopped Cleaning Up|Started Crash recovery kernel' 
  /var/log/messages /var/log/syslog /var/log/apcupsd* 
  | grep -iw 'recover[a-z]*|power[a-z]*|shut[a-z ]*down|rsyslogd|ups'

捕获的事件可能不总是具体的。始终追踪会导致系统关闭/崩溃的警告或错误事件。

验证auditd日志

对于具有auditd的系统,使用ausearch工具检查不同事件的日志是一个很好的方法。使用以下命令检查审核日志的最后两个条目。

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4

这将报告最近的两次关闭或重新启动。如果报告了一个SYSTEM_SHUTDOWN后面跟着一个SYSTEM_BOOT,则一切正常。但是,如果报告连续两行SYSTEM_BOOT或仅一行SYSTEM_BOOT,那么很可能系统没有正常关闭。正常输出应该类似于以下内容:

下面的输出列出了两个连续的`SYSTEM_BOOT`消息,这可能表明系统发生了非正常关闭,但需要与系统日志进行关联分析。

以下是在我的服务器上的输出:

“`
$ journalctl –list-boots
-15 8a7c8034da804ebb9cb063a7553ed0bf Wed 2020-11-18 23:09:05 IST—Wed 2020-11-18 23:17:10 IST
-14 7bbb9542778a4057a91b9d22fcf91735 Wed 2020-11-18 23:17:22 IST—Wed 2020-11-18 23:20:08 IST
-13 f2ee8a61bf4c4f67a12e012855d8b1c3 Wed 2020-11-18 23:20:17 IST—Wed 2020-11-18 23:23:01 IST
-12 1277d19a959f4c33ba944a68c5874d2a Fri 2020-12-11 10:32:44 IST—Fri 2020-12-11 10:43:39 IST
-11 eb4ff97f112445888a5946d1155de1b8 Fri 2020-12-11 10:43:55 IST—Fri 2020-12-11 10:48:18 IST
-10 bf46eff3f9a344d2b28a03ffbf7fff32 Fri 2020-12-11 19:04:30 IST—Fri 2020-12-11 19:31:01 IST
-9 2acf08368667423c89086579f98efd82 Tue 2020-12-15 17:36:52 IST—Tue 2020-12-15 19:13:10 IST
-8 b826f223a67d454b94d4413678870f08 Sat 2020-12-19 00:31:54 IST—Sat 2020-12-19 00:44:52 IST
-7 011e1b29339041b0ae48bbb93fce792f Wed 2020-12-23 23:01:15 IST—Wed 2020-12-23 23:02:44 IST
-6 f41f5880572e4394938c6dcb4a8b683c Mon 2020-12-28 16:54:11 IST—Mon 2020-12-28 22:54:22 IST
-5 a2e638dc292a4db2b0a50dd442129c28 Tue 2020-12-29 17:02:16 IST—Tue 2020-12-29 19:39:38 IST
-4 f6c738df872a48d48daee1962727cca5 Wed 2020-12-30 19:09:30 IST—Wed 2020-12-30 19:20:23 IST
-3 c876e60ea371460b94e247b40270b18f Thu 2020-12-31 14:36:07 IST—Thu 2020-12-31 15:45:36 IST
-2 a23c70804ec243f7868c18737f4b7e55 Sat 2021-02-13 20:09:30 IST—Sat 2021-02-13 20:10:44 IST
-1 94b604a6bf75462dac8c4a4576fdc863 Sat 2021-02-13 20:10:59 IST—Sat 2021-02-13 20:23:18 IST
0 3ff7e29fa0a34878b7574b7d4d3ccfb5 Sat 2021-02-13 20:24:57 IST—Sat 2021-02-13 21:13:15 IST
$
“`

正如您所看到的,它列出了最近的几次启动。要进一步分析特定的重启,请使用:

“`
$ journalctl -b {num} -n
“`

这里的{num}将是在journalctl --list-boots命令的第一列中给出的索引。

$ journalctl -b -1 -n
-- 日志开始于2020年11月18日星期三23:09:05 IST,结束于2021年2月13日星期六21:13:39 IST。 --
2月13日20:23:18 ubuntumate20vm systemd[1]: lvm2-monitor.service: 已成功停止。
2月13日20:23:18 ubuntumate20vm systemd[1]: 停止通过dmeventd或进程轮询监视LVM2镜像、快照等。
2月13日20:23:18 ubuntumate20vm systemd[1]: 达到目标Shutdown。
2月13日20:23:18 ubuntumate20vm systemd[1]: 达到目标Final Step。
2月13日20:23:18 ubuntumate20vm systemd[1]: systemd-poweroff.service: 已成功。
2月13日20:23:18 ubuntumate20vm systemd[1]: 已完成Power-Off。
2月13日20:23:18 ubuntumate20vm systemd[1]: 达到目标Power-Off。
2月13日20:23:18 ubuntumate20vm systemd[1]: 正在关闭。
2月13日20:23:18 ubuntumate20vm systemd-shutdown[1]: 同步文件系统和块设备。
2月13日20:23:18 ubuntumate20vm systemd-journald[304]: 日志记录已停止
$

您可以在上面的输出中观察到日志中记录的消息,并可以跟踪任何异常情况。

结论

使用单个命令或单个日志文件可能无法准确定位Linux重新启动的原因。因此,始终方便的是使用能够捕获系统相关事件的工具和日志,以缩短找到根本原因所需的时间。

上面的示例为您提供了一个开始解决问题的地方。使用这些工具和日志的组合,您可以确切地了解发生了什么以及系统如何重新启动。

接下来,了解一些轻量级的东西。

类似文章