De thread bevatte meer dan één probleem met het starten van apps
Na de upgrade van ZimaOS 1.4.1 naar 1.4.2 ontdekte de oorspronkelijke poster dat sommige apps, waaronder Portainer, niet automatisch leken te starten. Docker-herstartbeleid zoals tenzij-gestopt en altijd veranderde het zichtbare resultaat niet, terwijl het klikken op de app in het dashboard deze startte.
Andere gebruikers meldden vervolgens gerelateerde maar verschillende symptomen. Eén groep ontdekte dat containers al bereikbaar waren via hun rechtstreekse webadres, terwijl het ZimaOS-dashboard deed alsof ze gestopt waren. Een andere gebruiker bevestigde later dat geselecteerde containers daadwerkelijk niet werkten omdat hun SMB-ondersteunde volumepaden niet waren gekoppeld toen het opstarten van de app plaatsvond.
Geval één: de container werkte, maar het dashboard kon deze niet openen
Eén gebruiker documenteerde een reeks van vier stappen. Het dashboard toonde de app eerst als gestopt en waarschuwde daarna dat deze mogelijk niet beschikbaar was. Via de aangeboden link werd een nieuw browservenster geopend waarin de applicatie normaal werkte. Het rechtstreeks plakken van hetzelfde adres en dezelfde poort in de browser werkte eveneens.
Het IceWhale-team beschouwde dit gedrag als onderdeel van het onderzoek. De thread stelt niet vast dat het wijzigen van een Docker-herstartbeleid dit probleem met de dashboardstatus oplost.
Geval twee: app-updates en instellingen mislukten voor één gebruiker
Een andere deelnemer die versie 1.4.3 gebruikte, meldde korte fouten tijdens het bijwerken van Radarr en Sonarr en zei dat wijzigingen in de instellingen niet werden toegepast. Het opnieuw installeren van de apps hielp niet in die omgeving. Later zei de deelnemer dat het wijzigen van registerspiegels ervoor zorgde dat instellingen weer konden worden gewijzigd, en herstelde hij afzonderlijk het eigenaarschap van relevante app-mappen zodat dit overeenkwam met de geconfigureerde UID 1000.
Dit waren door gebruikers gemelde wijzigingen, geen universele oplossing voor elke herstartfout. Het aanpassen van de Docker-daemonconfiguratie of het recursief wijzigen van eigenaarschap kan gevolgen hebben voor de hele host. De threadgegevens mogen daarom niet buiten de omgeving van de deelnemer worden veralgemeniseerd.
Geval drie: SMB-opslag was niet gereed toen de containers startten
De oorspronkelijke poster identificeerde later een concrete oorzaak voor drie containers. Hun volumes waren gekoppeld aan een SMB-share. Uit de logs bleek dat de containers probeerden te starten voordat het SMB-bestandssysteem beschikbaar was, waarna ze faalden en uitgeschakeld bleven. Ze later handmatig starten werkte wel, omdat de share toen al was gekoppeld.
Dit verklaart waarom het wijzigen van altijd naar tenzij-gestopt hielp die containers niet: een herstartbeleid kan een niet-beschikbaar pad voor een bind-mount niet eerder gereed maken. De relevante afhankelijkheid was de gereedheid van de opslag en de opstartvolgorde.
Wat versie 1.4.3 wel en niet bevestigde
Een antwoord van IceWhale vroeg gebruikers om 1.4.3 te testen. Een deelnemer zei dat het dashboardgedrag bleef bestaan, terwijl de oorspronkelijke poster aanvankelijk dacht dat 1.4.3 had geholpen, maar later het probleem met de SMB-opstartvolgorde opnieuw reproduceerde. Een ander antwoord merkte op dat een app eerst moet worden gestart voordat de app-beheerservice weet wat de laatst actieve status was.
De thread ondersteunt daarom niet de algemene bewering dat 1.4.3 elk opstartprobleem van 1.4.2 heeft opgelost. De thread ondersteunt wel een diagnostisch onderscheid: controleer eerst of de container echt gestopt is en bekijk daarna de logs en opslagafhankelijkheden.
Veelgestelde vragen
Waarom opent een app via de URL, maar lijkt deze in ZimaOS gestopt?
Dat patroon bleek een probleem met het starten vanuit het dashboard of met de statusrapportage. De service zelf kon al actief en bereikbaar zijn op het geconfigureerde adres en de geconfigureerde poort.
Waarom werken na een herstart alleen containers die een SMB-share gebruiken niet?
In het bevestigde geval startten die containers voordat de SMB-koppeling gereed was. Ze werkten wel wanneer ze handmatig werden gestart nadat de share beschikbaar was.
Heeft het wijzigen van het Docker-herstartbeleid het probleem opgelost?
Nee. De oorspronkelijke poster heeft beide getest altijd en tenzij-gestopt zonder de getroffen containers opnieuw te starten.
