テクノロジー · 実用ガイド
journalctl の vacuum が 0B？アクティブなジャーナルをローテートし、容量の下限を理解する
アクティブなジャーナルとアーカイブ済みファイルを区別し、永続ストレージか揮発性ストレージかに応じた上限を選び、使用量が指定した目標を上回る理由を確認します。
journalctl の vacuum が正常に実行されても、解放される容量が 0B だったり、ディスク使用量が指定したサイズを上回ったりすることがあります。それだけで故障とは限りません。表示される使用量にはアクティブなジャーナルとアーカイブ済みファイルの両方が含まれますが、vacuum が削除するのはアーカイブ済みファイルだけです。その時点までに書き込まれたデータを一度のクリーンアップに含めるには、先にローテートします。
一度だけ行う vacuum と、今後の保存容量の上限は別のものです。/var/log/journal 配下の永続ジャーナルには System の設定を、/run/log/journal 配下の揮発性ジャーナルには Runtime の設定を使います。上限を正しく設定した後も、アクティブなジャーナルが一つ残ることと、ファイルサイズによる処理単位の粗さによって、合計使用量が名目上の値を超えることがあります。
1. 削除する前に基準となる状態を記録する
sudo journalctl --disk-usage を実行して出力を記録します。続いて sudo du -sh /var/log/journal /run/log/journal 2>/dev/null と sudo journalctl --list-boots の出力を確認します。最初のコマンドはジャーナル側から見た使用量を示し、ディレクトリの確認では対象の保存先が永続、揮発性、またはその両方かを判断できます。ディストリビューション名だけで保存方式を推測しないでください。
クリーンアップの前に、インシデント調査、監査、サポート対応に必要なログを保存してください。この手順が管理するのはローカルのジャーナルストレージです。journal-remote の保存期間、エクスポートしたアーカイブ、使用中のジャーナルのディレクトリ階層外へコピーしたファイルは対象に含みません。
2. 設定を変える前に 0B の理由を確認する
上流のマニュアルによれば、--disk-usage にはアクティブなファイルとアーカイブ済みファイルの両方が含まれますが、vacuum が処理するのはアーカイブ済みファイルです。保存先にアクティブなファイルしかなければ、小さい目標を指定しても解放される容量が 0B になることがあります。Server Fault の事例はまさにこのパターンで、その後アーカイブ済みファイルができて初めて容量が解放されています。
--vacuum-size=0 を一括削除の近道として使わないでください。現在の systemd のドキュメントでは、0 はその条件による制限を設けないことを意味します。システムの診断に十分な履歴が残る、0 以外の目標値を選んでください。
3. 範囲を定めて一度だけクリーンアップする
その時点までに書き込まれたデータを含めるには、sudo journalctl --rotate --vacuum-size=500M を実行します。500M は、検討した目標値に置き換えてください。この二つのオプションを組み合わせると、まずアクティブなファイルをローテートし、その後アーカイブ済みファイルを vacuum で処理します。journald が使用している間は、.journal ファイルを手動で削除しないでください。
もう一度 sudo journalctl --disk-usage を実行し、解放したバイト数のメッセージと新しい合計使用量の両方を記録します。使用量が残っているだけで失敗とは限りません。新たにアクティブになったファイルは残り、別の名前空間や保存先の使用量が加わっている場合もあります。
4. 長期的な上限を保存方式に合わせて選ぶ
/var/log/journal 配下の永続ストレージには、ローカルの journald.conf の drop-in 設定ファイルで SystemMaxUse を設定し、削除の単位を細かくする必要があれば SystemMaxFileSize も設定します。/run/log/journal 配下の揮発性ストレージには、代わりに RuntimeMaxUse と RuntimeMaxFileSize を使います。SystemKeepFree と RuntimeKeepFree は空き容量を確保する設定で、journald は適用される上限のうち小さい方を使います。
Red Hat は永続ジャーナルの有効化を別の手順として説明し、/var/log/journal が存在してファイルを含むことを確認しています。Storage=auto が有効なシステムでは、このディレクトリの存在が重要です。特定のシステムロール向けの例をそのままコピーするのではなく、使用しているディストリビューションの設定方法と検証ツールに従ってください。
5. 設定を適用して検証する
ローカルの drop-in を追加したら、ディストリビューションで利用できるツールで実際に有効な設定を確認し、サポートされている手順に従って systemd-journald を再読み込みするか再起動して、想定した保存先ディレクトリを確認します。その後、通常のログを発生させ、必要に応じてローテートを待ち、ディスク使用量を再確認してください。構文が正しい設定ファイルでも、対象とする保存方式を間違えていることがあります。
クリーンアップ直後だけでなく、定常状態を検証してください。アクティブなファイルのサイズ、アーカイブ済みファイルの合計、設定した MaxUse と MaxFileSize、空き容量を記録します。これにより、実際に使用量が増え続ける問題と、ドキュメントに記載されたアクティブファイルによる下限や、ファイルサイズによる処理単位の粗さとを区別できます。
6. この結果で何を確認できたかを理解する
ローテートと vacuum の結果が示すのは、対象となるローカルのアーカイブ済みジャーナルファイルが、選択した条件に基づく検討対象になったということだけです。すべてのアプリケーションログが journald に保存されていること、リモートのアーカイブが削除されたこと、今後の容量上限が設定されていることまでは証明しません。
使用量が想定した定常状態の範囲を超えて増え続ける場合は、実際のディレクトリ、アクティブなファイルとアーカイブ済みファイルのサイズ、ジャーナルの名前空間、有効な設定、systemd のバージョンを記録してください。どの構成要素が容量を消費しているかを証拠で特定するまでは、目標値を繰り返し下げないでください。
