Plexは起動するのにバックグラウンドワーカーがオフラインのまま：確認すべきこと

Plexが起動しているのにバックグラウンドワーカーがオフラインのままなら、何でも再インストールする前に、ワーカーのエラー、アプリデータへの書き込み権限、ストレージの空き容量、依存パスを確認してください。

Webインターフェースから分かるのは、メインサービスに到達できるということだけです。スキャナー、メタデータ、トランスコード、メンテナンスなどの処理は、ヘルパープロセスが書き込めない、一時パスが満杯になっている、マウントされた依存先が変わったといった理由で個別に失敗することがあります。ホスト全体を何度も再起動するのではなく、まず失敗した最小単位のジョブから始め、実際のプロセスとパスを正確に追跡してください。

実際に失敗しているワーカーまたはジョブを特定する

バックグラウンド処理は単一のサブシステムではないため、「ワーカーがオフライン」という状態には、具体的にどの操作が失敗しているのかを確認する必要があります。スキャナーの失敗、トランスコードヘルパーの失敗、データベースメンテナンスの失敗では、関係するリソースが異なります。

明示的なDockerボリュームマッピングにより、サービス間でパスの可視性と書き込み所有権を分離して確認できます。

失敗していることが分かっている操作を1つ実行し、その時間帯のPlexログ行と子プロセスの動作を記録してください。メインサービスが正常でも、1つのヘルパーだけが終了している場合は、次のテストをそのヘルパーと依存先に限定します。

アプリデータと一時パスが書き込み可能か確認する

Webプロセスが既存の状態を読み取れる場合でも、ワーカーはデータベース、メタデータ、キャッシュ、一時ファイルを作成する必要があることがよくあります。そのため、読み取り専用のマウントや不一致のあるマウントによって、メインプロセスを停止させずにバックグラウンド処理だけが失敗することがあります。

コンテナのUIDとGIDのマッピングにより、サービスの識別情報とバインドマウント先におけるホストファイルシステムの数値所有権が結び付けられます。

失敗したジョブが使用するアプリデータパスとトランスコードパスに対して、PlexのサービスIDで使い捨ての書き込みテストを実行します。書き込みテストが失敗する場合は、Plexの設定を変更する前に、マウントモードまたは所有権を修正してください。必要なパスに、場当たり的なバインドマウントではなく文書化された永続コンテナストレージを使用すると、バックグラウンドワーカーを復旧しやすくなります。

空き容量とI/Oエラーを確認する

ファイルシステムの空き容量がほとんどない、またはストレージパスに障害がある場合でも、既存のページは読み込める一方で、新しいワーカー出力だけが失敗することがあります。これは、一時ファイルや増加し続けるファイルを作成するトランスコード、プレビュー、メタデータのジョブで特に重要です。

リソース飽和の確認により、1つの使用率だけを見るのではなく、実際の制約に焦点を絞って診断できます。

ワーカーの失敗を再現しながら、ファイルシステムの空き容量、inodeの空き状況、カーネルのI/Oエラー、デバイスのレイテンシを確認してください。エラーや容量枯渇が見つかった場合は、ジョブを再試行する前にストレージの問題を解決します。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

依存先の確認後にのみワーカーを再作成する

Plexを再インストールすると元の原因が隠れてしまうことがあり、マウントや権限の問題はそのまま残ります。クリーンな再起動が役立つのは、ファイルシステムと依存先に問題がないことを確認した後だけです。

コンテナのアップグレード計画では、永続状態の保護、ロールバックの定義、結果の検証を行う必要があります。

確認済みの依存先を修正した後、同じイメージでコンテナを再起動するかジョブを再試行し、スモークテストを1つ実行します。パスが正常でリソースエラーもないのにヘルパーが引き続き失敗する場合は、正確なログを収集し、既知の正常バージョンと比較してから、さらに詳しい調査へ進んでください。