Pourquoi Immich se comporte-t-il différemment après le redémarrage d’un conteneur ?

Immich change après un redémarrage, car les caches temporaires disparaissent et les dépendances des services se reconnectent, tandis qu’une persistance mal configurée peut révéler une perte d’état plus grave.

Une première recherche lente peut être normale à froid ; un écran d’intégration initiale ne l’est pas. Classez le symptôme selon sa durée et son étendue avant de modifier les données, car la mise en cache progressive, la défaillance d’une dépendance et l’absence de stockage persistant nécessitent des réponses complètement différentes.

Un redémarrage supprime l’état temporaire des processus

Les processus redémarrés perdent les modèles en mémoire, les pools de connexions, les chemins compilés et les caches applicatifs. Le cache de pages de l’hôte peut survivre au redémarrage d’un conteneur, mais le redémarrage de l’hôte supprime davantage de données préchargées. Par conséquent, la première recherche ou requête de chronologie peut effectuer un travail d’initialisation que les répétitions immédiates évitent.

Une mesure réalisée par la communauté fait état d’une première recherche intelligente lente, suivie de répétitions beaucoup plus rapides pendant le chargement du modèle d’apprentissage automatique dans la mémoire du GPU. Le délai exact dépend du serveur concerné, mais cette transition d’état explique pourquoi une seule requête après redémarrage ne peut pas représenter le fonctionnement normal.

Exécutez trois fois la même requête connue et notez si la latence converge. Si seule la première requête est lente et que les résultats restent corrects, recherchez un chargement à froid ou une stratégie de rétention. Si chaque requête échoue ou si l’état semble absent, cessez d’attribuer le symptôme à la mise en cache progressive et examinez les dépendances et la persistance.

L’ordre de démarrage des dépendances peut révéler une course au démarrage

Immich dépend de plusieurs éléments, et pas uniquement du processus exposé sur le Web. La base de données, la coordination des tâches, le service d’apprentissage automatique et les supports de stockage montés doivent être accessibles avec une configuration compatible. Un conteneur indiqué comme actif peut encore être en cours d’initialisation ; une requête précoce peut donc échouer même si la pile devient saine quelques instants plus tard.

Un rapport d’échec après redémarrage décrit une perte d’accès d’Immich à PostgreSQL ou Redis après des modifications apparemment indépendantes dans Compose. Ce témoignage ne prouve pas l’existence d’un défaut généralisé du produit, mais il illustre l’intérêt diagnostique de mettre en parallèle les erreurs de connexion de l’application, l’état de préparation des dépendances et le moment du redémarrage.

Rassemblez les journaux horodatés de l’application et de la dépendance concernée à partir du même redémarrage. Vérifiez la résolution DNS, l’accessibilité des ports, les contrôles d’état et la disponibilité des montages depuis l’intérieur du conteneur. Si les nouvelles tentatives automatiques rétablissent le service, améliorez la gestion de la disponibilité ; si le service ne revient jamais, testez directement la configuration et les identifiants.

L’état persistant doit survivre au remplacement du conteneur

Les images et les fichiers de base de données stockés uniquement dans la couche inscriptible d’un conteneur disparaissent lorsque celui-ci est remplacé. Les volumes nommés et les montages de répertoires ne persistent que si le déploiement référence le même emplacement sous-jacent. Un simple redémarrage les préserve généralement, mais des modifications de Compose ou de chemin peuvent sélectionner silencieusement un nouveau stockage vide.

L’article sur le chemin des données de ZimaSpace explique qu’un chemin visible dans le conteneur ne révèle ni le stockage physique ni le domaine de défaillance situés derrière. C’est essentiel après une recréation : un chemin interne identique peut pointer vers un autre répertoire de l’hôte, un volume vide ou un montage réseau indisponible.

Si Immich affiche l’écran d’intégration initiale, ne créez pas immédiatement une bibliothèque de remplacement. Inspectez les montages effectifs, les identifiants de volume, les propriétaires et les journaux de la base de données, puis comparez-les avec ceux du dernier déploiement fonctionnel. De nouvelles écritures peuvent compliquer la récupération en créant un second ensemble d’états à côté de l’original manquant.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Classez le redémarrage en cinq minutes

À la minute zéro, notez quels conteneurs ont redémarré et si les images ou la configuration ont changé. À la première minute, vérifiez l’état des dépendances et les montages. À la troisième minute, répétez une recherche connue et un téléchargement existant. À la cinquième minute, déterminez si le comportement s’améliore, reste indisponible ou affiche un état vide.

Un rapport sur la persistance de la base de données décrit l’affichage répété de l’écran d’intégration après des redémarrages de Compose, alors que le répertoire de base de données attendu sur l’hôte restait vide. Il s’agit d’un environnement unique, mais ce cas fournit une signature d’échec claire : la disparition de l’identité persistante de l’application après un redémarrage indique que la base de données est écrite ailleurs que dans le chemin persistant prévu.

Associez l’amélioration de la latence à un état à froid, les erreurs de connexion au démarrage d’une dépendance, les médias manquants aux montages et les utilisateurs ou albums perdus à la persistance de la base de données. Conservez les journaux et les mappages de volumes actuels avant toute modification. Ne lancez une restauration qu’après avoir confirmé que l’état d’origine est indisponible, et non simplement déconnecté.