Der Thread enthielt mehr als ein Problem beim App-Start
Nach dem Upgrade von ZimaOS 1.4.1 auf 1.4.2 stellte der ursprüngliche Verfasser fest, dass einige Apps, darunter Portainer, offenbar nicht automatisch gestartet wurden. Docker-Neustartrichtlinien wie unless-stopped und always änderte das sichtbare Ergebnis nicht, während ein Klick auf die App im Dashboard sie startete.
Andere Nutzer berichteten anschließend von verwandten, aber unterschiedlichen Symptomen. Eine Gruppe stellte fest, dass Container über ihre direkte Webadresse bereits erreichbar waren, während das ZimaOS-Dashboard so tat, als wären sie angehalten. Ein anderer Nutzer bestätigte später, dass ausgewählte Container tatsächlich fehlschlugen, weil ihre von SMB bereitgestellten Volume-Pfade beim Start der Apps nicht eingebunden waren.
Fall eins: Der Container funktionierte, aber das Dashboard konnte ihn nicht öffnen
Ein Nutzer dokumentierte einen Ablauf in vier Schritten. Das Dashboard zeigte die App zunächst als angehalten an und warnte anschließend, dass sie möglicherweise nicht verfügbar sei. Über den angebotenen Link wurde ein neues Browserfenster geöffnet, in dem die Anwendung normal funktionierte. Auch das direkte Einfügen derselben Adresse und desselben Ports in den Browser funktionierte.
Das IceWhale-Team behandelte dieses Verhalten als Teil der Untersuchung. Der Thread belegt nicht, dass eine Änderung der Docker-Neustartrichtlinie dieses Dashboard-Statusproblem behebt.
Fall zwei: App-Aktualisierungen und Einstellungen schlugen bei einem Nutzer fehl
Ein weiterer Teilnehmer mit Version 1.4.3 berichtete von kurzzeitig angezeigten Fehlern beim Aktualisieren von Radarr und Sonarr und erklärte, dass Einstellungsänderungen nicht übernommen wurden. Eine Neuinstallation der Apps half in dieser Umgebung nicht. Später teilte der Teilnehmer mit, dass Änderungen an Registry-Spiegeln die Übernahme von Einstellungsänderungen wieder ermöglichten, und stellte separat die Eigentümerschaft der relevanten App-Ordner wieder auf die konfigurierte UID 1000 zurück.
Dies waren von Nutzern gemeldete Änderungen und keine universelle Lösung für jeden Fehler beim Neustart. Das Bearbeiten der Docker-Daemon-Konfiguration oder das rekursive Ändern von Besitzrechten kann den gesamten Host beeinflussen. Daher sollte die Evidenz aus dem Thread nicht über die Umgebung des Teilnehmers hinaus verallgemeinert werden.
Fall drei: Der SMB-Speicher war beim Start der Container nicht bereit
Der ursprüngliche Verfasser ermittelte später eine konkrete Ursache für drei Container. Ihre Volumes waren einer SMB-Freigabe zugeordnet. Die Protokolle zeigten, dass die Container starten wollten, bevor das SMB-Dateisystem verfügbar war, fehlschlugen und anschließend heruntergefahren blieben. Ein späterer manueller Start funktionierte, weil die Freigabe zu diesem Zeitpunkt bereits eingebunden war.
Das erklärt, warum das Ändern always zu unless-stopped half diesen Containern nicht: Eine Neustartrichtlinie kann einen nicht verfügbaren Pfad für einen Bind-Mount nicht früher verfügbar machen. Die relevante Abhängigkeit waren die Speicherbereitschaft und die Startreihenfolge.
Was Version 1.4.3 bestätigt und nicht bestätigt hat
Eine Antwort von IceWhale bat die Nutzer, 1.4.3 zu testen. Ein Teilnehmer sagte, dass das Dashboard-Verhalten weiterhin bestand, während der ursprüngliche Verfasser zunächst dachte, 1.4.3 habe geholfen, später jedoch den SMB-Fehler in der Startreihenfolge reproduzierte. Eine weitere Antwort wies darauf hin, dass eine App zunächst gestartet werden muss, damit der App-Verwaltungsdienst ihren letzten Laufstatus kennt.
Der Thread stützt daher nicht die pauschale Aussage, dass 1.4.3 jedes Startproblem von 1.4.2 behoben hat. Er unterstützt eine diagnostische Unterscheidung: Prüfen Sie zuerst, ob der Container tatsächlich gestoppt ist, und untersuchen Sie anschließend seine Protokolle und Speicherabhängigkeiten.
FAQ
Warum lässt sich eine App über die URL öffnen, wird in ZimaOS aber als gestoppt angezeigt?
Dieses Muster erwies sich als Problem beim Starten über das Dashboard oder bei der Statusanzeige. Der Dienst selbst konnte bereits unter der konfigurierten Adresse und dem konfigurierten Port laufen und erreichbar sein.
Warum schlagen nach einem Neustart nur Container fehl, die eine SMB-Freigabe verwenden?
Im bestätigten Fall wurden die Container gestartet, bevor der SMB-Mount bereit war. Nachdem die Freigabe verfügbar war, funktionierten sie bei einem manuellen Start.
Hat das Ändern der Docker-Neustartrichtlinie das Problem behoben?
Nein. Der ursprüngliche Verfasser hat beide getestet. always und unless-stopped ohne die betroffenen Container neu zu erstellen.
