Este tópico começou como uma queixa sobre o arranque automático das aplicações, mas uma resposta posterior identificou um modo de falha mais profundo: o próprio Docker podia não arrancar porque uma substituição do systemd impunha o nvidia-container-runtime num anfitrião onde esse caminho de runtime era incompatível.
Comece por determinar se o Docker está a arrancar
Se várias aplicações não relacionadas falharem após o reinício, verifique o serviço Docker antes de editar cada aplicação. A resolução de problemas do daemon Docker documenta falhas de arranque do daemon causadas por configurações e substituições do systemd em conflito.
Os requisitos da App Store do ZimaOS ajudam a perceber quais as aplicações baseadas em Docker, enquanto a primeira aplicação Docker apresenta o fluxo de trabalho normal dos contentores no ZimaOS. Um problema que afete vários contentores em simultâneo é mais provavelmente causado pela camada do daemon/runtime do que por nove erros independentes das aplicações.
A política de reinício não é a única camada
As políticas de reinício do Docker explicam o que o daemon faz com os contentores parados. Não ajudam se o próprio daemon Docker não conseguir arrancar corretamente.
A correção do runtime NVIDIA era específica do sistema
Um colaborador desativou uma substituição do systemd do Docker que adicionava explicitamente o nvidia-container-runtime. Após o reinício, o Docker voltou a funcionar, mas o suporte para GPU NVIDIA deixou de estar configurado através dessa substituição.
O NVIDIA Container Toolkit recomenda atualmente configurar o Docker com nvidia-ctk runtime configure --runtime=docker e, em seguida, reiniciar o Docker. Este é um contexto importante: renomear um ficheiro de substituição mencionado num tópico antigo da comunidade não deve ser considerado o método moderno universal para configurar ou remover o runtime NVIDIA.
Verifique o espaço livre antes de modificar ficheiros do sistema
Um utilizador posterior tentou renomear a substituição e recebeu No space left on device. Esta é uma causa-raiz diferente e tem de ser resolvida primeiro. As alterações do ZimaOS 1.5 fornecem contexto sobre a versão das alterações do ZimaOS, enquanto o fluxo de resolução de problemas do ZimaOS é útil quando uma atualização provoca uma falha mais abrangente ao nível do anfitrião.
Uma ordem de diagnóstico mais segura
- Verifique se o Docker está ativo e consulte os respetivos registos recentes.
- Confirme que o disco do sistema não está cheio.
- Verifique as políticas de reinício dos contentores apenas depois de o daemon estar saudável.
- Se os registos mencionarem o carregamento do runtime NVIDIA, inspecione a configuração atual do runtime antes de a alterar.
- Faça uma cópia de segurança de qualquer substituição personalizada do systemd antes de a modificar.
Em resumo
O tópico original não prova que todos os problemas de arranque automático do ZimaOS 1.4.3 tivessem a mesma causa. Num sistema, uma substituição do runtime NVIDIA do Docker impediu o daemon de arrancar normalmente; noutro, a tentativa de correção revelou que o disco do sistema estava cheio. Analise o estado do daemon Docker e do armazenamento antes de aplicar a solução histórica baseada na substituição.
