☰

我的 Linux 主机是否重新启动？

tag-icon • tag-icon reboot alma-linux uptime
我的 Linux 主机是否重新启动？

我运行的是AlmaLinux 9，它已经稳定运行了一段时间。今天早上，我收到电子邮件，称 systemd 服务已在一夜之间自行重新启动。奇怪的是，由于该服务没有设置为自动重启，只是随系统启动。主机装有 UPS，因此不应该出现任何奇怪的电源问题。我检查了启动日志，“last”命令显示：

reboot   system boot  5.14.0-284.25.1. Mon Nov 20 02:15   still running
reboot   system boot  5.14.0-284.25.1. Sun Oct 29 15:24   still running
reboot   system boot  5.14.0-284.25.1. Thu Oct 26 10:57 - 11:07 (2+00:09)
reboot   system boot  5.14.0-284.25.1. Wed Oct 25 17:13 - 17:16  (00:03)
reboot   system boot  5.14.0-284.25.1. Fri Oct 20 11:56 - 17:10 (5+05:13)
reboot   system boot  5.14.0-284.25.1. Wed Oct 18 20:25 - 11:51  (15:26)
reboot   system boot  5.14.0-284.25.1. Tue Oct 17 04:52 - 11:51 (2+06:59)
reboot   system boot  5.14.0-284.25.1. Fri Sep 29 15:45 - 11:51 (19+20:06)
reboot   system boot  5.14.0-284.25.1. Sat Sep 23 09:09 - 14:56 (6+05:46)
reboot   system boot  5.14.0-284.25.1. Tue Sep 19 20:14 - 09:09 (3+12:55)
reboot   system boot  5.14.0-284.25.1. Tue Sep 19 19:21 - 19:57  (00:35)
reboot   system boot  5.14.0-284.25.1. Sun Sep 10 20:23 - 18:01 (8+21:37)
reboot   system boot  5.14.0-284.25.1. Sun Sep 10 16:18 - 20:23  (04:04)
reboot   system boot  5.14.0-284.25.1. Fri Sep  8 20:53 - 19:56  (23:03)
reboot   system boot  5.14.0-284.25.1. Fri Sep  8 20:43 - 20:52  (00:08)
reboot   system boot  5.14.0-284.25.1. Fri Sep  8 20:27 - 20:43  (00:15)
reboot   system boot  5.14.0-284.25.1. Fri Sep  8 19:10 - 20:26  (01:16)
reboot   system boot  5.14.0-284.25.1. Fri Sep  8 16:25 - 18:52  (02:26)
reboot   system boot  5.14.0-284.11.1. Fri Sep  8 19:50 - 16:24  (-3:25)

这没有道理……最上面的两行怎么可能都“仍在运行”？或者我误解了这意味着什么？

我检查了正常运行时间--pretty，上面写着：

up 8 hours, 49 minutes

然而我的 /var/log/messages 文件没有显示大约 9 小时前的任何系统重启相关消息......只是常规日志记录。

到底是怎么回事？ Uptime 表示我的主机今天早上重新启动，“最后”表示 10 月 29 日启动仍在运行（但 11 月 20 日/今天启动也是如此），系统日志显示过去 24 小时内没有重新启动的迹象。这没有意义

答案1

您还检查过以前的版本吗/var/log/messages？

周一早上 04:00 左右是运行每周自动日志轮换的典型时间。如果您的系统上发生这种情况，则重新启动消息可能已经被轮换为/var/log/messages.1[.gz]AlmaLinux 日志轮换使用的任何命名方案。

如果重新启动的日志真的消失了，那么我会担心可能的黑客/恶意软件攻击。重新启动并删除日志（可能是不熟练/不完整）后可能表明您的系统已安装 rootkit，以隐藏入侵者运行的进程并确保入侵者能够重新获得对系统的访问权限，即使允许入侵者进入的原始漏洞已修复。

如果 UPS 电池不是很新，我还建议对它进行压力测试，方法是断开实际计算机与 UPS 的连接，并让 UPS 为一些功率大致相当的“无害”负载供电，例如台灯或风扇，然后查看断开墙上输入电源后 UPS 实际可以供电多长时间。

如果您的 UPS 电池快没电了，系统可能突然断电，然后重新启动并在启动过程中再次断电，如果第二次断电发生在完全错误的时刻。

（我的UPS最近开始通知我它的电池需要更换。我拖延了......然后出现了一次非常短暂的停电，几秒钟后UPS就失败了，因为电池确实完全没电了。我现在知道了我的课程，并且还安装了新电池。）

答案2

要回答您问题的标题，您可以尝试以下操作：

  1. date -d@$(cat /proc/uptime | cut -f 1 -d " ") -u +%H:%M:%S

这只是将输出转换为/proc/uptime更好的输出（并删除“空闲时间”）的一种奇特方式。

  1. ps -p 1 -o lstart=

这不会显示系统何时启动，而是显示系统何时init启动。如果您不在容器中，这相当于系统上次重新启动时的时间。您还可以运行date --date="$(cat /proc/uptime | cut -f 1 -d " ") seconds ago"来查看这些选项是否匹配。

  1. dmesg -H | head -n 1

这应该显示dmesg开始写入日志的时间。这是一个二进制日志，因此它比文本文件更可靠，但并非绝对可靠。

相关内容