¿Por qué Immich se comporta de manera diferente después de reiniciar un contenedor?

Immich cambia después de un reinicio porque las cachés temporales desaparecen y las dependencias del servicio se vuelven a conectar, mientras que una persistencia mal configurada puede provocar una pérdida de estado más grave.

Una primera búsqueda lenta puede ser normal cuando la caché está fría; una pantalla de configuración inicial nueva no lo es. Clasifica el síntoma según su duración y alcance antes de modificar los datos, porque el calentamiento de la caché, un fallo de dependencias y la falta de almacenamiento persistente requieren respuestas completamente distintas.

Un reinicio elimina el estado temporal del proceso

Los procesos reiniciados pierden los modelos en memoria, los grupos de conexiones, las rutas compiladas y las cachés de la aplicación. La caché de páginas del host puede sobrevivir al reinicio de un contenedor, pero un reinicio del host elimina una mayor parte de ese calentamiento. Por consiguiente, la primera solicitud de búsqueda o de la línea de tiempo puede realizar tareas de inicialización que las repeticiones inmediatas evitan.

Una medición de la comunidad informa de una primera búsqueda inteligente lenta, seguida de repeticiones mucho más rápidas mientras el modelo de aprendizaje automático se carga en la memoria de la GPU. El tiempo exacto depende de cada servidor, pero esta transición de estado explica por qué una sola solicitud posterior al reinicio no puede representar el funcionamiento estable.

Ejecuta la misma solicitud conocida tres veces y registra si la latencia converge. Si solo la primera solicitud es lenta y los resultados siguen siendo correctos, investiga la carga en frío o la política de retención. Si todas las solicitudes fallan o parece faltar estado, deja de tratar el síntoma como un simple calentamiento de la caché y examina las dependencias y la persistencia.

El orden de las dependencias puede revelar una condición de carrera durante el inicio

Immich depende de algo más que del proceso expuesto a la web. La base de datos, la coordinación de tareas, el servicio de aprendizaje automático y los medios montados deben estar disponibles con una configuración compatible. Un contenedor marcado como activo puede seguir inicializándose, por lo que una solicitud temprana puede fallar aunque la pila esté sana unos instantes después.

Un informe de un fallo tras el reinicio describe cómo Immich perdió el acceso a PostgreSQL o Redis después de cambios aparentemente no relacionados en Compose. Ese relato no demuestra un defecto general del producto, pero ilustra el valor diagnóstico de relacionar los errores de conexión de la aplicación con la disponibilidad de las dependencias y el momento del reinicio.

Recopila registros con marcas de tiempo de la aplicación y de la dependencia indicada durante el mismo reinicio. Verifica la resolución DNS, la accesibilidad del puerto, las comprobaciones de estado y la disponibilidad de los montajes dentro del contenedor. Si los reintentos automáticos recuperan el servicio, mejora la gestión de la disponibilidad; si nunca se recupera, prueba directamente la configuración y las credenciales.

El estado persistente debe sobrevivir al reemplazo del contenedor

Las imágenes y los archivos de la base de datos almacenados únicamente en la capa de escritura del contenedor desaparecen cuando ese contenedor se reemplaza. Los volúmenes con nombre y los montajes enlazados solo persisten cuando la implementación hace referencia a la misma ubicación subyacente. Un reinicio simple normalmente los conserva, pero las modificaciones en Compose o los cambios de ruta pueden seleccionar silenciosamente un almacenamiento nuevo y vacío.

El artículo sobre la ruta de datos de ZimaSpace explica que una ruta visible dentro del contenedor no revela el almacenamiento físico ni el dominio de fallo que hay detrás. Esto es fundamental después de recrear el contenedor: una ruta interna idéntica puede apuntar a un directorio de host diferente, un volumen vacío o un montaje de red no disponible.

Si Immich muestra la configuración inicial, no crees inmediatamente una biblioteca de reemplazo. Inspecciona los montajes efectivos, los identificadores de volumen, la propiedad y los registros de la base de datos, y compáralos con la última implementación que funcionaba. Las nuevas escrituras pueden complicar la recuperación al crear un segundo conjunto de estados junto al original desaparecido.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Clasifica el reinicio en cinco minutos

En el minuto cero, registra qué contenedores se reiniciaron y si cambiaron las imágenes o la configuración. En el minuto uno, comprueba el estado de las dependencias y los montajes. En el minuto tres, repite una búsqueda conocida y una descarga original. En el minuto cinco, decide si el comportamiento mejora, sigue sin estar disponible o muestra un estado vacío.

Un informe sobre la persistencia de la base de datos describe cómo aparecía repetidamente la configuración inicial después de reiniciar Compose, mientras el directorio de la base de datos esperado en el host seguía vacío. Es un solo entorno, pero ofrece una señal de fallo clara: si la identidad persistente de la aplicación desaparece entre reinicios, la base de datos se está escribiendo en un lugar distinto de la ruta persistente prevista.

Relaciona la latencia que mejora con un estado en frío, los errores de conexión con el inicio de las dependencias, la ausencia de medios con los montajes y la pérdida de usuarios o álbumes con la persistencia de la base de datos. Conserva los registros y las asignaciones de volúmenes actuales antes de realizar cualquier cambio. Recurre a una restauración solo después de confirmar que el estado original no está disponible, en lugar de estar simplemente desconectado.