Jellyfinの警告は、いつ監視を続けても安全で、いつ停止すべきか？

影響範囲が把握でき、原因が拡大しておらず、再生・書き込み・復旧に問題がない場合に限り、Jellyfinの警告は監視を続けても安全です。

その警告はスキャン中に一度だけ表示されますか。それとも、データベースエラー、ファイル欠落、OOMによる強制終了、再起動失敗を伴って繰り返されますか。判断する前に、正確なメッセージ、タイムスタンプ、バージョン、影響を受けるパス、実行中のワークロードを記録してください。ダッシュボードにアクセスできるからといって、警告を無視しないでください。

影響を及ぼす可能性のある操作で警告を分類する

単一のアートワーク項目が利用できない場合や、一時的なクライアントの再試行に関する警告は、次回のスキャンと再生が成功すれば、通常は監視を続けられます。一方、空き容量不足、データベースへの書き込み、マウントの消失、権限、プロセスの繰り返し終了に関する警告は、より広い範囲に障害を及ぼします。実際のJellyfinインシデントでは、データボリュームが満杯になることで、SQLiteエラーやユーザーレコードの欠落が発生しています（ディスク満杯時の障害に関する証拠）。

警告がログだけに限定されているのか、それとも同じ操作によって状態が変化しているのかを確認してください。マウントが利用できない間にスキャンによってライブラリデータが削除または書き換えられている場合は、ジョブを停止し、続行する前にパスを復旧してください。

初回の実行後、次回のスケジュールタスクでも同じメッセージが表示されるか比較してください。ワークロードを変更せずに消える警告は、同じ操作で再発する警告よりもリスクが低いといえます。

2つのテストで監視の可否を判断する

管理された条件で元のトリガーを一度再現し、影響を受けるサブシステムを確認してください。ストレージについては空きバイト数とiノード、OOMについてはmemory.events、再生についてはffmpegのログ、書き込み失敗については所有者を確認します。ワークロードを変更せずに消える警告は、同じ段階で再発する警告よりもリスクが低いといえます。

2回目の実行が成功し、警告の影響範囲が拡大せず、最新のバックアップが存在する場合は、監視を続けてください。データ損失、データベースエラー、書き込み失敗、再起動ループを伴って警告が再発した場合は停止してください。再生診断の手順を使うと、警告と実際のストリーミング障害を切り分けられます。

空きバイト数とiノード、データベースの書き込み状態、プロセスの終了コード、再生モードなど、正確な結果を書き留めてください。その結果によって、次に進むべき分岐が経過観察、修復、ロールバックのいずれかに決まります。

安全に停止し、保全して、エスカレーションする

データベースまたはストレージパスが関係している場合は、実行中のスキャンやインポートを停止し、ログを保全してください。破壊的なクリーンアップは避けます。空き容量または見つからないマウントを復旧してから、確認ゲートとして一度だけ再起動してください。再起動自体を修正手段にしてはいけません。元のワークロードを再実行し、同じ操作に警告の影響が残っていないことを確認します。

可逆的な確認を行った後も警告が続く場合、データベースを開けない場合、または基盤のディスク、ファイルシステム、コンテナランタイムがエラーを報告する場合は、エスカレーションしてください。最後に正常だったバックアップと状態パスは、そのまま保持します。

修復が成功した場合は、コールド再起動後に元のトリガーを再実行し、警告が再発しないことを確認してください。ダッシュボードが開くだけでは不十分です。同じスキャンや書き込みが失敗し続けていないか確認してください。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

クリーンな再起動後に境界を確認する

可逆的な確認の後にJellyfinを一度再起動し、警告の原因となった同じスキャン、インポート、または再生操作を再実行してください。比較を意味のあるものにするため、ワークロードとストレージパスは変更しないでください。

操作が完了し、警告の影響範囲が拡大せず、次回のバックアップが引き続き読み取れる場合は、監視を続けてください。データベース、ストレージ、権限、またはプロセスの繰り返しエラーを伴って警告が再発した場合は停止してください。

再起動後も同じトリガーで失敗する場合、データベースを開けない場合、または基盤のファイルシステムがエラーを報告する場合は、保全したログと最後に正常だった状態を添えてエスカレーションしてください。