我有一个Debian 10服务器,它一直在重新启动。journalctl提供了列出最后一次引导的可能性:
journalctl --list-boots
-6 1ee519dc5bc24e88af75cc609ee32093 Mon 2023-02-06 21:02:02 UTC—Sun 2023-02-12 17:23:28 UTC
-5 bb25fc752ac1428abb87bab15a3cea8b Sun 2023-02-12 17:26:04 UTC—Sun 2023-02-12 17:34:59 UTC
-4 91245b74acdc4c7086ebc4a626d55dcc Sun 2023-02-12 17:37:39 UTC—Sun 2023-02-12 21:48:10 UTC
-3 e3978f5222164454be6ebcd12a1ea65b Sun 2023-02-12 21:50:48 UTC—Sun 2023-02-12 22:38:56 UTC
-2 b3bc3015a73a4661af9f2c277e9bc03d Sun 2023-02-12 22:42:02 UTC—Mon 2023-02-13 02:02:07 UTC
-1 57f4a16489904888acc285ed090afaa7 Mon 2023-02-13 02:04:40 UTC—Mon 2023-02-13 04:04:46 UTC
0 28efdbf5275f4320ad11f3075b66aa95 Mon 2023-02-13 04:07:21 UTC—Mon 2023-02-13 08:33:09 UTC但是,还不清楚系统是在哪里被用户重新启动的,内核崩溃了,或者电源被切断了。是否有任何工具可以提供这样的输出?
发布于 2023-02-13 08:58:22
请按以下顺序试一试。
last或journalctl --list-boots命令输出,并获取任何重新启动的日期和时间(搜索时保持日期时间格式不变)。/var/log/messages文件并搜索相同的日期时间。如果日志旋转,请检查旧日志。stopping服务语句,这意味着服务器通常由用户、计划或控制台重新启动(在云实例的情况下)。发布于 2023-02-15 15:46:30
我编写了一个简单工具( bash )来自动收集有关重新启动的附加信息。该脚本使用内部journalctl,因此它可以在任何使用Systemd的Linux发行版上工作。
这个想法很简单,对于每个会话,我们希望检查日志中的其他信息,检查已知条目:
SIGTERMSEGFAULTBUG确认坠机是很复杂的。这就是为什么某些行被标记为CRASH?的原因。这意味着这样的日志突然结束而没有被识别的错误消息。在某些情况下,SEGFAULT可能会被记录,有时不会。
这可能有助于操作符将注意力集中在具有可疑条目的引导会话上。
$ crashctl
Distribution : Debian GNU/Linux 10 (buster)
Kernel : 4.19.0-23-amd64 #1 SMP Debian 4.19.269-1 (2022-12-20)
Current boot : 606aaecb-b14d-4bbc-9598-b6c60233a888
Scaled load : 0.04 0.01 0.00
System installed : Tue Jan 3 09:26:13 UTC 2023
System started : Mon Feb 6 03:11:44 CET 2023
Uptime : up 7 days
Running processes : 384
kdump : current state : ready to kdump
Boot First message Last message Uptime Reboot/Crash
-------------------------------------------------------------------------------------
-11 2022-12-05 20:43:53 UTC 2022-12-05 20:52:00 UTC 0d 00:08:07 reboot (SIGTERM)
-10 2022-12-06 07:56:01 UTC 2022-12-06 15:14:36 UTC 0d 07:18:35 CRASH?
-9 2022-12-07 12:28:07 UTC 2022-12-10 16:33:43 UTC 3d 04:05:36 reboot (SIGTERM)
-8 2022-12-12 08:56:05 UTC 2022-12-18 08:18:40 UTC 5d 23:22:35 CRASH?
-7 2022-12-18 08:32:27 UTC 2022-12-25 10:54:03 UTC 7d 02:21:36 reboot (SIGTERM)
-6 2022-12-28 10:51:54 UTC 2022-12-29 12:12:32 UTC 1d 01:20:38 Power key pressed, but ignored
-5 2023-01-02 08:45:54 UTC 2023-01-06 08:05:01 UTC 3d 23:19:07 CRASH?
-4 2023-01-06 10:07:00 UTC 2023-01-12 10:01:25 UTC 5d 23:54:25 Power key pressed, but ignored
-3 2023-01-12 10:04:36 UTC 2023-01-28 14:07:19 UTC 16d 04:02:43 reboot (SIGTERM)
-2 2023-01-30 08:43:42 UTC 2023-01-31 07:27:26 UTC 0d 22:43:44 reboot (SIGTERM)
-1 2023-02-02 12:41:51 UTC 2023-02-04 13:16:19 UTC 2d 00:34:28 reboot (SIGTERM)
0 2023-02-06 03:12:01 UTC 2023-02-13 18:17:52 UTC 7d 15:05:51 runninghttps://serverfault.com/questions/1122800
复制相似问题