La discussione comprendeva più di un problema di avvio delle app
Dopo l’aggiornamento da ZimaOS 1.4.1 a 1.4.2, l’autore del post originale ha constatato che alcune app, tra cui Portainer, non sembravano avviarsi automaticamente. Policy di riavvio Docker come a meno che non venga arrestato sempre sempre non ha modificato il risultato visibile, mentre facendo clic sull’app nella dashboard la si avviava.
Altri utenti hanno quindi segnalato sintomi correlati ma distinti. Un gruppo ha rilevato che i container erano già raggiungibili tramite il loro indirizzo web diretto, mentre la dashboard ZimaOS si comportava come se fossero arrestati. Un altro utente ha poi confermato che alcuni container non funzionavano realmente perché i percorsi dei volumi basati su SMB non erano montati all’avvio dell’app.
Caso uno: il container funzionava, ma la dashboard non riusciva ad aprirlo
Un utente ha documentato una sequenza in quattro passaggi. Inizialmente, la dashboard mostrava l’app come arrestata, quindi avvisava che avrebbe potuto non essere disponibile. Il link proposto apriva una nuova finestra del browser, in cui l’applicazione funzionava normalmente. Anche incollare direttamente nel browser lo stesso indirizzo e la stessa porta funzionava.
Il team IceWhale ha considerato questo comportamento parte dell’indagine. La discussione non dimostra che la modifica di una policy di riavvio Docker risolva questo problema relativo allo stato visualizzato nella dashboard.
Caso due: aggiornamenti delle app e impostazioni non riusciti per un utente
Un altro partecipante che utilizzava la versione 1.4.3 ha segnalato brevi errori durante l’aggiornamento di Radarr e Sonarr e ha riferito che le modifiche alle impostazioni non venivano applicate. In quell’ambiente, reinstallare le app non è servito. In seguito, il partecipante ha dichiarato che la modifica dei mirror del registro consentiva nuovamente di modificare le impostazioni e, separatamente, ha ripristinato la proprietà delle cartelle delle app interessate in modo che corrispondesse all’UID 1000 configurato.
Si trattava di modifiche segnalate dagli utenti, non di una soluzione universale per ogni errore di riavvio. La modifica della configurazione del daemon Docker o il cambio ricorsivo della proprietà possono influire sull'intero host; pertanto, le prove della discussione non dovrebbero essere generalizzate oltre l'ambiente del partecipante.
Caso tre: lo storage SMB non era pronto quando i container si sono avviati
L'autore del post originale ha poi individuato una causa concreta per tre container. I relativi volumi erano mappati su una condivisione SMB. I log mostravano che i container tentavano di avviarsi prima che il filesystem SMB fosse disponibile, fallivano e rimanevano arrestati. Avviarli manualmente in seguito funzionava perché nel frattempo la condivisione era stata montata.
Questo spiega perché cambiare sempre a a meno che non venga arrestato non ha aiutato quei container: una policy di riavvio non può rendere disponibile prima un percorso di bind mount non disponibile. La dipendenza rilevante era la disponibilità dello storage e l'ordine di avvio.
Cosa ha confermato e cosa non ha confermato la versione 1.4.3
Una risposta di IceWhale ha chiesto agli utenti di testare la versione 1.4.3. Un partecipante ha dichiarato che il comportamento della dashboard persisteva, mentre l'autore del post originale inizialmente pensava che la versione 1.4.3 avesse aiutato, ma in seguito ha riprodotto il problema dell'ordine di avvio con SMB. Un'altra risposta ha osservato che un'app deve essere prima avviata affinché il servizio di gestione delle app conosca il suo ultimo stato di esecuzione.
Pertanto, la discussione non supporta l'affermazione generale secondo cui la versione 1.4.3 avrebbe risolto ogni problema di avvio della versione 1.4.2. Supporta invece una distinzione diagnostica: verificare innanzitutto se il container è davvero arrestato, quindi controllare i log e le dipendenze di archiviazione.
FAQ
Perché un'app si apre tramite URL ma risulta arrestata in ZimaOS?
Questo comportamento si è rivelato essere un problema di avvio della dashboard o di segnalazione dello stato. Il servizio poteva essere già in esecuzione e raggiungibile all'indirizzo e sulla porta configurati.
Perché dopo un riavvio non funzionano solo i container che utilizzano una condivisione SMB?
Nel caso confermato, quei container si avviavano prima che il montaggio SMB fosse pronto. Funzionavano quando venivano avviati manualmente dopo che la condivisione era diventata disponibile.
Cambiare la policy di riavvio di Docker ha risolto il problema?
No. L'autore del post originale ha testato entrambe le opzioni sempre sempre a meno che non venga arrestato senza risolvere i container interessati.
