Jitsi Meet Dockerコンテナの無限再起動ループを修正する

Jitsi Meet のデプロイメントは短時間実行された後、Docker Desktop または で 1 つ以上のサービスが「再起動中」と表示されることがありますdocker compose ps。これは通常、プロセスが終了した後に Docker が設定された再起動ポリシーを適用しているためです。根本的な解決策は、終了したサービスを特定し、その最後のログを読み取って、起動エラーを修正することです。スタック全体を繰り返し再起動したり、ボリュームを削除したりすると、証拠が隠蔽されたり、永続データが削除されたりする可能性があります。

1. 再起動しているサービスを見つける

このインストールを起動する際に使用したのと同じ Compose ファイルを含むディレクトリから Compose を実行してください.env。通常、追加の Compose ファイル、プロファイル、またはオプションを使用している場合は--env-file、それらのオプションもすべて含めてください。

docker compose ps -a

各サービスを個別に確認してください。コアサービスはweb、、、、およびですprosody。やなどのオプションサービスも表示される場合があります。状態がまたはであるサービスを正確にメモしてください。1つのサービスが障害を起こしているからといって、すべてのコンテナに同じ障害があるとは限りません。jicofojvbjibrijigasiRestartingExited

タイムスタンプを使用して、そのサービスのログの末尾を読み取ってください。

docker compose logs --tail=150 --timestamps jicofo

jicofo影響を受けるサービスに置き換えてください。-f別の起動試行を監視するように設定します。Jitsi Docker ガイドには、サービスの Compose ログに関するドキュメントがあります。Docker がログを返せない場合は、そのコンテナに設定されているログドライバがログの読み取りをサポートしているかどうかを確認してください。

2. 最初の致命的なメッセージを探す

各起動サイクルで最初に明確なエラーが表示されるまでスクロールしてください。それ以降の行では、プロセスが停止し、Dockerが再起動していることのみが報告される場合があります。一般的な根本原因は次のとおりです。

• 必要なパスワードがありません: Jitsi は内部サービス アカウントのデフォルト パスワードを削除したため、パスワードが必要なサービスは設定されるまで起動しません。標準のデプロイメント ディレクトリから、付属の./gen-passwords.shスクリプトを実行して、必要な値を に設定してください.env。このファイルは保護し、サポート リクエストにその秘密情報を投稿しないでください。
• 設定が無効または読み取り不能です。エラーメッセージに示されているファイルパスと構文を確認してください。Prosody、Jicofo、またはJVBのカスタム設定によっては、そのサービスのみが起動しない場合があります。
• マウントされたディレクトリが見つからないか、書き込みができません。エラーメッセージに表示されているホストパスを正確に確認し、サービスのボリュームマッピングと比較してください。設定ツリー全体にわたってアクセス許可を変更することは避けてください。
• イメージまたはエントリポイントのエラー:特にアップデート後にループが発生した場合は、デプロイメントディレクトリ、Composeファイル、およびイメージタグが互換性のあるリリースに属しているかどうかを確認してください。
• メモリ負荷：コンテナの状態とホストメモリを検査してください。メモリ不足による強制終了は、設定ファイルの不正な形式による強制終了とは異なる対処が必要です。

Dockerの再起動ポリシーは、プロセスが終了後に復活する理由を説明するものであり、プロセスが終了した理由を説明するものではありません。プロセス終了Restartingは症状、サービスログは証拠として捉えてください。

3. 環境とComposeファイルを検証する

Compose が実際に読み込むファイルを編集していることを確認してください。よくある間違いは、.envCompose が別のディレクトリまたは明示的に指定されたファイルから別のファイルを読み込む間に、一方のファイルを変更してしまうことです--env-file。コンテナを再作成する前に、構成を検証してください。

docker compose config --quiet

Compose がエラーを報告した場合は、YAML、変数置換、参照ファイルの欠落、またはエラーで指定されたオプションを修正してください。オプションを指定docker compose configせずに実行すると--quiet、解決されたモデルを検査するのに役立ちますが、補間されたパスワードが出力される可能性があります。編集されていない出力は共有しないでください。

標準の Jitsi インストールの場合、同じリリースの.envものと比較してenv.example、必要な内部パスワードが存在することを確認してください。カスタム Compose ファイルを使用する場合は、必要な変数が適切なサービスに渡っていることを確認してください。空のプレースホルダーではなく、付属のパスワードスクリプトを使用してください。パスワードを変更する場合は、対応するコンポーネント構成を常に同じに保ってください。

Jitsiプロジェクトでは、通常のリリースファイルと開発コードおよび不安定なイメージを区別しています。トラブルシューティングの際には、古いComposeディレクトリ、任意のイメージタグ、および異なるリリースのファイルを組み合わせないようにしてください。

4. マウントと権限の設定を確認する

サービスのボリュームエントリと実際のホストパスを比較してください。入力ミス、予期しないCONFIG値、または異なるCompose作業ディレクトリが原因で、デプロイメントが別の構成ディレクトリを使用する可能性があります。

権限は Jitsi のバージョンによって異なります。ハンドブックによると、バージョン 以降ではstable-11146、コンテナは読み取り専用のコンテナファイルシステムを持つ非特権ユーザーとして実行されます。設定ディレクトリは入力であり、書き込み可能なデータはstorageとtmpディレクトリに分けられ、これらは UID/GID 1000 で書き込み可能である必要があります。古いリリースでは別のレイアウトが使用されています。異なるリリースの権限設定を再利用するのではなく、使用しているバージョンのハンドブックに従ってください。

ログに欠落または書き込み不能なディレクトリが検出された場合は、そのパスを正確に修復してください。chmod -R 777マウントされたパスを修正せずにセキュリティを弱める可能性があるため、Jitsi 設定ディレクトリ全体に広範囲なコマンドを適用しないでください。

5. 終了状態と最近の変更点を確認する

Dockerは、コンテナの終了コード、メモリ不足の状態、再起動回数、デーモンエラーを報告できます。まず、障害が発生しているサービスのコンテナIDを取得します。

docker compose ps -q jicofo

次に、返されたIDを置き換えます。

docker inspect --format '{{.State.Status}} exit={{.State.ExitCode}} oom={{.State.OOMKilled}} restarts={{.RestartCount}} error={{.State.Error}}' CONTAINER_ID

再起動回数が増加している場合は、試行が繰り返されていることを示しています。その場合はoom=true、ホストまたはコンテナのメモリ制限とシステムログを確認してください。ゼロ以外の終了コードだけでは診断できません。サービスログと比較してください。

アップデート後にループが発生した場合は、リリース ファイル、イメージ タグ、パスワード、バインド マウント、カスタム構成など、何が変更されたかを確認してください。バージョンを変更する前に、構成と永続データをバックアップしてください。互換性のある Compose ファイルとイメージのセットを復元するか、Jitsi のアップグレード手順に従ってください。ネットワークやファイアウォールの問題により参加者が接続できなくなることがありますが、通常はサービス プロセスが繰り返し終了する理由を説明するものではありません。起動の失敗とメディア接続の問題を区別してください。

6. 原因を修正した後、サービスを再作成する

環境値またはCompose定義を変更した後は、影響を受けるサービスを再作成して新しい構成を適用してください。

docker compose up -d --force-recreate jicofo

サービス名を置き換えてください。共有構成の変更が複数のコンポーネントに影響する場合は、関連するサービスをまとめて再作成してください。その後、ステータスとログを再度確認してください。単純な再起動では、すべての Compose または環境の変更が適用されるわけではなく、スタック全体を再作成すると、進行中の会議が中断される可能性があります。

docker compose down -v再起動ループの一般的な解決策として使用しないでください。この-vオプションはComposeで管理されているボリュームを削除するため、保持するはずだったデータが削除される可能性があります。コンテナやデータを削除する前に、ログを保存し、マウントを確認してください。

修正内容を確認してください。

ステータスを確認し、通常の起動間隔を数回待ってから、再度確認してください。

docker compose ps
docker compose logs --tail=100 --timestamps jicofo

影響を受けるサービスは稼働状態を維持し、再起動回数の増加が止まり、ログに同じ致命的なメッセージが繰り返されないことを確認してください。Webページが正しく読み込まれることを確認し、2つのクライアントで会議をテストしてください。サービスが稼働しているにもかかわらず、参加者間で音声やビデオのやり取りができない場合は、ネットワーク、ファイアウォールルール、およびJitsiハンドブックに記載されているJVBアドレスを調査してください。

参考資料として、Jitsi Meet Docker セルフホスティングガイド、プロジェクトの環境変数の例、Docker の再起動ポリシーのドキュメント、Compose ログのリファレンス、およびコンテナ検査のリファレンスを参照してください。