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」タイプのコマンドはありません。journaldは問題を検出するとすぐに新しい「クリーン」ファイルの書き込みに自動的に切り替わるので、理論的にはデータ損失は最小限に抑えられます。

ファイル修復コマンドがあるまで、破損したジャーナルファイルを見つけて削除することが唯一の解決策です。これについては、Fedoraメガスレッドで、ジャーナルのみのログをデフォルトに設定する方法をご覧ください。

テールの破損の場合、通常のjournalctlツールは、ファイルから回収できる限り多くの情報を提供します。最後の完全なログ行を出力して終了します。これはあなたが得ることができるものにかなり近いです。

中間の汚職では状況が異なります。このような破損からデータを回収するための優れたツールはありませんが、比較的簡単に作成できます。ただし、ジャーナルの「追加専用」モデルのため、これらは非常にまれであるため、これはTODOリストには含まれていません。

もちろん、最初に問題の原因を特定して報告できる場合、それは良いことです。

journalctl issuesというタイトルのArchLinux wikiのこのスレッドに関連しているようです。この設定を行うには何かを持っているようだSystemMaxUse中を/etc/systemd/journald.conf。

スレッドは決定的なものではありませんが、何人かの人々は、下のログをクリアするか/var/log/journal/*、の値を増やすことに成功していましたSystemMaxUse。