it-swarm.cn

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

例如。我在/var/log/messages

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

有没有办法找出造成关机的原因?例如。是从控制台运行,还是有人按下电源按钮等?

123
alex

只有root特权程序才能正常关闭系统。因此,当系统以正常方式关闭时,它要么是具有root特权的用户,要么是acpi脚本。在这两种情况下,您都可以通过检查日志来查找。按下电源按钮,过热或电池电量不足(笔记本电脑)可能会导致acpi关闭。我忘记了第三个原因,当电源出现故障时,UPS软件仍然会发送警报。

最近,我有一个系统,反复启动后会不正常地关闭电源,结果发现该设备过热并且主板配置为尽早关闭电源。该系统没有保存日志的机会,但幸运的是,监视系统的温度表明它刚在关闭电源之前就开始升高。

因此,如果是正常关机,则它将被记录下来;如果是入侵……祝您好运;如果是冷关机,则您最好的机会是控制和监视其环境。

50
forcefsck

尝试以下命令:

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

显示最近关闭的条目的列表:last -x | less

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

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

我在网上找到了该资源。这可能对您有用:

如何找出谁或什么使我的系统停止

127
Nicolas de Fontenay

您必须检查两件事:

  1. last -x命令的输出
  2. / var/log /中的日志文件

使用这两个命令并继续阅读以获取更多信息。

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)关于last -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 -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'

当意外关闭电源或发生硬件故障时,文件系统将无法正确卸载,因此在下次启动时,您可能会收到以下日志:

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来反转顺序,这样我们就不会为最近事件到最近事件的打印感到困惑。

26
ndemou

一些可能的日志文件可供探索:(找到了Ubuntu系统,但我希望它们在大多数Linux/Unix系统中都存在)

/var/log/debug
/var/log/syslog (will be pretty full and may be harder to browse)
/var/log/user.log
/var/log/kern.log
/var/log/boot

同样,这些日志文件位于Ubuntu系统上,因此文件名可能不同。 tail命令是您的朋友。

11
user6148

使用last进行简化,以显示系统关闭条目,运行级别更改以及对shutdownreboot的过滤:

last -x shutdown reboot
8
jhvaras

不完全令人满意

我在Debian 7.8上也有类似的需求,并观察到日志中基本上没有明确的消息,这有点令人惊讶。

Grep通过/var/log可以告诉您计算机已关闭的时间,显示适当的守护程序已关闭等信息,但不是最初的原因。

shutdown[25861]: shutting down for system halt

提到的其他解决方案(last -x)并没有太大帮助。

看看它是如何工作的

阅读/etc/acpi/powerbtn-acpi-support.sh,其中包括:

 if [-x /etc/acpi/powerbtn.sh];然后
#与acpid软件包中的旧配置脚本兼容
 /etc/acpi/powerbtn.sh
Elif [-x /etc/acpi/powerbtn.sh.dpkg-bak] ;然后
#与acpid软件包
中的旧配置脚本兼容。#仍然存在,因为它已由admin 
 /etc/acpi/powerbtn.sh.dpkg-bak 
 else 
#正常处理。
/sbin/shutdown -h -P现在“按下电源按钮” 
 fi 

注意,显式文本是shutdown命令的参数。我希望该字符串由关机程序自动记录。

调整以获得更好的日志

无论如何,要获得明确的消息,我将文本(作为根)放在新创建的/etc/acpi/powerbtn.sh中,并使其可以通过chmod a+x /etc/acpi/powerbtn.sh执行

#!/ bin/sh 
记录在/etc/acpi/powerbtn.sh中,大概是“按下了电源按钮” 
/sbin/shutdown -h -P现在是“电源按钮”按下“ 

与修改/etc/acpi/powerbtn-acpi-support.sh相比,以这种方式进行的更改可能会更持久。后一种选择可能会在软件包acpi-support-base的下一次升级中失去作用。

请注意,与Ubuntu 14.04相比,它的操作有所不同(/etc/acpi/powerbtn.sh已经存在,但其内容与acpid包不同)。同样,Debian 8可能会有所不同。随时提供变体。

利润!

现在,当按下电源按钮时,/var/log/messages/var/log/syslog/var/log/user.log中将出现以下一行:

logger: in /etc/acpi/powerbtn.sh, presumably Power button pressed

现在,这是日志中的显式消息。

8
Stéphane Gourichon

我的想法很笨拙,但也许对您有用:输入命令last并查看所有用户的登录信息。然后,使用当时已登录的halt所需的权限过滤用户。然后看看他们的.bash_history文件,以查看他们是否已进入暂停状态。

4
sazary

就我而言,我有一个过热的问题,在/ var/log/syslog中通过/ var/log文件夹中的'grep shut *'找到了日志。

记录的错误是这样的:

Feb 23 15:59:49 luca-LIFEBOOK-A530 kernel: [24746.497174] thermal thermal_zone0: critical temperature reached(99 C),shutting down
1
luandrea

只是在我的KVMVM(我想知道主机重新启动是否彻底关闭来宾系统)上)中找到了筹码,我在/var/log/auth.log (此外 last -x shutdown表示相同)。这些行出现了:

Sep  3 23:56:31 Web systemd-logind[531]: Power key pressed.
Sep  3 23:56:31 Web systemd-logind[531]: Powering Off...
Sep  3 23:56:31 Web systemd-logind[531]: System is powering down.
Sep  3 23:55:45 Web systemd-logind[591]: New seat seat0.
Sep  3 23:55:45 Web systemd-logind[591]: Watching system buttons on /dev/input/event0 (Power Button)
Sep  3 23:55:54 Web sshd[805]: Server listening on 0.0.0.0 port 22.
Sep  3 23:55:54 Web sshd[805]: Server listening on :: port 22.

last -x显示这些行,请注意,它们以most-recent-first的顺序打印(即先读取最后一行,然后上升),但是由于时钟重置(23:在启动前56(之后23:55)在上一行中也很明显,该顺序似乎有些令人困惑:

runlevel (to lvl 2)   3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
reboot   system boot  3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
shutdown system down  3.13.0-123-gener Sun Sep  3 23:56 - 23:55  (00:00)    
runlevel (to lvl 0)   3.13.0-123-gener Sun Sep  3 23:56 - 23:56  (00:00)

就我而言,检查在引导主机时来宾是否干净地关闭,我也可以仅登录(ssh)其中一个来宾,并在引导主机时停留在那儿,在终端中获取以下行:

[email protected]:~#
Broadcast message from [email protected]
        (unknown) at 22:25 ...

The system is going down for power off NOW!
Connection to web closed by remote Host.
Connection to web closed.
1
stolsvik

将关机别名为脚本
脚本必须将所有参数等赋予原始的关闭可执行文件
但是:脚本必须记录这些

0
LanceBaynes