Varför beter sig Immich annorlunda efter en omstart av containern?
Immich förändras efter en omstart eftersom tillfälliga cachelagringar försvinner och tjänsteberoenden återansluter, medan felaktigt konfigurerad beständig lagring kan orsaka allvarligare dataförlust.
En långsam första sökning kan vara normalt kallstartsbeteende; en ny introduktionsskärm är det inte. Klassificera symtomet utifrån varaktighet och omfattning innan du ändrar data, eftersom uppvärmning av cache, beroendefel och saknad beständig lagring kräver helt olika åtgärder.
En omstart tar bort tillfälligt processtillstånd
Omstartade processer förlorar modeller i minnet, anslutningspooler, kompilerade sökvägar och programcache. Värdens sidcache kan finnas kvar efter en omstart av containern, men en omstart av värddatorn tar bort ännu mer av uppvärmningen. Därför kan den första sökningen eller tidslinjebegäran behöva utföra initieringsarbete som efterföljande upprepningar slipper.
En mätning från communityn rapporterar en långsam första smart sökning följd av betydligt snabbare upprepningar medan maskininlärningsmodellen läses in i GPU-minnet. Den exakta tidsåtgången beror på servern, men tillståndsövergången förklarar varför en enda begäran efter omstart inte kan representera normal drift.
Kör samma kända begäran tre gånger och notera om svarstiden stabiliseras. Om bara den första begäran är långsam och resultaten förblir korrekta bör du undersöka kall inläsning eller lagringspolicy. Om varje begäran misslyckas eller tillstånd verkar saknas bör du sluta behandla symtomet som cacheuppvärmning och undersöka beroenden och beständig lagring.
Beroendeordningen kan blottlägga en startkapplöpning
Immich är beroende av mer än den webbvända processen. Databasen, jobbkoordineringen, maskininlärningstjänsten och de monterade medierna måste bli nåbara med kompatibel konfiguration. En container som är markerad som körande kan fortfarande initieras, så en tidig begäran kan misslyckas även om stacken blir frisk några ögonblick senare.
En rapport om ett omstartsfel beskriver hur Immich förlorade åtkomsten till PostgreSQL eller Redis efter till synes orelaterade compose-ändringar. Rapporten fastställer inte ett produktomfattande fel, men illustrerar värdet av att koppla programmets anslutningsfel till beroendenas beredskap och tidpunkten för omstarten.
Samla tidsstämplade loggar från programmet och det namngivna beroendet under samma omstart. Kontrollera DNS-upplösning, portåtkomst, hälsokontroller och tillgång till monteringar inifrån containern. Om automatiska återförsök återställer tjänsten bör du förbättra hanteringen av beredskap; om den aldrig återhämtar sig bör du testa konfiguration och inloggningsuppgifter direkt.
Beständigt tillstånd måste överleva när containrar ersätts
Avbildningar och databasfiler som endast lagras i containerns skrivbara lager försvinner när containern ersätts. Namngivna volymer och bindmonteringar är beständiga endast när distributionen hänvisar till samma underliggande plats. En enkel omstart bevarar dem normalt, men compose-redigeringar eller sökvägsändringar kan omärkligt välja en ny tom lagring.
Artikeln om ZimaSpace datasökvägen förklarar att en synlig containersökväg inte avslöjar den fysiska lagringen eller felgränsen bakom den. Detta är avgörande efter återskapande: en identisk intern sökväg kan peka på en annan värddatorkatalog, en tom volym eller en otillgänglig nätverksmontering.
Om Immich visar den första introduktionen bör du inte omedelbart skapa ett ersättningsbibliotek. Kontrollera de faktiska monteringspunkterna, volymidentifierarna, ägarskapet och databasloggarna och jämför dem sedan med den senast fungerande distributionen. Nya skrivningar kan försvåra återställningen genom att skapa en andra uppsättning tillstånd bredvid den saknade ursprungliga.
Använd en femminutersklassificering efter omstart
Vid minut noll noterar du vilka containrar som startade om och om avbildningar eller konfiguration ändrades. Vid minut ett kontrollerar du beroendenas hälsa och monteringar. Vid minut tre upprepar du en känd sökning och en ursprunglig nedladdning. Vid minut fem avgör du om beteendet förbättras, om tjänsten fortfarande är otillgänglig eller om ett tomt tillstånd visas.
En rapport om databasens beständighet beskriver hur introduktionen visades på nytt efter compose-omstarter medan den förväntade databas katalogen på värden förblev tom. Det gäller en enda miljö, men ger en tydlig felsignatur: om beständig programidentitet försvinner efter en omstart skrivs databasen till någon annan plats än den avsedda beständiga sökvägen.
Koppla förbättrad svarstid till kallt tillstånd, anslutningsfel till beroendenas uppstart, saknade medier till monteringar och förlorade användare eller album till databasens beständighet. Bevara loggar och de aktuella volymmappningarna innan du gör någon ändring. Påbörja återställning först efter att du har bekräftat att det ursprungliga tillståndet saknas, snarare än att det bara är frånkopplat.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Vad är Immichs tillstånd, och vilka delar måste bevaras?
Immich-tillståndet omfattar original, databasrelationer, identitet, konfiguration och härledda filer; bevara varje del utifrån om den kan återskapas.
Hur hanterar Immich autentisering för lokala och fjärranslutna sessioner?
Immich använder serverbaserad identitet med klientsessioner, medan proxyhuvuden, ursprung och OIDC-omdirigeringar kan göra att lokalt och på distans beter sig olika.
Vad gör att Immichs sökningar eller frågeresultat blir långsammare när datamängden växer?
Immich-tillväxt kan göra index större, tränga undan ofta använda sidor, komplicera filter och fördröja mediedistributionen; separera dessa steg innan du finjusterar.
