Gemenskapslösning

Varför ZimaOS-appar inte startade om efter omstart i versionerna 1.4.2 och 1.4.3

After updating to ZimaOS 1.4.2, users reported apps that appeared stopped, failed to open from the dashboard, or could not start before SMB storage mounted.

Tråden innehöll mer än ett problem med appstart

Efter uppgradering från ZimaOS 1.4.1 till 1.4.2 upptäckte den ursprungliga skribenten att vissa appar, däribland Portainer, inte verkade starta automatiskt. Docker-omstartspolicyer som om den inte stoppas och alltid ändrade inte det synliga resultatet, medan ett klick på appen i instrumentpanelen startade den.

Andra användare rapporterade sedan relaterade men skilda symtom. En grupp upptäckte att containrarna redan kunde nås via sina direkta webbadresser medan ZimaOS-instrumentpanelen betedde sig som om de var stoppade. En annan grupp bekräftade senare att vissa valda containrar faktiskt inte fungerade eftersom deras SMB-baserade volymsökvägar inte var monterade när appstarten skedde.

Fall ett: Containern fungerade, men instrumentpanelen kunde inte öppna den

En användare dokumenterade ett förlopp i fyra steg. Instrumentpanelen visade först appen som stoppad och varnade sedan för att den kanske inte var tillgänglig. När den erbjudna länken följdes öppnades ett nytt webbläsarfönster där applikationen fungerade normalt. Det fungerade också att klistra in samma adress och port direkt i webbläsaren.

ZimaOS-appens startskärm visades trots att containern redan kördes
Instrumentpanelen började med en appstartskärm trots att tjänsten gick att nå direkt.
ZimaOS-varning om att en applikation kanske inte är tillgänglig
Instrumentpanelen visade sedan en tillgänglighetsvarning och en alternativ länk.
Webbläsarfönster öppnat från ZimaOS-appens varning
Den alternativa länken öppnade ett separat webbläsarfönster.
Fungerande applikationsgränssnitt nåddes utanför ZimaOS-instrumentpanelen
Själva applikationen var tillgänglig, även om instrumentpanelens startflöde var missvisande.

IceWhale-teamet behandlade detta beteende som en del av utredningen. Tråden fastställer inte att ändring av en Docker-omstartspolicy löser problemet med instrumentpanelens tillstånd.

Fall två: Appuppdateringar och inställningar misslyckades för en användare

En annan deltagare som körde 1.4.3 rapporterade kortvariga fel vid uppdatering av Radarr och Sonarr och sade att inställningsändringarna inte hade tillämpats. Ominstallation av apparna hjälpte inte i den miljön. Deltagaren sade senare att byte av registerspeglingsservrar gjorde att inställningsändringar kunde tillämpas igen och återställde separat ägarskapet för relevanta appmappar så att det överensstämde med det konfigurerade UID:t 1000.

Kontroll för uppdatering av ZimaOS-applikationer, visad i det rapporterade inställningsproblemet
Användaren dokumenterade appuppdateringsförloppet innan hen fångade de kortvariga felen.
Kort Radarr-uppdateringsfel visades i ZimaOS
Radarr-felet syntes i endast ungefär en sekund.
Kortvarigt Sonarr-uppdateringsfel som visades i ZimaOS
Ett liknande tillfälligt fel uppstod vid uppdatering av Sonarr.
Mappmappningar på värdsystemet för Radarr, visade av en medlem i IceWhale-teamet
Teamet bad användarna att bevara konsekventa mappmappningar på värdsystemet när appar installeras om eller testas.
Radarrs mappinställningar efter att behörigheterna återställts för UID 1000
Deltagaren återställde ägarskapet för de relevanta mapparna till det UID som konfigurerats i appen.

Detta var ändringar som rapporterades av användare, inte en universell lösning för alla omstartsproblem. Att redigera Dockers daemon-konfiguration eller ändra ägarskap rekursivt kan påverka hela värdsystemet, så bevisen i tråden bör inte generaliseras utanför deltagarens miljö.

Fall tre: SMB-lagringen var inte klar när containrarna startade

Ursprungsskribaren identifierade senare en konkret orsak för tre containrar. Deras volymer var mappade till en SMB-resurs. Loggarna visade att containrarna försökte starta innan SMB-filsystemet var tillgängligt, misslyckades och förblev avstängda. Att starta dem manuellt senare fungerade eftersom resursen då hade monterats.

Detta förklarar varför ändring av alltid till om den inte stoppas hjälpte inte dessa containrar: en omstartspolicy kan inte göra en otillgänglig sökväg för bind-montering tillgänglig tidigare. Det relevanta beroendet var lagringens tillgänglighet och startordningen.

Vad version 1.4.3 bekräftade och inte bekräftade

Ett svar från IceWhale bad användarna att testa 1.4.3. En deltagare sade att instrumentpanelens beteende kvarstod, medan ursprungsskribaren först trodde att 1.4.3 hjälpte men senare återskapade SMB-problemet med startordningen. Ett annat svar påpekade att en app först måste startas så att apphanteringstjänsten känner till dess senaste körstatus.

Tråden ger därför inte stöd för ett generellt påstående att 1.4.3 löste alla startproblem i 1.4.2. Den stöder i stället en diagnostisk uppdelning: kontrollera först om containern verkligen är stoppad och granska sedan dess loggar och lagringsberoenden.

Vanliga frågor

Varför öppnas en app via URL men ser ut att vara stoppad i ZimaOS?

Det mönstret visade sig vara ett problem med att starta från instrumentpanelen eller rapportera status. Själva tjänsten kunde redan vara igång och nåbar på den konfigurerade adressen och porten.

Varför misslyckas endast containrar som använder en SMB-resurs efter omstart?

I det bekräftade fallet startade containrarna innan SMB-monteringen var klar. De fungerade när de startades manuellt efter att resursen blivit tillgänglig.

Löste det problemet att ändra Dockers omstartspolicy?

Nej. Ursprungsskribenten testade båda alltid och om den inte stoppas utan att lösa problemen med de berörda containrarna.