Risoluzione del problema del ciclo infinito di riavvio del container Docker di Jitsi Meet.

Un'implementazione di Jitsi Meet potrebbe essere eseguita per un breve periodo e poi mostrare uno o più servizi come "In riavvio" in Docker Desktop o in docker compose ps. Docker di solito applica la policy di riavvio configurata dopo la terminazione di un processo. La soluzione definitiva consiste nell'identificare il servizio che si arresta, leggere i suoi ultimi log e correggere l'errore di avvio. Riavviare ripetutamente l'intero stack o eliminare i suoi volumi può nascondere prove o rimuovere dati persistenti.

1. Individua il servizio che si sta riavviando

Esegui Compose dalla directory contenente lo stesso file Compose .envutilizzato per avviare questa installazione. Se normalmente utilizzi file Compose aggiuntivi, profili o --env-fileopzioni, includi anche queste.

docker compose ps -a

Controlla ciascun servizio separatamente. I servizi principali sono web, prosody, jicofo, e jvb; potrebbero essere presenti anche servizi opzionali come jibrio jigasi. Prendi nota del servizio esatto il cui stato è Restartingo Exited. Un servizio non funzionante non significa che ogni container presenti lo stesso problema.

Leggi la coda del log per quel servizio, utilizzando i timestamp:

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

Sostituisci jicofocon il servizio interessato. Aggiungi -fper monitorare un altro tentativo di avvio. La guida Docker di Jitsi documenta la composizione dei log per i suoi servizi. Se Docker non è in grado di restituire i log, verifica se il driver di logging configurato per quel container supporta la lettura degli stessi.

2. Cerca il primo messaggio fatale

Scorri fino al primo errore chiaro in ogni ciclo di avvio. Le righe successive potrebbero indicare solo che il processo si è arrestato e che Docker lo sta riavviando. Le cause principali più comuni includono:

• Password mancanti: Jitsi ha rimosso le password predefinite per gli account di servizio interni e i servizi che le richiedono non si avvieranno finché non saranno impostate. Dalla directory di distribuzione standard, eseguire lo ./gen-passwords.shscript fornito per inserire i valori richiesti in .env. Proteggere tale file e non pubblicare mai i suoi segreti in una richiesta di supporto.
• Configurazione non valida o illeggibile: verificare il percorso del file e la sintassi indicati nell'errore. Una configurazione personalizzata di Prosody, Jicofo o JVB potrebbe impedire l'avvio del servizio in questione.
• Una directory montata mancante o non scrivibile: verifica il percorso host esatto nell'errore e confrontalo con la mappatura del volume del servizio. Evita di modificare le autorizzazioni nell'intero albero di configurazione.
• Errore dell'immagine o del punto di ingresso: verificare che la directory di distribuzione, il file Compose e i tag dell'immagine appartengano a versioni compatibili, soprattutto se il ciclo si è avviato dopo un aggiornamento.
• Pressione sulla memoria: ispezionare lo stato del container e la memoria dell'host. Un arresto anomalo per esaurimento della memoria richiede una soluzione diversa rispetto a una configurazione non corretta.

Una policy di riavvio di Docker spiega perché un processo si riavvia dopo essere terminato; non spiega perché il processo è terminato. Consideralo Restartingcome un sintomo e il log del servizio come la prova.

3. Convalidare l'ambiente e i file di composizione

Assicurati di modificare il file che Compose effettivamente carica. Un errore comune è quello di modificarne uno .envmentre Compose ne legge un altro da una directory diversa o da un percorso specificato esplicitamente --env-file. Convalida la configurazione prima di ricreare i container:

docker compose config --quiet

Se Compose segnala un errore, correggi il file YAML, la sostituzione delle variabili, il file di riferimento mancante o l'opzione indicata. L'esecuzione docker compose configsenza --quietpuò aiutare a ispezionare il modello risolto, ma potrebbe stampare password interpolate. Non condividere l'output non redatto.

Per un'installazione standard di Jitsi, confrontala .envcon quella env.exampledella stessa release e verifica che siano presenti le password interne richieste. Se utilizzi un file Compose personalizzato, controlla che le variabili necessarie raggiungano il servizio corretto. Utilizza lo script per le password incluso anziché i segnaposto vuoti. Se modifichi una password, mantieni coerente la configurazione del componente corrispondente.

Il progetto Jitsi distingue i file di rilascio standard dal codice di sviluppo e dalle immagini instabili. Evita di combinare una vecchia directory Compose, tag di immagine arbitrari e file provenienti da una versione diversa durante la risoluzione dei problemi.

4. Verificare i punti di montaggio della configurazione e le autorizzazioni

Confronta le voci del volume del servizio con i percorsi host effettivi. Un errore di battitura, CONFIGun valore imprevisto o una directory di lavoro Compose diversa possono far sì che la distribuzione utilizzi una directory di configurazione diversa.

I permessi dipendono dalla versione di Jitsi. Il manuale indica che a partire da stable-11146, i container vengono eseguiti come utente non privilegiato con un filesystem di sola lettura. Le directory di configurazione sono input; i dati scrivibili sono separati nelle directory storagee tmp, che devono essere scrivibili dall'utente UID/GID 1000. Le versioni precedenti utilizzano una struttura diversa. Segui il manuale per la versione in uso anziché riutilizzare una configurazione di permessi per una versione diversa.

Se il log identifica una directory mancante o non scrivibile, ripara esattamente quel percorso. Non applicare comandi generici come chmod -R 777all'intera directory di configurazione di Jitsi; ciò potrebbe compromettere la sicurezza senza correggere il percorso montato.

5. Esamina lo stato di uscita e le modifiche recenti

Docker può segnalare il codice di uscita di un container, lo stato di memoria insufficiente, il numero di riavvii e gli errori del demone. Per prima cosa, recupera l'ID del container per il servizio che presenta l'errore:

docker compose ps -q jicofo

Quindi sostituisci l'ID restituito:

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

Un numero crescente di riavvii conferma tentativi ripetuti. In tal caso oom=true, verificare i limiti di memoria dell'host o del container e i log di sistema. Un codice di uscita diverso da zero da solo non è sufficiente per una diagnosi; confrontarlo con il log del servizio.

Se il ciclo è iniziato dopo un aggiornamento, annota cosa è cambiato: file di rilascio, tag delle immagini, una password, un bind mount o una configurazione personalizzata. Esegui il backup della configurazione e dei dati persistenti prima di cambiare versione. Ripristina un set compatibile di file e immagini Compose oppure segui le istruzioni di aggiornamento di Jitsi. I problemi di rete e firewall possono impedire ai partecipanti di connettersi, ma di solito non spiegano perché un processo di servizio si arresta ripetutamente; distingui un errore di avvio da un problema di connettività multimediale.

6. Ricreare il servizio dopo aver risolto la causa.

Dopo aver modificato un valore di ambiente o una definizione Compose, ricrea il servizio interessato per applicare la nuova configurazione:

docker compose up -d --force-recreate jicofo

Sostituisci il nome del servizio. Se una modifica alla configurazione condivisa interessa più componenti, ricrea contemporaneamente i servizi pertinenti. Quindi, rivedi lo stato e i log. Un semplice riavvio non applica tutte le modifiche di Compose o dell'ambiente, mentre la ricreazione dell'intero stack potrebbe interrompere le riunioni in corso.

Non utilizzare questa opzione docker compose down -vcome soluzione generica per i cicli di riavvio. L' -vopzione rimuove i volumi gestiti da Compose e potrebbe eliminare i dati che si intendeva conservare. Salvare i log e verificare i punti di montaggio prima di rimuovere container o dati.

Verifica la correzione

Verifica lo stato, attendi alcuni intervalli di avvio normali e controlla di nuovo:

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

Il servizio interessato dovrebbe rimanere attivo, il conteggio dei riavvii dovrebbe smettere di aumentare e il suo registro non dovrebbe più ripetere lo stesso messaggio di errore irreversibile. Verificare che la pagina web si carichi correttamente ed eseguire una riunione di prova con due client. Se i servizi rimangono in esecuzione ma i partecipanti non riescono a scambiarsi audio o video, esaminare la rete, le regole del firewall e l'indirizzo JVB pubblicizzato nel manuale di Jitsi.

Per riferimento, consultare la guida all'hosting self-service di Jitsi Meet per Docker , l' esempio di variabile d'ambiente del progetto , la documentazione sulla politica di riavvio di Docker , il riferimento ai log di Compose e il riferimento all'ispezione dei container .