Warum verhält sich Immich nach einem Neustart des Containers anders?

Immich ändert sich nach einem Neustart, weil flüchtige Caches verschwinden und Dienstabhängigkeiten die Verbindung erneut herstellen, während eine falsch konfigurierte Persistenz schwerwiegenderen Zustandsverlust verursachen kann.

Eine langsame erste Suche kann bei einem Kaltstart normal sein; ein frischer Einrichtungsbildschirm ist es nicht. Ordnen Sie das Symptom anhand von Dauer und Umfang ein, bevor Sie Daten ändern, denn das Aufwärmen des Caches, ein Fehler bei Abhängigkeiten und fehlender persistenter Speicher erfordern völlig unterschiedliche Maßnahmen.

Ein Neustart entfernt den flüchtigen Prozesszustand

Neugestartete Prozesse verlieren Modelle im Arbeitsspeicher, Verbindungspools, kompilierte Pfade und Anwendungscaches. Der Seiten-Cache des Hosts kann einen Containerneustart überstehen, ein Neustart des Hosts entfernt jedoch noch mehr Aufwärmeffekte. Daher kann die erste Such- oder Zeitleistenanfrage Initialisierungsarbeit ausführen, die bei unmittelbar folgenden Wiederholungen entfällt.

Eine Messung aus der Community berichtet von einer langsamen ersten intelligenten Suche, auf die deutlich schnellere Wiederholungen folgen, während das Machine-Learning-Modell in den GPU-Speicher geladen wird. Das genaue Timing hängt von diesem Server ab, aber der Zustandsübergang erklärt, warum eine einzelne Anfrage nach dem Neustart keinen Rückschluss auf den Dauerbetrieb zulässt.

Führen Sie dieselbe bekannte Anfrage dreimal aus und protokollieren Sie, ob sich die Latenz einpendelt. Ist nur die erste Anfrage langsam und bleiben die Ergebnisse korrekt, untersuchen Sie das Kaltladen oder die Aufbewahrungsrichtlinie. Schlägt jede Anfrage fehl oder scheint der Zustand zu fehlen, behandeln Sie das Symptom nicht länger als Aufwärmen des Caches und prüfen Sie Abhängigkeiten und Persistenz.

Die Reihenfolge der Abhängigkeiten kann einen Startwettlauf sichtbar machen

Immich hängt von mehr als dem webbasierten Prozess ab. Die Datenbank, die Auftragskoordination, der Machine-Learning-Dienst und die eingebundenen Medien müssen mit kompatibler Konfiguration erreichbar werden. Ein als laufend markierter Container kann noch initialisiert werden, sodass eine frühe Anfrage fehlschlagen kann, obwohl der Stack wenige Augenblicke später fehlerfrei ist.

Ein Bericht über einen Neustartfehler beschreibt, dass Immich nach scheinbar unabhängigen Compose-Änderungen den Zugriff auf PostgreSQL oder Redis verlor. Dieser Bericht belegt keinen produktweiten Fehler, zeigt aber, wie hilfreich es für die Diagnose ist, Anwendungsfehler bei Verbindungen mit der Bereitschaft der Abhängigkeiten und dem Zeitpunkt des Neustarts abzugleichen.

Sammeln Sie zeitgestempelte Protokolle der Anwendung und der genannten Abhängigkeit aus demselben Neustart. Prüfen Sie die DNS-Auflösung, die Erreichbarkeit des Ports, die Zustandsprüfungen und die Verfügbarkeit der Einbindungen innerhalb des Containers. Stellt sich der Dienst durch automatische Wiederholungen wieder her, verbessern Sie die Bereitschaftsbehandlung; stellt er sich nicht wieder her, testen Sie Konfiguration und Zugangsdaten direkt.

Persistenter Zustand muss den Austausch von Containern überstehen

Images und Datenbankdateien, die ausschließlich in einer beschreibbaren Containerschicht gespeichert sind, verschwinden, wenn dieser Container ersetzt wird. Benannte Volumes und Bind-Mounts bleiben nur erhalten, wenn die Bereitstellung auf denselben zugrunde liegenden Speicherort verweist. Ein einfacher Neustart bewahrt sie normalerweise, doch Änderungen an Compose oder Pfadänderungen können unbemerkt neuen, leeren Speicher auswählen.

Der Artikel zum Datenpfad von ZimaSpace erklärt, dass ein sichtbarer Containerpfad weder den physischen Speicherort noch die dahinterliegende Fehlerdomäne erkennen lässt. Das ist nach einer Neuerstellung entscheidend: Ein identischer interner Pfadname kann auf ein anderes Hostverzeichnis, ein leeres Volume oder einen nicht verfügbaren Netzwerkspeicher verweisen.

Wenn Immich die Ersteinrichtung anzeigt, erstellen Sie nicht sofort eine Ersatzbibliothek. Prüfen Sie die tatsächlich wirksamen Einbindungen, Volume-Kennungen, Besitzrechte und Datenbankprotokolle und vergleichen Sie sie anschließend mit der letzten funktionierenden Bereitstellung. Neue Schreibvorgänge können die Wiederherstellung erschweren, indem sie neben dem fehlenden Original einen zweiten Zustandsbestand anlegen.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Ordnen Sie den Neustart in fünf Minuten ein

Halten Sie bei Minute null fest, welche Container neu gestartet wurden und ob Images oder Konfiguration geändert wurden. Prüfen Sie bei Minute eins den Zustand der Abhängigkeiten und die Einbindungen. Wiederholen Sie bei Minute drei eine bekannte Suche und einen ursprünglichen Download. Entscheiden Sie bei Minute fünf, ob sich das Verhalten verbessert, der Dienst dauerhaft nicht verfügbar ist oder ein leerer Zustand angezeigt wird.

Ein Bericht zur Datenbankpersistenz beschreibt wiederholte Einrichtungsbildschirme nach Compose-Neustarts, während das erwartete Datenbankverzeichnis auf dem Host leer blieb. Es handelt sich um eine einzelne Umgebung, dennoch zeigt sie ein klares Fehlersymptom: Wenn die dauerhafte Anwendungsidentität nach einem Neustart verschwindet, wird die Datenbank an einem anderen Ort als dem vorgesehenen persistenten Pfad beschrieben.

Ordnen Sie sich verbessernde Latenz einem Kaltstartzustand zu, Verbindungsfehlern dem Start von Abhängigkeiten, fehlende Medien den Einbindungen und verlorene Benutzer oder Alben der Datenbankpersistenz. Sichern Sie Protokolle und die aktuellen Volume-Zuordnungen, bevor Sie Änderungen vornehmen. Beginnen Sie eine Wiederherstellung erst, nachdem Sie bestätigt haben, dass der ursprüngliche Zustand nicht verfügbar und nicht lediglich getrennt ist.