我的一台 KVM 服务器（2 个 Xeon E5-2680 v2、1 个 AMD Vega 10 GPU、Ubuntu 20.04.1 LTS）昨晚变得没有响应。服务器上运行的 5 台虚拟机中，只有一台可以访问。服务器本身拒绝 SSH 连接，我什至无法通过 HDMI 获得屏幕。除了重置之外我没有看到任何其他解决方案。
完成此操作后，我想更好地了解到底发生了什么。系统上提供以下期刊：
# journalctl --list-boots
-8 57c5ae37af1649379e82b349abb14f9d Sun 2020-05-24 20:25:57 CEST—Sun 2020-05-24 20:44:30 CEST
-7 c617acfdd3854669bd114d1d033cd5a7 Sun 2020-05-24 20:45:01 CEST—Mon 2020-05-25 19:21:48 CEST
-6 745df76c9d784907862118c7804a19ab Mon 2020-05-25 19:22:26 CEST—Mon 2020-05-25 19:42:17 CEST
-5 9781df6fa3494c4588d0cf4a99678e84 Mon 2020-05-25 19:42:59 CEST—Thu 2020-06-04 04:53:20 CEST
-4 db93d994719a4ee1ad8eb74932220898 Thu 2020-06-04 18:45:10 CEST—Thu 2020-06-04 19:16:38 CEST
-3 c6007ce834bd4933805138523549677e Thu 2020-06-04 19:17:20 CEST—Thu 2020-08-20 18:35:54 CEST
-2 c24b967697ce41a2ac6c1707936dc450 Thu 2020-08-20 18:36:23 CEST—Mon 2020-08-31 17:21:52 CEST
-1 b1efda1e7a3b42d4ae9a20f0c3b06fcf Mon 2020-09-07 09:49:24 CEST—Mon 2020-09-07 09:59:49 CEST
0 f5de0a1534a7478e87847031156976d0 Mon 2020-09-07 10:00:19 CEST—Mon 2020-09-07 10:08:33 CEST
正如您可能已经从列表中看到的那样，过去 7 天的数据丢失了，我实际上无法访问导致系统错误的日志。
运行journalctl --verify显示以下输出。
1f23cc0: Invalid object
File corruption detected at /var/log/journal/f9decb319623482392299509c566049a/[email protected]~:1f23cc0 (of 33554432 bytes, 97%).
FAIL: /var/log/journal/f9decb319623482392299509c566049a/[email protected]~ (Bad message)
PASS: /var/log/journal/f9decb319623482392299509c566049a/system@24f780e4155245c0a176021b285d8b61-0000000000000001-0005a744de2ec87d.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/user-1000@6da18e6709a04eb8809cb4af946ec557-00000000000008e3-0005a66900b2a7be.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/system@24f780e4155245c0a176021b285d8b61-0000000000010c89-0005a8cfc4df2d27.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/user-1000@6da18e6709a04eb8809cb4af946ec557-0000000000010c88-0005a8cfc4dec165.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/system@24f780e4155245c0a176021b285d8b61-000000000001b654-0005ab341293df34.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/user-1000@6da18e6709a04eb8809cb4af946ec557-000000000001bf95-0005ab56000dcbe1.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/[email protected]~
PASS: /var/log/journal/f9decb319623482392299509c566049a/system@cf2a7210a86040e6aa7736d9b0a88e8b-0000000000000001-0005aeb4750dab5e.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/system.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/user-1000@6da18e6709a04eb8809cb4af946ec557-00000000000269b9-0005ad9c6a92da4a.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/user-1000.journal
浏览一些明显的网络搜索结果，似乎目前无法修复损坏的日记，它就这样消失了。坦率地说，当 systemd 负责人写道他认为不需要修复损坏的 journalctl 条目时，我觉得有点奇怪，但也许只有我这么认为。
我真的不知道还能做什么。在我的 中/var/log，我还调用了文件syslog，但它们也于 8 月 31 日停止并于今天继续。对于 也是如此kern。我查看了其他一些日志文件，例如 Xorg 和 dmesg。老实说，我什至不知道要寻找什么，但似乎没有什么能让我兴奋。
Xorg.log 仅显示一个错误，该错误似乎不太可能是我的问题的罪魁祸首：
[230912.637] (II) xfree86: Adding drm device (/dev/dri/card0)
[230912.637] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
dmesg 中似乎没有错误或失败消息。
我的意思是，目前一切正常，但这个错误似乎每隔几周就会重复一次。我还可以采取哪些其他步骤来更好地了解这个问题？
答案1
我不认为journalctl --list-boots显示所有日记文件， 只是启动事件。从手册:
--list-boots显示启动号（相对于当前启动）、其 ID 以及与启动相关的第一条和最后一条消息的时间戳的表格列表。
所以看起来没有靴子发生在 2020-08-31 17:21:52 和 2020-09-07 09:49:24 之间。如果您知道这是错误的，那么期刊中确实存在空白。
但是，我们可以检查自特定时间以来或之前发生的所有（其他）消息。当我写这篇文章时，这个特定事件发生在很久以前，但它会是这样的：
journalctl --since '2020-09-06' --until '2020-09-08
这将涵盖前一天午夜到后一天午夜之间的 48 小时。您可以-k仅针对内核消息进一步过滤它。
如果有日志，那么这将打印它们。如果它们确实丢失了，那么我们就知道期刊一定有问题。
Journalctl 应该跳过日志中损坏的消息，但仍然打印它可以打印的内容。我同意有关此问题的错误报告得到了非常轻率的答案，但是意图是应该跳过坏消息。从这个输出看来--verify，大部分日志文件都没有问题，但在接近尾声时发生了损坏（可能是不完整的消息写入，就在系统崩溃时）。