Este hilo de origen permite extraer una conclusión sólida y específica de la versión. Después de actualizar un ZimaBoard 832 a ZimaOS 1.4.3, Docker no se iniciaba automáticamente, la App Store no podía instalar nuevas aplicaciones y las aplicaciones existentes no podían iniciarse. Zima-Giorgio afirmó que el equipo conocía el problema del servicio de Docker y proporcionó un comando temporal para reiniciarlo manualmente.
El autor original confirmó que el comando de reinicio resolvía el problema inmediato, pero también informó de que Docker volvía a fallar después de cada reinicio del equipo anfitrión. La siguiente versión de IceWhale aporta el dato decisivo: ZimaOS 1.4.4 corrigió un fallo de inicio de Docker causado por un intervalo de inicio del servicio insuficiente.
El fallo apareció inmediatamente después de la actualización a la versión 1.4.3
El usuario de la fuente informó:
- la actualización de Prowlarr se quedaba bloqueada;
- las aplicaciones existentes no se iniciaban;
- fallaban las instalaciones de nuevas aplicaciones desde la App Store;
- la interfaz informaba de que no podía conectarse al demonio de Docker.
/var/run/docker.sock, lo que impedía instalar e iniciar aplicaciones.IceWhale lo identificó como un problema conocido del servicio de Docker
El 26 de agosto, Zima-Giorgio escribió que el equipo consideraba que se trataba de un problema conocido del servicio de Docker y afirmó que se publicaría una solución.
Proporcionó la solución temporal oficial:
sudo -i
systemctl restart docker docker.socketEste comando es una indicación histórica válida de IceWhale para el caso de origen de la versión 1.4.3.
El autor original confirmó que el reinicio manual de Docker funcionó
El usuario respondió que reiniciar Docker como root mediante la CLI resolvió por completo el problema inmediato. Es un éxito confirmado por la fuente, no una solución especulativa.
Sin embargo, el mismo usuario reinició después el ZimaBoard y descubrió que Docker volvía a no iniciarse automáticamente.
El panel podía mostrar las aplicaciones como iniciadas cuando Docker no funcionaba correctamente
Reiniciar Docker restauró el estado real de la aplicación
El reinicio manual de las aplicaciones no solucionó de forma fiable el siguiente arranque
Zima-Giorgio dijo que algunos informes sugerían que iniciar y reiniciar manualmente cada aplicación podría ayudar en futuros reinicios. El autor original probó la idea, pero siguió viendo el mismo estado de inicio falso después de reiniciar.
Por eso es importante no presentar el reinicio de cada aplicación como la solución definitiva del origen.
ZimaOS 1.4.4 corrigió el problema de sincronización del inicio de Docker
Las notas de lanzamiento oficiales de IceWhale para la versión 1.4.4 incluyen:
- una corrección para las aplicaciones que permanecían en estado de carga después del arranque;
- una corrección para el intervalo de inicio del servicio Docker, que era insuficiente y provocaba un fallo durante el arranque;
- correcciones adicionales del estado de las aplicaciones y de las tarjetas de instalación.
Consulta las correcciones del inicio de Docker de ZimaOS 1.4.4 para conocer la solución histórica del producto.
Los usuarios actuales no deben considerar systemctl restart como la solución permanente
En una versión moderna de ZimaOS, que un daemon de Docker falle repetidamente después de reiniciar indica un problema actual del servicio, el almacenamiento, el runtime o la configuración. Reiniciar Docker puede ser una acción de diagnóstico, pero recopila el fallo real antes de normalizar un reinicio manual en cada arranque.
Las pruebas actuales útiles incluyen:
-
systemctl status docker.service; -
journalctl -u docker.service; - espacio libre en el disco del sistema;
- anulaciones recientes del GPU/runtime o modificaciones del host;
- la versión exacta actual de ZimaOS.
Un síntoma similar puede tener una causa raíz diferente
Otra discusión sobre la versión 1.4.3 informó de que Docker fallaba porque una anulación personalizada del runtime de NVIDIA permanecía en la configuración de systemd. Esa es una causa distinta del problema de sincronización del inicio descrito en este hilo de origen.
No elimines los archivos de anulación del servicio a menos que los registros indiquen que una anulación específica está provocando el fallo del daemon.
Preguntas frecuentes sobre Docker Daemon 1.4.3
¿IceWhale proporcionó oficialmente un reinicio manual de Docker?
Sí. Zima-Giorgio publicó systemctl restart docker docker.socket como solución temporal de la versión 1.4.3.
¿El usuario original confirmó que funcionaba?
Sí, para el arranque actual. El fallo volvió a aparecer después de reiniciar.
¿Qué versión documentó la solución del inicio a nivel del producto?
ZimaOS 1.4.4 solucionó el tiempo de inicio insuficiente del servicio Docker, que podía provocar un fallo durante el arranque.
