☰

我如何追踪随机重启的原因？

tag-icon • tag-icon reboot log
我如何追踪随机重启的原因？

运行 Precise 64 位的 Thinkpad X220（Core-i5、SandyBridge、Intel GMA）在过去四天内硬重启了两次。我当时只是在写一封电子邮件。没有任何警告。它只是黑了，然后我看到的是联想启动屏幕。

我应该去哪里查找原因？我担心立即重启会没有时间写入日志...

谢谢！

答案1

检查/proc/sys/kernel/panic；如果其值为 1，则服务器将在崩溃时立即重新启动。有问题的驱动程序可能会导致内核崩溃。

如果这不是重新启动时出现的恐慌检查问题，那么问题可能是过热。

last reboot

答案2

命令

  1. dmesg- 可能无法显示上次启动之前的项目，但如果系统仍在运行，则非常有用

文件

  1. /var/log/syslog- 系统范围的记录器，使用tail /var/log/syslog或less /var/log/syslog
  2. /var/log/kern.log- 内核日志，同上
  3. /var/log/*

答案3

总结：@insider 的回答以及 @Antonios Hadjigeorgalis 的评论让我发现

Unattended-Upgrade::Automatic-Reboot "true"

在

/etc/apt/apt.conf.d/99custom-unattended-upgrades

我遇到了突然重启的情况，通常是在早上打开笔记本电脑后不久。我正在运行 Ubuntu 18.04。运行last reboot显示突然重启后内核版本通常较新：

reboot   system boot  4.15.0-112-gener Wed Jul 22 10:07   still running
reboot   system boot  4.15.0-111-gener Wed Jul 22 10:01 - 10:06  (00:04)
...
reboot   system boot  4.15.0-111-gener Wed Jul 15 09:49 - 23:43  (13:53)
reboot   system boot  4.15.0-109-gener Wed Jul 15 09:45 - 09:48  (00:03)
...
reboot   system boot  4.15.0-109-gener Fri Jul  3 09:14 - 17:37  (08:23)
reboot   system boot  4.15.0-108-gener Fri Jul  3 09:08 - 09:13  (00:05)

查看/etc/apt/apt.conf.d/50unattended-upgrades，我发现已"Unattended-Upgrade::Automatic-Reboot"被注释掉，其默认值应为 false。然后我运行了以下命令：

grep Reboot /etc/apt/apt.conf.d/*
/etc/apt/apt.conf.d/50unattended-upgrades:Unattended-Upgrade::Automatic-Reboot "false";
/etc/apt/apt.conf.d/50unattended-upgrades://Unattended-Upgrade::Automatic-Reboot-Time "02:00";
/etc/apt/apt.conf.d/99custom-unattended-upgrades:// Reboot automatically if necessary (e.g. on kernel upgrade), should be
/etc/apt/apt.conf.d/99custom-unattended-upgrades:Unattended-Upgrade::Automatic-Reboot "true";

这就是我的问题Unattended-Upgrade::Automatic-Reboot "true";所在/etc/apt/apt.conf.d/99custom-unattended-upgrades。

答案4

应用程序崩溃时有崩溃文件/var/crash/；我还会探索正常的系统日志，这是最好的选择。如果硬件关闭，您将不会在 systemd 和消息日志中看到任何内容（一个巨大的线索！！)。如果 Ubuntu 知道关机，您也会看到这一点，因为您会看到关机的原因。（如果未找到任何详细信息，则需要检查机器日志；即如果是虚拟机则检查主机操作系统，如果是金属则检查硬件日志）

查看此框中的应用程序崩溃

guiverc@d960-ubu2:/de2900/ubuntu_64$   ls -la /var/crash
total 113484
drwxrwsrwt  2 root    whoopsie      4096 Feb 27 12:00 .
drwxr-xr-x 16 root    root          4096 Nov 29  2018 ..
-rw-------  1 root    whoopsie   1214905 Feb 26 08:28 irssi-scripts.0.crash
-rw-------  1 root    whoopsie   1193193 Feb 25 15:04 lvm2.0.crash
-rw-r-----  1 guiverc whoopsie 101162337 Feb 19 13:00 _usr_bin_clementine.1000.crash
-rw-r-----  1 guiverc whoopsie   5962296 Feb 26 23:31 _usr_bin_gnome-control-center.1000.crash
-rw-r-----  1 guiverc whoopsie   1519149 Feb 20 08:28 _usr_bin_light-locker.1000.crash
-rw-r-----  1 guiverc whoopsie   1327084 Feb 27 12:00 _usr_bin_totem-video-thumbnailer.1000.crash
-rw-r-----  1 guiverc whoopsie     96196 Feb 22 13:55 _usr_games_sgt-launcher.1000.crash
-rw-r-----  1 guiverc whoopsie   3685288 Feb 22 00:34 _usr_lib_ibus_ibus-ui-gtk3.1000.crash

从应用程序崩溃开始很容易，所以我会首先查看那里，但我真的想不出为什么应用程序崩溃会导致重新启动或关机；所以我不希望在那里看到任何有意义的东西（如果它有用；它会在系统日志之后）。

要查看系统消息（针对当前会话），您可以使用dmesg。因为它只显示当前会话，所以您看不到上次关机的原因（即上次会话），但在非正常关机后，我希望看到结果fsck（由于计划外关机）。

然而，最好的线索是在 systemd 日志或 中journalctl。这是我真正寻找上次关机线索的地方，即我希望在这里看到缺少正常关机消息，这意味着它是硬件关机的线索（例如，由于极端高温阈值，CPU 关闭；引脚接地，操作系统没有线索，因此消息就停止了！下一条消息是下一个会话的正常启动；假设是企业服务器，此类消息将在硬件日志中找到；消费级通常不保留硬件日志）。

有时您可以在日志中看到过热的线索；如果 PSU 出现问题（PWR_GOOD 下降），那就糟糕了，因为 CPU 甚至没有意识到关机，所以什么也找不到；我怀疑硬件日志也可能会错过这种类型的关机（但缺少条目仍然是一个线索！）

要进一步缩小查看范围，将取决于服务器的类型、服务器上运行的内容以及尚未提供的详细信息。

相关内容