Perché Immich si comporta diversamente dopo il riavvio di un container?

Immich cambia dopo un riavvio perché le cache temporanee scompaiono e le dipendenze dei servizi si riconnettono, mentre una persistenza configurata in modo errato può causare una perdita di stato più grave.

Una prima ricerca lenta può essere normale a freddo; una schermata di configurazione iniziale vuota non lo è. Classifica il sintomo in base a durata e ambito prima di modificare i dati, perché il riscaldamento della cache, un errore delle dipendenze e l’assenza di archiviazione persistente richiedono risposte completamente diverse.

Un riavvio rimuove lo stato temporaneo dei processi

I processi riavviati perdono i modelli in memoria, i pool di connessioni, i percorsi compilati e le cache dell’applicazione. La cache delle pagine dell’host può sopravvivere al riavvio di un container, ma il riavvio dell’host elimina ulteriore stato di riscaldamento. Di conseguenza, la prima richiesta di ricerca o della timeline può eseguire operazioni di inizializzazione che le ripetizioni immediate evitano.

Una misurazione della community riporta una prima ricerca intelligente lenta, seguita da ripetizioni molto più rapide mentre il modello di machine learning viene caricato nella memoria della GPU. I tempi esatti dipendono dal server, ma questa transizione di stato spiega perché una singola richiesta dopo il riavvio non possa rappresentare il funzionamento a regime.

Esegui tre volte la stessa richiesta nota e registra se la latenza converge. Se solo la prima richiesta è lenta e i risultati restano corretti, esamina il caricamento a freddo o i criteri di conservazione. Se ogni richiesta fallisce o lo stato sembra mancare, smetti di considerare il sintomo come un semplice riscaldamento della cache ed esamina dipendenze e persistenza.

L’ordine delle dipendenze può esporre una condizione di gara all’avvio

Immich dipende da più elementi del solo processo esposto sul web. Il database, il servizio di coordinamento dei processi, il servizio di machine learning e i supporti multimediali montati devono diventare raggiungibili con una configurazione compatibile. Un container contrassegnato come in esecuzione potrebbe essere ancora in fase di inizializzazione, quindi una richiesta precoce può fallire anche se lo stack diventa integro pochi istanti dopo.

Un rapporto su un errore dopo il riavvio descrive la perdita di accesso di Immich a PostgreSQL o Redis dopo modifiche apparentemente non correlate alla configurazione di Compose. Questo resoconto non dimostra un difetto generale del prodotto, ma illustra il valore diagnostico del mettere in relazione gli errori di connessione dell’applicazione con la disponibilità delle dipendenze e con la tempistica del riavvio.

Raccogli i log con marca temporale dell’applicazione e della dipendenza indicata, usando lo stesso riavvio come riferimento. Verifica la risoluzione DNS, la raggiungibilità delle porte, i controlli di integrità e la disponibilità dei mount all’interno del container. Se i tentativi automatici ripristinano il servizio, migliora la gestione della disponibilità; se il servizio non si ripristina mai, verifica direttamente configurazione e credenziali.

Lo stato persistente deve sopravvivere alla sostituzione del container

Le immagini e i file del database archiviati solo nel livello scrivibile di un container scompaiono quando il container viene sostituito. I volumi denominati e i bind mount persistono solo quando la distribuzione fa riferimento alla stessa posizione sottostante. Un semplice riavvio normalmente li conserva, ma le modifiche a Compose o ai percorsi possono selezionare silenziosamente un nuovo spazio di archiviazione vuoto.

L’articolo sul percorso dei dati di ZimaSpace spiega che un percorso visibile nel container non rivela lo spazio di archiviazione fisico o il dominio di errore sottostante. Questo è fondamentale dopo una ricreazione: lo stesso percorso interno può puntare a una directory host diversa, a un volume vuoto o a un mount di rete non disponibile.

Se Immich mostra la configurazione iniziale, non creare subito una libreria sostitutiva. Esamina i mount effettivi, gli identificatori dei volumi, la proprietà dei file e i log del database, quindi confrontali con l’ultima distribuzione funzionante. Le nuove scritture possono complicare il ripristino creando un secondo insieme di stato accanto a quello originale mancante.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Classifica il riavvio in cinque minuti

Al minuto zero, registra quali container sono stati riavviati e se sono cambiate immagini o configurazioni. Al minuto uno, controlla lo stato delle dipendenze e dei mount. Al minuto tre, ripeti una ricerca nota e un download già eseguito. Al minuto cinque, stabilisci se il comportamento sta migliorando, se il servizio è persistentemente indisponibile o se viene mostrato uno stato vuoto.

Un rapporto sulla persistenza del database descrive la visualizzazione ripetuta della configurazione iniziale dopo i riavvii di Compose, mentre la directory del database prevista sull’host restava vuota. Si tratta di un singolo ambiente, ma fornisce un chiaro indicatore di errore: la scomparsa dell’identità persistente dell’applicazione tra un riavvio e l’altro indica che il database viene scritto in una posizione diversa da quella persistente prevista.

Associa la latenza in miglioramento allo stato a freddo, gli errori di connessione all’avvio delle dipendenze, i contenuti multimediali mancanti ai mount e la perdita di utenti o album alla persistenza del database. Conserva i log e le mappature attuali dei volumi prima di apportare qualsiasi modifica. Avvia il ripristino solo dopo aver confermato che lo stato originale non è disponibile, anziché semplicemente disconnesso.