CasaOSのjournaldディスク使用量：ログ機能を壊さずにログを制限する

結論：小容量の CasaOS システムディスクがいっぱいになる前に journald に上限を設定する

元の CasaOS システムでは、5 GB を超える容量が /var/log/journal。確実な対策は、ジャーナルファイルを手動で削除することではありません。サイズの上限を設定し、必要に応じて最低空き容量を確保し、古いアーカイブ済みログを一度削除してください。その後は journald がポリシーを自動的に適用します。

変更前にジャーナルの使用量を測定する

journalctl --disk-usage
du -sh /var/log/journal 2>/dev/null
df -h /var

小容量の起動ディスクでログが数ギガバイトを消費している場合は、実際に必要な最近の履歴の量を決めてください。ホームサーバーでは、デフォルトによってファイルシステムの一定割合が消費されるのを許すより、固定の上限を設定するほうが通常は予測しやすくなります。

journald.conf でサイズと保持期間の上限を設定する

[Journal]
SystemMaxUse=1G
SystemKeepFree=1G
MaxRetentionSec=14day

SystemMaxUse は永続ジャーナルのストレージ容量を制限し、SystemKeepFree は OS の他の用途のために空き容量を確保します。時間ベースの上限も設定したい場合は、MaxRetentionSec を任意で指定できます。これらの上限がどのように連動するかについては、journald のサイズ制限で説明されています。

ポリシー設定後に古いログを一度削除する

sudo journalctl --rotate
sudo journalctl --vacuum-size=1G

ログの削除処理では、アーカイブ済みのジャーナルファイルが削除されますが、設定は置き換わりません。削除処理を行うだけで上限を設定しなければ、ディレクトリは再び増大する可能性があります。journalctl の削除操作では、サポートされているクリーンアップコマンドを確認できます。

設定ファイルを置き換えるだけのために journald を停止しない

2024年の投稿では、サービスを停止し、設定を削除して置換ファイルをコピーしていました。動作はしますが、必要以上に大きな影響があります。ファイルを安全に編集してバックアップを保持し、その後サービスを再起動してください。

sudo cp /etc/systemd/journald.conf /etc/systemd/journald.conf.bak
sudo nano /etc/systemd/journald.conf
sudo systemctl restart systemd-journald

journald は別のディスクにログを保存できますか？

内の単純な任意のパス経由ではありません journald.conf. Storage=persistent 対象とする /var/log/journal; Storage=volatile 使用する /run/log/journal他の場所でより長くログを保持する必要がある場合は、重要なシステムパスを安易にバインドマウントするのではなく、ログを別の syslog/journal ホストに転送してください。

過剰なログを生成しているサービスを特定する

journalctl -p warning..alert --since "24 hours ago"
journalctl --since "24 hours ago" | tail -200
systemctl --failed

ディスク容量の上限はOSを保護しますが、同じエラーを何千回も記録するサービス自体を直すことはできません。システムに余裕ができたら、ログ出力の多いサービスを修正してください。

古いCasaOSのインストール環境から、よりアプライアンス型のサーバーへの移行を検討している場合、ZimaBoard 2プラットフォームとZimaOSバックアップが、より安全な移行環境を提供します。

1つのサービスによるジャーナルの大量出力を防ぐ

1つのコンテナやデーモンが同じ警告を継続的に出力している場合、グローバルなストレージ上限は被害を抑えるだけです。最もログ出力の多いユニットを確認し、原因を修正してください。

journalctl --since "1 hour ago" -o short-unix | tail -500
journalctl -u SERVICE_NAME --since "1 hour ago"

systemdが管理するサービスでは、ユニットごとのログレート制御により、他のすべてのシステムログを破棄することなくバーストを抑制できます。レート制限は、何が抑制されるのかを理解してから使用してください。ストレージ、ファイルシステム、ネットワークに関するエラーが繰り返される場合、それが根本的な問題の解決に必要な証拠となることがあります。

よくある質問

SystemMaxUseはどの程度に設定すべきですか？

一律に適用できる値はありません。小容量のOSディスクでは、長期間のログ履歴をほとんど必要としない場合、500 MB～2 GBが実用的な開始範囲です。更新やアプリケーションのメタデータ用に十分な空き容量を残してください。

journalctl --vacuum-sizeは現在のログを削除しますか？

目標サイズに近づくまで、アーカイブ済みのジャーナルファイルを削除します。アクティブなジャーナルをアーカイブ済みセットに移動したい場合は、先にローテーションしてください。

/var/log/journalにlogrotateを使用すべきですか？

いいえ。バイナリ形式のジャーナルファイルはsystemd-journald自体が管理します。journaldのサイズ・保持設定と、journalctlのvacuum操作を使用してください。

ログを別のHDDに保存できますか？

ログ転送や意図的に設計したマウントを利用すれば可能ですが、journaldには任意のカスタムパスを設定する機能はありません。コアOSディレクトリを移動するより、通常はリモートロギングのほうが安全です。

ジャーナルが数ギガバイトに達したのはなぜですか？

デフォルトのポリシーでは大量のストレージ使用が許可される場合があり、ノイズの多いサービスが短時間で大量のエントリを生成することがあります。設定された上限と、大量のログを生成しているサービスの両方を確認してください。