systemdジャーナルが満杯になった場合の対処法

systemdのジャーナルには、サーバーが生成するすべてのログメッセージが保存されます。ルートパーティションの容量が小さいVPSでは、これらが知らぬ間に利用可能なディスク容量を消費してしまうことがあります。そうなると、サービスの起動に失敗したり、書き込みが停止したりし、何が問題なのかを特定するために必要な診断情報そのものを失うことになります。このガイドでは、問題の診断方法、直ちに空き容量を確保する方法、そして再発を防ぐためのjournaldの設定方法について解説します。

問題の診断

まず、ジャーナルが使用している容量を確認します:

journalctl --disk-usage

これは、アクティブなジャーナルファイルとアーカイブされたジャーナルファイルの合計サイズを示します。これを、利用可能なディスク容量と比較してください。 df -h。20 GBのルートパーティションの場合、ログが2 GBあるだけでもディスク全体の10%以上を占めることになり、問題を引き起こすのに十分な量です。

次に、どのサービスが最も多くのログを生成しているかを確認します。次のワンライナーは、過去24時間におけるログ発生元の上位10件をランク付けします：

journalctl --since "24 hours ago" | awk '{print $5}' | cut -d'[' -f1 | sort | uniq -c | sort -rn | head -10

特にエラーをフィルタリングするには journalctl -p err -b を使用してエラーを具体的にフィルタリングし、単一のサービスがクラッシュループに陥ってジャーナルを溢れさせていないかを確認します。また、journaldが特定のサービスに対してレート制限を行っているかどうかも確認できます：

journalctl -u systemd-journald | grep -i "suppressed"

「Suppression」メッセージは、サービスが30秒以内にデフォルトのしきい値である10,000エントリを超過したことを意味します。それが原因です。

VPSインスタンスでは、特に以下の現象がよく見られます。もし Storage=auto が設定されており、 /var/log/journal/ が存在する場合、journaldはデフォルトで約4GBの上限を持つ永続ストレージを使用します。ルートパーティションが小さい場合、すぐに容量がいっぱいになります。また、不適切なシャットダウンにより、 .journal~ という拡張子を持つ破損したジャーナルファイルが残されることもあります。これらのファイルは正常にローテーションされず、スペースを消費し続けます。

ログの安全な消去

何かを削除する前に、アクティブなジャーナルファイルをローテーションして、現在のログが保存されるようにしてください:

journalctl --rotate

その後、アーカイブされたログを削除します。削除対象は、経過時間、サイズ、またはファイル数で指定できます：

sudo journalctl --vacuum-time=1d
sudo journalctl --vacuum-size=100M
sudo journalctl --vacuum-files=5

最初のコマンドは24時間以上経過したログを削除します。2番目のコマンドはジャーナルの総容量を100MBに縮小します。3番目のコマンドは、アーカイブされたファイルのうち最新の5つだけを残します。状況に合わせて適切な方法を選択してください。

ディスクが完全に満杯で、journalctl コマンドが反応しない場合は、ジャーナルファイルを手動で削除する必要があるかもしれません：

sudo rm -rf /var/log/journal/*
sudo systemd-tmpfiles --create --prefix /var/log/journal

これは最終手段です。これにより、保存されているすべてのログが消去され、適切な権限でディレクトリが再作成されます。クリーンアップ後は、デーモンを再起動して確認してください:

sudo systemctl restart systemd-journald
journalctl --disk-usage

Journaldのサイズ制限の設定

Journaldのデフォルト設定は余裕のあるものになっています。VPS環境では、その設定は過剰です。ログ保存容量に上限を設定するため、設定ファイルを編集してください。パッケージの更新後も変更が維持されるよう、メインの設定ファイルを直接編集するのではなく、オーバーライドファイルを作成してください：

sudo mkdir -p /etc/systemd/journald.conf.d/
sudo nano /etc/systemd/journald.conf.d/size-limits.conf

主なディレクティブ：

両方を設定 SystemMaxUse と SystemKeepFree の両方を設定すると、二重の安全策となります。ログは固定サイズに制限され、ディスク上の他の状況にかかわらず、システムには常に余裕が確保されます。

永続ストレージと揮発性ストレージ

` Storage= ディレクティブはログの保存先を制御します。 Storage=persistent を /var/log/journal/ に設定します。これは本番サーバーに最適な設定です。ログが再起動後も保持されるため、事後的にクラッシュの原因を調査できるからです。ディレクトリが存在しない場合は、作成してください：

sudo mkdir -p /var/log/journal

もう一つの選択肢である Storage=volatileは、ログを /run/log/journal/。再起動するとログは消去されます。これは、一時的なコンテナや、すべてのログを外部システムに転送するサーバーに適しています。

高トラフィックサーバーでの圧縮の無効化

Journaldはデフォルトで、512バイトを超えるデータオブジェクトを圧縮します。ログの処理量が膨大なサーバーでは、これによりCPUのオーバーヘッドが増加します。 Compress=no を有効にしてください。また、本番環境では ForwardToConsole=no を有効にしてください。コンソールの転送は同期処理であり、仮想シリアルコンソールが停止すると、journaldデーモン全体がブロックされる可能性があります。

設定変更後は、必ずサービスを再起動してください:

sudo systemctl restart systemd-journald

ログ管理の自動化

手動でのクリーンアップはスケーラブルではありません。systemdタイマーを作成し、スケジュールに従ってログを削除するようにします。 /etc/systemd/system/journal-vacuum.service:

[Unit]
Description=Vacuum old journal logs
 
[Service]
Type=oneshot
ExecStart=/usr/bin/journalctl --vacuum-time=7d --vacuum-size=500M

次に、対応するタイマーを /etc/systemd/system/journal-vacuum.timer:

[Unit]
Description=Weekly journal vacuum
 
[Timer]
OnCalendar=Sun 02:00
Persistent=true
 
[Install]
WantedBy=timers.target

で有効にします sudo systemctl enable --now journal-vacuum.timerで有効にします。このタイマーは毎週日曜日の午前2時に実行され、時間ベースとサイズベースの両方の保持ルールを1回の処理で適用します。

タイマーでは対処できないものとして、破損したジャーナルファイルがあります。不正なシャットダウン後、journaldはファイル名に ~ をファイル名に付加して隔離します。これらの .journal~ ファイルはディスク使用量にはカウントされますが、自動的にバキュームされることはありません。定期的に古いファイルを確認し、削除してください：

find /var/log/journal/ -name "*.journal~" -mtime +30 -delete

ログの外部転送

ローカルストレージを増設せずに長期保存が必要なサーバーでは、ログを集中管理システムに転送してください。最も簡単な方法は、 journald.conf:

ForwardToSyslog=yes

完全なメタデータ（PID、UID、ユニット名）を含む構造化ログの場合は、 systemd-journal-remote を使用して、JSON形式のエントリをログ管理プラットフォームに送信します。外部ログストレージは、ローカルディスクの障害やサーバーへの不正アクセスが発生した場合でも、監査証跡を保護します。

結論

systemdのジャーナルが満杯になる問題は、修正も予防も簡単です。主な手順は以下の通りです：

• 以下のコマンドで利用状況を確認し journalctl --disk-usage を使用して使用状況を確認し、ノイズの多いサービスを特定します。
• 直ちに journalctl --rotate を実行し、続いて --vacuum-size または --vacuum-time.
• journald.confのオーバーライドファイルで明示的なサイズ制限を設定します。
• systemd タイマーを使用してクリーンアップを自動化します。
• 長期保存のためにログを外部に転送します。

FDCのVPSおよび専用サーバープランは、本番環境のログワークロードに必要なディスクI/Oとストレージを提供します。