☰

Journalctl - 報告書の損傷を確認する

tag-icon • tag-icon systemd systemd-journald
Journalctl - 報告書の損傷を確認する

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

答え1

現在、Journalctlは破損したジャーナルを検出できますが、回復を試みる「fsck」タイプコマンドはありません。問題が検出されると、ログは自動的に新しい「クリーン」ファイルへの書き込みに切り替わるため、理論的にはデータ損失を最小限に抑える必要があります。

ファイル回復コマンドが表示されるまで、破損したログファイルを見つけて削除することが唯一の回避策です。あなたは見つけることができますこれについてもっと詳しくFedoraハイパースレッドでは、ロギングのみがデフォルトに設定されます。

尾の破損の場合、一般的なJournalctlツールはファイルから回復できるできるだけ多くの情報を提供します。最後の完全なログ行を出力してから完了します。これはあなたが得ることができる限り近いです。

真ん中の不正状況は異なります。この種の損傷からデータを救出することができる良いツールはありませんが、比較的簡単に作成できます。ただし、ジャーナルの「追加専用」モデルによってTODOリストに表示される可能性はほとんどありません。

もちろん、問題の原因が何であるかをまず把握して報告していただきたいと思います。

答え2

これはArchLinux Wikiの次のスレッドに関連しているようです。ログ制御の問題。このSystemMaxUse設定に関連しているようです/etc/systemd/journald.conf。

このスレッドは結論付けられませんでしたが、一部の人々は/var/log/journal/*下のログを消去したり値を上げたりすることに成功しましたSystemMaxUse。

答え3

sudo journalctl --flush
sudo journalctl --verify

~から手動:

永続ストレージが有効な場合、ログデーモンはに保存されているすべてのログデータをフラッシュする必要があります/run/log/journal/。/var/log/journal/この呼び出しは、操作が完了するまで返されません。この呼び出しはすばらしいです。データはシステムランタイム中に/run/log/journal/一度だけ更新されます/var/log/journal/（ただし、以下の --relinquish-var を参照）、既に発生した場合、このコマンドは何も実行せずに完全に終了します。このコマンドは、/var/log/journal/返却時にすべてのデータが更新されることを効果的に保証します。

バージョン217で追加されました。

関連サービスがありますsystemd-journal-flush.service。

関連情報