Jellyfinのログでシステムディスクがいっぱいになるのを防ぐ方法

Jellyfinのログが増え続け、データベースやキャッシュ、OSと最後の空き容量を奪い合う状態は、決して許容すべきではありません。Jellyfin自身のログ出力レベルと、同じイベントを再収集している可能性があるコンテナまたはホストのログ層の両方を制限して、障害を防ぎましょう。

小容量のホームサーバーのシステムディスクでは、2つの独立したログ経路が同時に増えるため、この問題を見落としやすくなります。Jellyfinはアプリケーションログを書き込み、Docker、journald、または別のスーパーバイザーは標準出力と標準エラー出力を別途保持できます。まず実際に容量を消費している経路を特定し、その層で保持量に上限を設け、通常利用でクリーンアップが機能することを確認してください。さらに、将来のデバッグセッションでディスクが気付かないうちに満杯にならないよう、空き容量のアラートも設定します。

実際に増えているログ保存先を特定する

削除する前に測定しましょう。Jellyfinで設定されているログディレクトリのサイズと、コンテナランタイムまたはサービスマネージャーのログ保存先のサイズを比較し、通常のライブラリスキャンや再生セッションを再現している間に、どちらが変化するかを確認します。片方の経路だけが増えている場合は、複数のローテーション設定を同時に変更せず、その経路を修正してください。

Jellyfinのトラブルシューティングガイドでは、デバッグログは非常に大量の出力を生成する可能性があり、短時間のトラブルシューティングに限って使用するものだと説明されています。そのため、最初に確認すべきなのは、カスタムのlogging.jsonで詳細なログ出力を行うカテゴリが有効になっていないかどうかです。保持期間や保持量を変更する前に、デバッグログのガイダンスを確認してください。

Jellyfin自身のログディレクトリが安定しているのにホストのシステムディスクの空き容量が減り続ける場合は、次にランタイムのログを調べます。この結果は、Jellyfinのログファイルを削除しても目に見える症状に対処するだけで、2つ目のログ層が増え続けることを意味します。

ランタイム層で保持量の上限を設定する

コンテナでは、無制限の増加に頼るのではなく、最大値が明確に定義されたログドライバーとローテーションポリシーを選択してください。この設定を新しく作成するコンテナに適用し、設定した最大値を記録しておきます。そうすれば、将来Composeファイルを再構築しても保護設定が失われません。

Dockerの説明によると、デフォルトのjson-fileログはローテーションを設定しないと大量のディスク容量を消費する可能性があります。一方、localドライバーはデフォルトでローテーションを行います。このコンテナログのローテーション動作を参考に、max-size／max-fileに上限を設定するか、localドライバーを使用するか判断してください。

ランタイムポリシーを変更した後、ランタイムで必要とされる場合はJellyfinコンテナを再作成し、稼働中のコンテナが実際に新しいドライバーを使用していることを確認します。新しく作成したコンテナにしか適用されないデーモンレベルの設定は、Jellyfinインスタンスがその設定を継承するまで、解決策として機能しません。

Jellyfinのクリーンアップを活用しつつ、それだけに頼らない

Jellyfinには、ログ、キャッシュ、アクティビティログ、トランスコードデータを削除するメンテナンスタスクが用意されています。ただし、スケジュールされたクリーンアップは第2の防御策であり、ログを無制限に増やしてよい理由にはなりません。タスクが失敗したり遅延したりする可能性があり、急激なログ増加によってクリーンアップの実行前に残りのシステム容量を使い切ることもあります。

ダッシュボードのタスク履歴でログクリーンアップタスクが正常に実行されていることを確認し、次回のスケジュール実行の前後でログディレクトリのサイズを比較します。ディレクトリがまったく小さくならない場合は、スケジュールをむやみに短縮するのではなく、タスクのエラーやパスの不一致を調査してください。

ホームサーバーでは、アプリケーションの状態やメディア処理を把握できる状態に保ちながら、診断ファイルが起動ディスクを圧迫しないようにするのが有効です。同じリソース優先の考え方は、Jellyfinのバッファリングをトラブルシューティングする場合にも役立ちます。ログは実際のボトルネックを示す場合にのみ有用だからです。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

デバッグログは時間を限定した診断モードとして使う

デバッグ出力が必要な場合は、有効化する前に開始時刻、再現する時間帯、停止条件を決めておきます。問題が発生する操作を実行し、関連するログの一部を安全な場所に保存したら、証拠を取得した直後に設定を通常の出力レベルへ戻してください。

現在ディスク容量に余裕があるからといって、デバッグログを何日も有効にしたままにしないでください。トラフィックの少ない夜間とライブラリスキャンでは出力量が大きく異なるため、あるテストでは問題なさそうな設定でも、スケジュールされた処理中には大きな負荷になる可能性があります。

通常のログ出力に戻した後、設定上必要であれば1度再起動し、通常の再生とスケジュールされたタスクを1回ずつ再現します。ログの増加率が基準値に戻るはずです。戻らない場合は設定を再確認し、Jellyfinが実際に読み込んでいるファイルが想定したファイルであることを確認してください。

ディスクが危険な状態になる前に空き容量の停止条件を追加する

Jellyfinのデータ、ランタイムログ、またはOSが存在するファイルシステムに、シンプルなアラートを設定します。ホスト全体で書き込みエラーが発生し始めるまで待つのではなく、原因を調査して安全にサービスを停止できるだけの余裕が残るよう、しきい値を設定してください。

空き容量が予期せず減少した場合は、まず大量にログを出力しているソースを停止し、少量の診断サンプルを保存します。そのうえで、明らかに不要なログまたはキャッシュだけを削除してください。容量を確保するために、Jellyfinのデータベースや設定、用途不明のボリュームの内容を最初に削除しないでください。

通常の再生、ライブラリタスク、再起動を行ってもログが無制限に増加せず、アラートもしきい値を十分上回った状態が維持されれば、予防策は完了です。ログに上限を設けても空き容量が減り続ける場合は、原因がJellyfinのログだと証明できなくなっているため、より広範なディスク使用量の監査に進んでください。