Questa discussione della fonte porta a una conclusione fortemente legata alla versione. Dopo l'aggiornamento di ZimaBoard 832 a ZimaOS 1.4.3, Docker non riusciva ad avviarsi automaticamente, l'App Store non poteva installare nuove app e le app esistenti non potevano essere avviate. Zima-Giorgio ha dichiarato che il team era a conoscenza del problema del servizio Docker e ha fornito un comando temporaneo per il riavvio manuale.
L'autore del post originale ha confermato che il comando di riavvio aveva risolto il problema immediato, ma ha anche riferito che Docker falliva nuovamente dopo ogni riavvio dell'host. La versione successiva di IceWhale fornisce il dettaglio mancante: ZimaOS 1.4.4 ha corretto ufficialmente un errore di avvio di Docker causato da un intervallo di avvio del servizio insufficiente.
Il problema è comparso immediatamente dopo l'aggiornamento alla versione 1.4.3
L'utente della fonte ha segnalato:
- l'aggiornamento di Prowlarr rimaneva bloccato;
- le app esistenti non si avviavano;
- le nuove installazioni dall'App Store non riuscivano;
- l'interfaccia segnalava che non riusciva a connettersi al demone Docker.
/var/run/docker.sock, impedendo l'installazione e l'avvio delle applicazioni.IceWhale lo ha definito un problema noto del servizio Docker
Il 26 agosto, Zima-Giorgio ha scritto che il team considerava il problema del servizio Docker come noto e ha affermato che sarebbe stata rilasciata una correzione.
Ha fornito la soluzione temporanea ufficiale:
sudo -i
systemctl restart docker docker.socketQuesto comando è una indicazione storica valida di IceWhale per il caso relativo alla versione 1.4.3.
L'autore del post originale ha confermato che il riavvio manuale di Docker funzionava
L'utente ha risposto che il riavvio di Docker come root tramite la CLI ha risolto completamente il problema immediato. Si tratta di un successo confermato dalla fonte, non di una soluzione ipotetica.
Tuttavia, lo stesso utente ha poi riavviato ZimaBoard e ha scoperto che Docker non riusciva nuovamente ad avviarsi automaticamente.
La dashboard poteva mostrare le app come avviate quando Docker non funzionava correttamente
Il riavvio di Docker ha ripristinato lo stato reale dell'app
Il riavvio manuale delle app non ha risolto in modo affidabile il problema del riavvio successivo
Zima-Giorgio ha affermato che alcuni report suggerivano che avviare e riavviare manualmente ogni app potesse aiutare nei riavvii successivi. L'autore del post originale ha testato l'idea, ma dopo il riavvio ha continuato a riscontrare lo stesso stato di falso avvio.
Per questo è importante non presentare il riavvio delle singole app come la soluzione definitiva indicata nella fonte.
ZimaOS 1.4.4 ha risolto il problema dei tempi di avvio di Docker
Le note di rilascio ufficiali di IceWhale per la versione 1.4.4 includono:
- una correzione per le app che rimanevano nello stato di caricamento dopo l'avvio;
- una correzione per l'intervallo di avvio del servizio Docker, che era insufficiente e causava errori di avvio;
- correzioni aggiuntive relative allo stato delle applicazioni e alle schede di installazione.
Vedi le correzioni di ZimaOS 1.4.4 relative all'avvio di Docker per la soluzione storica del prodotto.
Gli utenti attuali non dovrebbero considerare systemctl restart una soluzione permanente
In una versione moderna di ZimaOS, un demone Docker che continua a non avviarsi dopo il riavvio indica un problema attuale relativo al servizio, allo spazio di archiviazione, al runtime o alla configurazione. Riavviare Docker può essere un'azione diagnostica, ma è necessario raccogliere la causa effettiva del problema prima di considerare normale un riavvio manuale a ogni avvio.
Le informazioni attuali utili includono:
-
systemctl status docker.service; -
journalctl -u docker.service; - spazio libero sul disco di sistema;
- override recenti relativi alla GPU/al runtime o modifiche all'host;
- l'esatta versione corrente di ZimaOS.
Un sintomo simile può avere una causa diversa
Un'altra discussione sulla versione 1.4.3 ha segnalato che Docker non si avviava perché un override personalizzato del runtime NVIDIA era ancora presente nella configurazione di systemd. Si tratta di una causa diversa dal problema dei tempi di avvio discusso in questo thread.
Non rimuovere i file di override dei servizi a meno che i log non mostrino che uno specifico override sta effettivamente causando il malfunzionamento del demone.
Domande frequenti sul demone Docker 1.4.3
IceWhale ha fornito ufficialmente un comando per il riavvio manuale di Docker?
Sì. Zima-Giorgio ha pubblicato systemctl restart docker docker.socket come soluzione temporanea nella versione 1.4.3.
L'utente della fonte ha confermato che funzionava?
Sì, per l'avvio corrente. Il problema è tornato dopo il riavvio.
Quale versione ha documentato la correzione a livello di prodotto del problema di avvio?
ZimaOS 1.4.4 ha risolto il problema dei tempi di avvio insufficienti del servizio Docker, che potevano causare un errore di avvio.
