メインサービスは起動するものの依存関係が失敗した場合にPlexを復旧する方法
Plexが起動しているものの依存関係のいずれかが失敗している場合は、稼働中のサービスを基準にして、欠落しているストレージ、ネットワーク、プロキシ、または認証経路を特定します。
コンテナの状態が緑色であることから分かるのは、Plexプロセスが起動したということだけです。メディアのマウントが存在すること、アプリデータに書き込めること、DNSが名前解決できること、リモートエッジに到達できることまでは保証されません。依存関係を内側から外側に向かってテストし、失敗したレイヤーだけを変更してください。
まずアプリデータとメディアマウントを確認する
マウントが存在しない、または読み取り専用になっていると、プロセスが動作したままライブラリが表示されなくなったり、書き込みに失敗したりすることがあります。コンテナを何度も再起動する前に、Plexで使用するよう設定されている正確なパスを確認してください。
ネットワークストレージの切断により、ホストとPlexプロセスがオンラインのままメディアにアクセスできなくなることがあります。
コンテナ内からマウント済みのパスを一覧表示し、メディアに対する安全な読み取りと、アプリデータに対する使い捨てファイルの書き込みを実行します。Plexの設定を変更する前に、マウントまたは権限を修復してください。
DNSとネットワーク到達性を確認する
ストレージに問題がなければ、サービスが実際に必要とするネットワーク依存先に到達できることを確認します。プロキシ、DNS、リモートストレージ、VPNの障害は、それぞれ個別に切り分けてください。
基本的なルートメトリックによって、複数のネットワーク経路が存在する場合に選択されるインターフェースが決まります。
依存先の名前を解決し、Plexホストから実際の宛先への接続をテストします。Plexの外部でも接続に失敗する場合は、ルーティング、DNS、またはファイアウォールポリシーの範囲で修復してください。
証明されるまでは補助サービスを任意扱いにする
ダウンローダー、リクエスト管理ツール、インデクサーはワークフローを改善できますが、コアの再生に必須とは限りません。重要でない補助サービスが不健全になっただけで、スタック全体を再起動しないでください。
一般的なマルチコンテナ依存関係パターンを使うと、必須の依存関係と、独立して縮退動作させるべきサービスを区別できます。
失敗した補助サービスを意図的に停止し、ローカルのPlex再生と状態の書き込みを確認します。コアサービスが健全なままなら、補助サービスを個別に復旧してください。一貫した永続アプリデータのレイアウトがあれば、壊れた依存関係と、Plexの状態が存在しない、または書き込み不可である状態を区別しやすくなります。
エンドツーエンドの検証で締めくくる
依存関係を修復したら、正常なプロセス状態で止めるのではなく、最初に失敗したユーザーワークフローを検証します。再生、状態の書き込み、リモートアクセスはそれぞれ異なる経路を使用します。
最後に使用率、飽和度、エラーの確認を行い、修復した依存関係が単に到達可能なだけでなく、直ちに飽和したりエラーを起こしたりしていないことを確認します。
ログを開いた状態で最初に発生した障害を再現し、修復結果を記録します。次回のインシデントが正しいレイヤーから始まるよう、依存関係のテストを運用手順書に追加してください。
おすすめ商品
サポートとヒント
もっと読む
Jellyfinをライブ状態でバックアップすべきか、それとも先にサービスを停止すべきか？
シンプルさを重視するならサービスを停止してバックアップする方法を優先し、アプリケーションの状態が一貫して取得され、復元テストも実施済みの場合に限り、稼働中のスナップショットを使用してください。
誰もストリーミングしていないのに、Jellyfinが高温になったり、動作音が大きくなったりするのはなぜですか？
アイドル時の発熱は通常、バックグラウンド処理または共有ホストのワークロードを意味するため、冷却やハードウェアを変更する前に、実行中のプロセスとスケジュールされたタスクを特定してください。
Jellyfinは修理より再構築すべきタイミングとは？
ランタイムの不整合が問題で、永続状態がバックアップされている場合は、修復より再構築を選択してください。ただし、唯一の正常なデータベースを削除して「再構築」してはいけません。
