journalctl --verify 报告损坏

Question

我刚刚注意到这个verify选项journalctl并决定试一试，它显示损坏，可能是什么原因造成的？如果我应该做些什么呢？我应该进一步调查吗？

journalctl --verify
PASS: /var/log/journal/19184893a1d645c7a43729e79b10a876/user-1000.journal
Invalid object contents at 3733856??????????????????????????????   0%
File corruption detected at /var/log/journal/19184893a1d645c7a43729e79b10a876/system.journal:3733856 (of 91734016, 4%).
FAIL: /var/log/journal/19184893a1d645c7a43729e79b10a876/system.journal (Bad message)
Invalid object contents at 21575496?????????????????????????????  45%
File corruption detected at /var/log/journal/19184893a1d645c7a43729e79b10a876/system@60e058db556e4de4b256d0b1ff176aa4-0000000000000001-0004e0b436d20aa1.journal:21575496 (of 44052480, 48%).
FAIL: /var/log/journal/19184893a1d645c7a43729e79b10a876/system@60e058db556e4de4b256d0b1ff176aa4-0000000000000001-0004e0b436d20aa1.journal (Bad message)
PASS: /var/log/journal/19184893a1d645c7a43729e79b10a876/user-1000@60e058db556e4de4b256d0b1ff176aa4-0000000000000a91-0004e0b4ff9a949a.journal
PASS: /var/log/journal/19184893a1d645c7a43729e79b10a876/user-1001.journal

Answer 1

目前，journalctl 可以检测损坏的日志，但没有“fsck”类型的命令来尝试修复。journald 会在检测到问题后立即自动切换到写入新的“干净”文件，因此理论上数据丢失应该是最小的。

在有文件修复命令之前，找到损坏的日志文件并将其删除是唯一的解决方法。您可以在我们的 Fedora 超级线程中找到更多关于将仅日志记录设置为默认值的信息：

对于尾部损坏，您的常规 journalctl 工具将为您提供尽可能多的信息以从文件中挽救。它将输出最后一个完整的日志行，然后完成。这非常接近您可以获得的好程度。

中间的腐败则不同。我们没有从这种损坏中挽救数据的好工具，但它们可以相对容易地编写。但是，由于期刊的“仅附加”模型，它们极不可能出现，因此它们不在我们的 TODO 列表中。

当然，如果您能确定最初导致问题的原因并报告它，那就太好了。

Answer 2

它似乎与 ArchLinux wiki 上的这个帖子相关，标题为：journalctl issues。SystemMaxUse看来和这个设定也有关系/etc/systemd/journald.conf。

该线程不是结论性的，但有几个人在清除下面的日志/var/log/journal/*或增加 的值方面有一些运气SystemMaxUse。