修復 Jitsi Meet Docker 容器無限重啟循環問題

Jitsi Meet 部署可能會短暫運行，然後在 Docker Desktop 或其他應用程式中顯示一個或多個服務「正在重新啟動」docker compose ps。這通常是 Docker 在進程退出後套用已配置的重新啟動策略。徹底的解決方法是找到退出的服務，讀取其最後日誌，並修正啟動錯誤。重複重啟整個堆疊或刪除其磁碟區可能會掩蓋痕跡或刪除持久性資料。

1. 找到正在重啟的服務

從包含用於啟動本次安裝的相同 Compose 檔案的目錄中執行 Compose .env。如果您通常使用額外的 Compose 檔案、設定檔或其他配置--env-file，請包含相同的選項。

docker compose ps -a

分別檢查每個服務。核心服務包含 `<service>`、`<service>` 、web` <service>` 和`<service>`；可選服務（例如 `<service>`或 `<service> `）也可能出現。記下狀態為 `<service> ` 或 `<service>`的具體服務。一個服務故障並不意味著每個容器都存在相同的故障。prosodyjicofojvbjibrijigasiRestartingExited

使用時間戳記讀取該服務的日誌尾部：

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 實際載入的檔案。常見的錯誤是，.env當 Compose 從其他目錄或明確提供的路徑讀取檔案時，您卻修改了該檔案--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，容器以非特權使用者身分運行，容器檔案系統為唯讀。配置目錄是輸入目錄；可寫入資料被分成 `configuration`storage和 ` tmpfiles` 目錄，這些目錄必須對 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

受影響的服務應保持運行，其重啟次數應停止增加，且其日誌不應再重複出現相同的致命錯誤訊息。確認網頁可以加載，並與兩位客戶端測試會議。如果服務持續運作但參與者無法交換音頻或視頻，請檢查網路、防火牆規則以及 Jitsi 手冊中公佈的 JVB 位址。

作為參考，請使用Jitsi Meet Docker 自託管指南、專案環境變數範例、Docker重啟策略文件、其Compose 日誌參考和容器檢查參考。