Answers:
只有root特权程序才能正常关闭系统。因此，当系统以正常方式关闭时，它要么是具有root特权的用户，要么是acpi脚本。在这两种情况下，您都可以通过检查日志来查找。按下电源按钮，过热或电池电量不足（笔记本电脑）可能会导致acpi关闭。我忘记了第三个原因，当电源出现故障时，UPS软件仍然会发送警报。
最近，我有一个系统，反复启动后会不正常地关闭电源，结果发现该设备过热并且主板配置为尽早关闭电源。该系统没有保存日志的机会，但是幸运的是，监视系统的温度表明它在关闭电源之前就开始升高。
因此，如果是正常关机，则它将被记录下来；如果是入侵……祝您好运；如果是冷关机，则您最好的机会是控制和监视其环境。
尝试以下命令：
显示最近的重启条目列表：
last reboot | less
显示最近关闭的条目列表：
last -x | less
或更确切地说：
last -x | grep shutdown | less
但是，您不知道是谁做的。如果您想知道是谁做的，则需要添加一些代码，这意味着您下次会知道。
我在网上找到了该资源。这可能对您有用：
last -x shutdown
有几件事要检查：
运行此命令*，然后将输出与以下示例进行比较：
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)
一个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用来颠倒顺序，这样我们就不会为最近事件到最近事件的最后打印感到困惑。
tac命令就可以重做
一些可能的日志文件可供探索：（找到了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命令是您的朋友。
简化使用last上显示该系统关闭记录和运行水平的变化和滤波shutdown和reboot：
last -x shutdown reboot
cat foo | grep barvs grep bar foo似乎可以自我过滤。
我在Debian 7.8上也有类似的需求，并观察到日志中基本上没有明确的消息，这有点令人惊讶。
Grep through /var/log会告诉您机器关闭的时间，显示适当的守护程序关闭等，但不是最初的原因。
shutdown[25861]: shutting down for system halt
（last -x）中提到的其他解决方案没有太大帮助。
阅读/etc/acpi/powerbtn-acpi-support.sh内容包括：
如果[-x /etc/acpi/powerbtn.sh]; 然后
＃与acpid包中的旧配置脚本兼容
/etc/acpi/powerbtn.sh
elif [-x /etc/acpi/powerbtn.sh.dpkg-bak]；然后
＃与acpid包中的旧配置脚本兼容
＃仍然存在，因为它已由管理员更改
/etc/acpi/powerbtn.sh.dpkg-bak
其他
＃正常处理。
/ sbin / shutdown -h -P现在“按下电源按钮”
科幻
注意，显式文本作为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
现在，这是日志中的显式消息。
acpi-support-base和安装acpid软件包。我还没有测试过自己。您能否详细说明它可以带来哪些收益和版本？
只是在我的KVM VM上安装了芯片（我想知道主机重启是否彻底关闭了guest虚拟机），我找到了所需的东西/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显示了这些行，请注意，它们是按照最新的顺序打印的（即先阅读最后一行，然后上移），但是由于时钟重置（引导之前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）其中一个来宾，并在启动主机时停留在那儿，在终端中获取以下行：
root@Web:~#
Broadcast message from root@Web
(unknown) at 22:25 ...
The system is going down for power off NOW!
Connection to web closed by remote host.
Connection to web closed.
cat /usr/adm/syslog
就我而言，是ups软件关闭了服务器。
/etc/rc.d/7/upsd.boot
/var/log/acpid：原来电源按钮被按下了。还有其他想法，如果acpid不提供提示，应该去哪里看？