journalctl --verify报告损坏

我只是注意到此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

当前，journalctl可以检测到损坏的日志，但是没有“ fsck”类型的命令来尝试修复。一旦发现问题，日志将自动切换到写入新的“干净”文件，因此从理论上讲，数据丢失应该最小化。

除非有文件修复命令，否则找到损坏的日志文件并将其删除是唯一的解决方法。您可以在我们的Fedora巨线程中找到更多有关此的信息，而不是将仅日志记录作为默认记录：

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

中间的腐败情况有所不同。我们没有很好的工具来挽救此类损坏的数据，但可以相对轻松地编写它们。但是，由于由于期刊的“仅追加”模式，它们极不可能出现，因此它不在我们的TODO列表中。

当然，如果您可以识别出最初导致问题的原因并进行报告，那就太好了。

它似乎与ArchLinux Wiki上题为：journalctl issues的该线程有关。似乎与中的此设置SystemMaxUse有关/etc/systemd/journald.conf。

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