*.journal
Ubuntu 18.04ホストの1つが予想よりはるかに多い12 GBのファイルでキャプチャされました。保管する価値があるかどうかを調べるために、私は走りました。
journalctl --file $f
今日より古いすべてのファイルは常にFailed to open files
または--- No entries ---
。
そのようなファイルはゴミなので廃棄できると結論付けるのは正しいですか?
それでは、なぜ存在するのですか?これをクリーンアップするためにサポートされている方法は何ですか?システムの有無を定期的に確認することは価値がありますか?
答え1
まず、ジャーナルはロギングシステムであり、systemd
何が起こったのかを知る必要があるときにその存在が重要です。
言ったようにここ、journalctl --file
それは使えませんか?
ジャーナルファイルは定期的に置き換えられるため、このフォームはジャーナル全体を表示するために実際には使用できません。
これで、ファイルが役に立たないと思うかどうかは、ユーザーが決定します。通常、古すぎるログはアーカイブする価値がないため、削除できます。
そのためには、journalctl
それ自体とユーティリティ真空を使用するのが最善です。たとえば、次のように使用できます。
sudo journalctl --vacuum-time=3weeks
3週間を超えるすべてのジャーナルファイルを削除するには
詳細については、以下を確認してください。マニュアルページとman journalctl
。
--vacuum-size=, --vacuum-time=, --vacuum-files=
使用するディスク容量が指定されたサイズ(通常は「K」、「M」、「G」、および「T」サフィックスで指定)を下回るか、すべてのアーカイブジャーナルファイルに次の古いデータが含まれないまで古いアーカイブジャーナルファイルを削除します。指定された時間範囲(通常の「s」、「m」、「h」、「日」、「月」、「週」、および「年」のサフィックスとして指定))、または指定された数以下の個々のジャーナルファイルが残ります。 --vacuum-size=を実行すると、--disk-usageに示されている出力に間接的な影響しかありませんが、後者はアクティブジャーナルファイルを含みますが、真空ジョブはアーカイブジャーナルファイルでのみ機能します。 -files=はアクティブなジャーナルファイルを削除しないため、実際にはジャーナルファイルの数を指定された数未満に減らすことはできません。
また、これを定期的に確認することは価値がないと思います。では、次の項目のコメントを削除して変更して上限を設定します/etc/systemd/journald.conf
。
たとえば、
SystemMaxUse=4G
その後、サービスを再起動してくださいsudo systemctl restart systemd-journald
。
より多くの情報のために使用してくださいman journald.conf
。
編集する:
@reinierpostの説明どおり
この質問は、一般的な古いログに関するものではなく、ログがまったく含まれていないように見える古いログファイルについてです(ただし、各ログファイルは8MBを占めています)。
を実行してみてくださいjournalctl --verify
。ファイルが通過できない場合は、ジャーナルが破損しているため、サービスを再起動する必要があります。
sudo systemctl restart systemd-journald
これにより、今後のログに関する問題が解決します。
最初になぜこのようなことが起こったのかはわかりません。破損したファイルはおそらくジャンクです。これきれいなスレートのため。
答え2
同様のことが発生しました。 Ubuntu 22.04システムの1つには、/var/log/journal
3年前のファイルが81Gでした。journalctl --utc --no-pager | head
私のファイルは約6日前のものでした。journald.conf
別のVMの確認を始めました。同様の問題が見つかりました。
私は試した:
SystemMaxUse=10G
systemd-journaldの設定と再起動RuntimeMaxUse=10G
systemd-journaldの設定と再起動- SystemMaxFiles=30 に設定
SystemMaxFileSize=1G
し、systemd-journald を再起動します。 MaxFileSec=1month
systemd-journaldの設定と再起動
これらの設定のどれも以前のログファイルを削除しませんでした/var/log/journal
。私も次のことを試しました。
journalctl --flush --rotate
journalctl --rotate --vacuum-time=10days
既存のファイルはすべてそのまま残ります。
journalctl --disk-usage
ジャーナル処理された請求は496Mのみを使用します。
journalctl --verify
すべての確認は「通過」と表示されますが、確認のみが表示されます/var/log/journal
。他のすべてのディレクトリはジャーナリングによって孤児になったと仮定しますが、現在の日付まで維持されるため、これは継続的な問題です。
ログから削除しなければならなかったが削除していないジャンクを削除するためMaxFileSec=1month
に毎日のクローンジョブを設定し(デフォルトでなければならない)、追加して問題を解決しました。find /var/log/journal -mtime +45 -delete