El hilo contenía más de un problema de inicio de aplicaciones
Después de actualizar de ZimaOS 1.4.1 a 1.4.2, el autor de la publicación original descubrió que algunas aplicaciones, incluido Portainer, no parecían iniciarse automáticamente. Las políticas de reinicio de Docker, como a menos que se detenga explícitamente y siempre no cambió el resultado visible, mientras que hacer clic en la aplicación del panel la iniciaba.
Después, otros usuarios informaron de síntomas relacionados pero distintos. Un grupo descubrió que ya se podía acceder a los contenedores mediante su dirección web directa, mientras que el panel de ZimaOS se comportaba como si estuvieran detenidos. Otro usuario confirmó más tarde que algunos contenedores realmente fallaban porque las rutas de volumen respaldadas por SMB no estaban montadas cuando se iniciaba la aplicación.
Caso uno: el contenedor funcionaba, pero el panel no podía abrirlo
Un usuario documentó una secuencia de cuatro pasos. Primero, el panel mostraba la aplicación como detenida y después advertía que podría no estar disponible. Al seguir el enlace ofrecido, se abrió una nueva ventana del navegador en la que la aplicación funcionaba con normalidad. Pegar directamente en el navegador la misma dirección y el puerto también funcionó.
El equipo de IceWhale consideró este comportamiento parte de la investigación. El hilo no establece que cambiar una política de reinicio de Docker solucione este problema del estado del panel.
Caso dos: las actualizaciones de aplicaciones y la configuración fallaron para un usuario
Otro participante que ejecutaba la versión 1.4.3 informó de breves errores al actualizar Radarr y Sonarr y dijo que los cambios de configuración no se aplicaban. Reinstalar las aplicaciones no ayudó en ese entorno. Más tarde, el participante dijo que cambiar los espejos del registro permitió aplicar de nuevo los cambios de configuración y, por separado, restableció la propiedad de las carpetas de aplicaciones pertinentes para que coincidiera con el UID 1000 configurado.
Estos fueron cambios informados por usuarios, no una solución universal para todos los fallos tras un reinicio. Editar la configuración del demonio de Docker o cambiar recursivamente la propiedad puede afectar a todo el host, por lo que las pruebas del hilo no deben generalizarse más allá del entorno del participante.
Caso tres: el almacenamiento SMB no estaba listo cuando se iniciaron los contenedores
Más tarde, el autor original identificó una causa concreta para tres contenedores. Sus volúmenes estaban asignados a un recurso compartido SMB. Los registros mostraron que los contenedores intentaron iniciarse antes de que el sistema de archivos SMB estuviera disponible, fallaron y permanecieron detenidos. Iniciarlos manualmente más tarde funcionó porque para entonces el recurso compartido ya se había montado.
Esto explica por qué cambiar siempre a a menos que se detenga explícitamente no ayudó a esos contenedores: una política de reinicio no puede hacer que una ruta de montaje vinculada no disponible esté lista antes. La dependencia relevante era la disponibilidad del almacenamiento y el orden de inicio.
Qué confirmó y qué no confirmó la versión 1.4.3
Una respuesta de IceWhale pidió a los usuarios que probaran la versión 1.4.3. Un participante dijo que el comportamiento del panel continuaba, mientras que el autor original pensó inicialmente que la versión 1.4.3 había ayudado, pero después reprodujo el fallo del orden de inicio de SMB. Otra respuesta señaló que primero hay que iniciar una aplicación para que el servicio de gestión de aplicaciones conozca su último estado de ejecución.
Por lo tanto, el hilo no respalda una afirmación general de que la versión 1.4.3 solucionara todos los problemas de inicio de la versión 1.4.2. Respalda una distinción diagnóstica: primero comprueba si el contenedor está realmente detenido y, después, revisa sus registros y las dependencias de almacenamiento.
Preguntas frecuentes
¿Por qué una aplicación se abre mediante URL, pero aparece detenida en ZimaOS?
Ese patrón apareció como un problema de lanzamiento del panel o de notificación del estado. El servicio en sí ya podía estar ejecutándose y accesible en la dirección y el puerto configurados.
¿Por qué fallan después de reiniciar solo los contenedores que usan un recurso compartido SMB?
En el caso confirmado, esos contenedores se iniciaron antes de que el montaje SMB estuviera listo. Funcionaron al iniciarlos manualmente después de que apareciera el recurso compartido.
¿Cambiar la política de reinicio de Docker resolvió el problema?
No. El autor original probó ambas opciones. siempre y a menos que se detenga explícitamente sin resolver los contenedores afectados.
