Dieser Quellthread führt zu einem klaren versionsspezifischen Ergebnis. Nach dem Upgrade eines ZimaBoard 832 auf ZimaOS 1.4.3 startete Docker nicht automatisch, der App Store konnte keine neuen Apps installieren und vorhandene Apps konnten nicht gestartet werden. Zima-Giorgio erklärte, dass das Team von dem Problem mit dem Docker-Dienst wusste, und stellte einen vorübergehenden manuellen Neustartbefehl bereit.
Der ursprüngliche Beitragende bestätigte, dass der Neustartbefehl das unmittelbare Problem behoben hatte, berichtete jedoch auch, dass Docker nach jedem Neustart des Hosts erneut ausfiel. Die nächste Veröffentlichung von IceWhale liefert die fehlende Einordnung: ZimaOS 1.4.4 behob offiziell einen Docker-Startfehler, der durch ein unzureichendes Dienststartintervall verursacht wurde.
Der Fehler trat unmittelbar nach dem Upgrade auf Version 1.4.3 auf
Der Benutzer aus der Quelle berichtete:
- Das Update von Prowlarr blieb hängen;
- Vorhandene Apps wurden nicht gestartet;
- Neue Installationen aus dem App Store schlugen fehl;
- Die Benutzeroberfläche meldete, dass keine Verbindung zum Docker-Daemon hergestellt werden konnte.
/var/run/docker.sockund verhinderte die Installation und den Start von Anwendungen.IceWhale bezeichnete es als bekanntes Problem des Docker-Dienstes
Am 26. August schrieb Zima-Giorgio, dass das Team das Problem als bekanntes Problem des Docker-Dienstes betrachte und eine Lösung veröffentlicht werde.
Er nannte die vorübergehende offizielle Behelfslösung:
sudo -i
systemctl restart docker docker.socketDieser Befehl entspricht den historischen offiziellen Anweisungen von IceWhale für den Ausgangsfall mit Version 1.4.3.
Der ursprüngliche Beitragende bestätigte, dass der manuelle Docker-Neustart funktioniert hat
Der Benutzer antwortete, dass der Neustart von Docker als Root über die CLI das unmittelbare Problem vollständig behoben habe. Das ist ein durch die Quelle bestätigter Erfolg und keine spekulative Behelfslösung.
Der Benutzer startete anschließend das ZimaBoard neu und stellte fest, dass Docker erneut nicht automatisch gestartet wurde.
Das Dashboard konnte Apps als gestartet anzeigen, obwohl Docker nicht ordnungsgemäß funktionierte
Ein Docker-Neustart stellte den tatsächlichen App-Zustand wieder her
Ein manueller Neustart der Apps behob den nächsten Neustart nicht zuverlässig
Zima-Giorgio sagte, einige Berichte deuteten darauf hin, dass das manuelle Starten und Neustarten jeder App das Verhalten bei künftigen Neustarts verbessern könnte. Der ursprüngliche Verfasser testete diese Idee, sah nach dem Neustart jedoch weiterhin denselben falschen Startstatus.
Daher ist es wichtig, den Neustart einzelner Apps nicht als endgültige Lösung des ursprünglichen Problems darzustellen.
ZimaOS 1.4.4 behob das Problem mit dem Docker-Startzeitpunkt
Zu den offiziellen Release-Hinweisen von IceWhale für Version 1.4.4 gehören:
- eine Korrektur für Apps, die nach dem Start im Ladezustand verblieben;
- eine Korrektur für ein unzureichendes Startintervall des Docker-Dienstes, das zu einem Startfehler führte;
- zusätzliche Korrekturen für den Anwendungsstatus und Installationskarten.
Siehe die Docker-Startkorrekturen in ZimaOS 1.4.4 für die historische produktseitige Lösung.
Aktuelle Nutzer sollten systemctl restart nicht als dauerhafte Lösung betrachten
Bei einer modernen ZimaOS-Version weist ein Docker-Daemon, der nach einem Neustart wiederholt fehlschlägt, auf ein aktuelles Problem mit dem Dienst, dem Speicher, der Runtime oder der Konfiguration hin. Ein Neustart von Docker kann der Diagnose dienen, aber ermittle zunächst den tatsächlichen Fehler, bevor du einen manuellen Neustart bei jedem Systemstart zur Standardlösung machst.
Nützliche aktuelle Informationen umfassen:
-
systemctl status docker.service; -
journalctl -u docker.service; - freier Speicherplatz auf der Systemfestplatte;
- kürzlich vorgenommene GPU-/Runtime-Overrides oder Änderungen am Host;
- die aktuell genaue ZimaOS-Version.
Ein ähnliches Symptom kann eine andere Grundursache haben
In einer weiteren Diskussion zu Version 1.4.3 wurde berichtet, dass Docker aufgrund eines benutzerdefinierten NVIDIA-Runtime-Overrides in der systemd-Konfiguration fehlschlug. Das ist eine andere Ursache als das Startzeitproblem in diesem Quellthread.
Entferne Service-Override-Dateien nicht, es sei denn, die Protokolle zeigen, dass ein bestimmtes Override den Daemon tatsächlich beeinträchtigt.
FAQ zum Docker-Daemon in Version 1.4.3
Hat IceWhale offiziell einen manuellen Docker-Neustart bereitgestellt?
Ja. Zima-Giorgio veröffentlichte systemctl restart docker docker.socket als vorübergehende Problemumgehung in Version 1.4.3.
Bestätigte der ursprüngliche Nutzer, dass es funktioniert hatte?
Ja, für den aktuellen Systemstart. Nach dem Neustart trat der Fehler erneut auf.
In welchem Release wurde die produktseitige Startkorrektur dokumentiert?
ZimaOS 1.4.4 behob eine unzureichende Startverzögerung des Docker-Dienstes, die zu einem Startfehler führen konnte.
