Este hilo comenzó como una queja sobre el inicio automático de las aplicaciones, pero una respuesta posterior identificó un modo de fallo más profundo: Docker podía no iniciarse porque una anulación de systemd forzaba nvidia-container-runtime en un host donde esa ruta de ejecución era incompatible.
Primero determina si Docker se está iniciando
Si varias aplicaciones no relacionadas fallan después de reiniciar, inspecciona el servicio de Docker antes de editar cada aplicación. La solución de problemas del demonio de Docker documenta fallos de inicio del demonio causados por configuraciones y anulaciones de systemd en conflicto.
Los requisitos de la tienda de aplicaciones de ZimaOS ayudan a determinar qué aplicaciones están basadas en Docker, mientras que la guía sobre la primera aplicación Docker explica el flujo de trabajo normal de los contenedores en ZimaOS. Un problema que afecta simultáneamente a muchos contenedores probablemente se encuentre en la capa del demonio o del entorno de ejecución, y no en nueve errores independientes de las aplicaciones.
La política de reinicio no es la única capa
Las políticas de reinicio de Docker explican qué hace el demonio con los contenedores detenidos. No ayudan si el propio demonio de Docker no puede iniciarse correctamente.
La solución del entorno de ejecución de NVIDIA era específica del sistema
Un colaborador desactivó una anulación de systemd de Docker que añadía explícitamente nvidia-container-runtime. Después de reiniciar, Docker volvió a funcionar, pero la compatibilidad con la GPU NVIDIA dejó de estar configurada mediante esa anulación.
Actualmente, el NVIDIA Container Toolkit recomienda configurar Docker con nvidia-ctk runtime configure --runtime=docker y, después, reiniciar Docker. Este contexto es importante: cambiar el nombre de un archivo de anulación mencionado en un hilo antiguo de la comunidad no debe considerarse el método moderno universal para configurar o eliminar el entorno de ejecución de NVIDIA.
Comprueba el espacio libre antes de modificar archivos del sistema
Un usuario posterior intentó cambiar el nombre de la anulación y recibió No space left on device. Esa es una causa raíz diferente que debe resolverse primero. Los cambios de ZimaOS 1.5 proporcionan contexto sobre las versiones de ZimaOS, mientras que el flujo de trabajo de solución de problemas de ZimaOS resulta útil cuando un fallo más amplio del host aparece después de una actualización.
Un orden de diagnóstico más seguro
- Comprueba si Docker está activo y revisa sus registros recientes.
- Confirma que el disco del sistema no esté lleno.
- Comprueba las políticas de reinicio de los contenedores solo después de verificar que el demonio funciona correctamente.
- Si los registros mencionan la carga del entorno de ejecución de NVIDIA, inspecciona la configuración actual del entorno antes de cambiarla.
- Haz una copia de seguridad de cualquier anulación personalizada de systemd antes de modificarla.
En resumen
El hilo original no demuestra que todos los problemas de inicio automático de ZimaOS 1.4.3 tuvieran la misma causa. En un sistema, una anulación del entorno de ejecución de NVIDIA para Docker impedía que el demonio se iniciara con normalidad; en otro, el intento de aplicar la solución reveló que el disco del sistema estaba lleno. Diagnostica el demonio de Docker y el estado del almacenamiento antes de aplicar la solución histórica basada en la anulación.
