☰

如何从日志中找出导致系统关闭的原因？

tag-icon • tag-icon logs shutdown
如何从日志中找出导致系统关闭的原因？

例如，我在以下位置看到了这个/var/log/messages：

Mar 01 23:12:34 hostname shutdown: shutting down for system halt

有没有办法找出导致关闭的原因？例如，它是从控制台运行的，还是有人按下了电源按钮等？

答案1

尝试以下命令：

显示上次重新启动条目的列表： last reboot | less

显示上次关闭条目的列表： last -x | less

或者更准确地说： last -x | grep shutdown | less

但你不会知道是谁干的。如果您想知道是谁干的，您将需要添加一些代码，这意味着您下次就会知道。

我在网上找到了这个资源。它可能对你有用：

如何找出是谁或什么东西停止了我的系统

答案2

总长DR

使用这两个命令并继续阅读以获取更多信息。 
last -x | head | tac

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'

1）关于最后一个-x命令的输出

运行此命令* 并将输出与以下示例进行比较：

last -x | head | tac

正常关机示例

正常的关机和开机如下所示（请注意，您有一个关机事件，然后是一个系统启动事件）：

runlevel (to lvl 0)   2.6.32- Sat Mar 17 08:48 - 08:51  (00:02) 
shutdown system down  ... <-- first the system shuts down   
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 3)

在某些情况下，您可能会看到这一点（请注意，没有关于关闭的行，但系统处于运行级别 0，即“暂停状态”）：

runlevel (to lvl 0)   ... <-- first the system shuts down (init level 0)
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 2)   2.6.24-... Fri Aug 10 15:58 - 15:32 (2+23:34)

意外关闭示例

因断电而导致的意外关闭如下所示（请注意，您有一个系统启动事件，但之前没有发生系统关闭事件）：

runlevel (to lvl 3)   ... <-- the system was running since this momemnt
reboot   system boot  ... <-- then we've a boot WITHOUT a prior shutdown
runlevel (to lvl 3)   3.10.0-693.21.1. Sun Jun 17 15:40 - 09:51  (18:11)

2）关于/var/log/中的日志

用于过滤最有趣的日志消息的 bash 命令如下：

grep -iva ': 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'

当意外断电或发生硬件故障时，文件系统将无法正确卸载，因此在下次启动时您可能会收到如下日志：

EXT4-fs ... INFO: recovery required ... 
Starting XFS recovery filesystem ...
systemd-fsck: ... recovering journal
systemd-journald: File /var/log/journal/.../system.journal corrupted or uncleanly shut down, renaming and replacing.

当系统因用户按下电源按钮而关闭时，您会收到如下日志：

systemd-logind: Power key pressed.
systemd-logind: Powering Off...
systemd-logind: System is powering down.

只有当系统正常关闭时，您才会收到如下日志：

rsyslogd: ... exiting on signal 15

当系统因过热而关闭时，您会收到如下日志：

critical temperature reached...,shutting down

如果您有 UPS 并运行守护程序来监控电源和关机，您显然应该检查其日志（NUT 日志记录在 /var/log/messages 上，但 apcupsd 日志记录在 /var/log/apcupsd* 上）

笔记

last*：这是其手册页的描述：

last [...] prints information about connect times of users. 
Records are printed from most recent to least recent.  
[...]
The special users reboot and shutdown log in when the system reboots
or (surprise) shuts down.

我们用来head保留最新的 10 个事件，并用来tac反转顺序，这样我们就不会因为最后打印的事件从最近到最近的事件而感到困惑。

答案3

只有 root 特权程序才能正常关闭系统。因此，当系统以正常方式关闭时，要么是具有 root 权限的用户，要么是 acpi 脚本。在这两种情况下，您都可以通过检查日志来找出答案。 acpi 关闭可能是由于按下电源按钮、过热或电池电量不足（笔记本电脑）引起的。我忘记了第三个原因，UPS软件当电源出现故障时，无论如何都会发出警报。

最近，我有一个系统反复启动，不正常地关闭电源，结果发现它过热，并且主板被配置为提前关闭电源。系统没有机会保存日志，但幸运的是，监控系统温度显示，在关闭电源之前温度开始升高。

因此，如果是正常关闭，则会被记录下来，如果是入侵......祝你好运，如果是冷关闭，您最好的了解机会是控制和监视其环境。

答案4

last使用显示系统关闭条目和运行级别更改以及过滤 和shutdown来简化reboot：

last -x shutdown reboot

相关内容