Este tópico de origem apresenta uma conclusão forte e específica da versão. Depois de atualizar um ZimaBoard 832 para o ZimaOS 1.4.3, o Docker não iniciou automaticamente, a App Store não conseguia instalar novas aplicações e as aplicações existentes não iniciavam. Zima-Giorgio afirmou que a equipa tinha conhecimento do problema do serviço Docker e forneceu um comando temporário para o reinício manual.
O autor original confirmou que o comando de reinício resolveu o problema imediato, mas também relatou que o Docker falhava novamente após cada reinício do anfitrião. A versão seguinte da IceWhale fornece a explicação em falta: o ZimaOS 1.4.4 corrigiu oficialmente uma falha de arranque do Docker causada por um intervalo de arranque do serviço insuficiente.
A Falha Surgiu Imediatamente Após a Atualização para a Versão 1.4.3
O utilizador da fonte relatou:
- a atualização do Prowlarr ficou bloqueada;
- as aplicações existentes não iniciavam;
- as novas instalações da App Store falhavam;
- a interface indicava que não conseguia ligar-se ao daemon do Docker.
/var/run/docker.sock, impedindo a instalação e o arranque de aplicações.A IceWhale Classificou-o como um Problema Conhecido do Serviço Docker
A 26 de agosto, Zima-Giorgio escreveu que a equipa considerava tratar-se de um problema conhecido do serviço Docker e afirmou que seria lançada uma correção.
Forneceu a solução alternativa temporária oficial:
sudo -i
systemctl restart docker docker.socket
Este comando é uma orientação histórica válida da IceWhale para o caso de origem da versão 1.4.3.
O Autor Original Confirmou que o Reinício Manual do Docker Funcionou
O utilizador respondeu que reiniciar o Docker como root através da CLI resolveu completamente o problema imediato. Trata-se de um sucesso confirmado pela fonte, não de uma solução alternativa especulativa.
No entanto, o mesmo utilizador reiniciou depois o ZimaBoard e descobriu que o Docker voltou a não iniciar automaticamente.
O Painel Podia Mostrar as Aplicações como Iniciadas Quando o Docker Não Estava Operacional
Reiniciar o Docker Restaurou o Estado Real da Aplicação
O reinício manual das aplicações não resolveu de forma fiável o reinício seguinte
Zima-Giorgio afirmou que alguns relatos sugeriam que iniciar e reiniciar manualmente cada aplicação poderia ajudar em futuros reinícios. O autor original testou a ideia, mas continuou a ver o mesmo estado de falso arranque após o reinício.
Isto torna importante não apresentar o reinício por aplicação como a correção final da origem do problema.
O ZimaOS 1.4.4 corrigiu o problema de temporização do arranque do Docker
As notas de lançamento oficiais da IceWhale para a versão 1.4.4 incluem:
- uma correção para as aplicações permanecerem no estado de carregamento após o arranque;
- uma correção para o intervalo de arranque do serviço Docker, que era insuficiente e causava uma falha no arranque;
- correções adicionais do estado das aplicações e dos cartões de instalação.
Consulte as correções do arranque do Docker no ZimaOS 1.4.4 para conhecer a resolução histórica do produto.
Os utilizadores atuais não devem considerar systemctl restart uma solução permanente
Numa versão moderna do ZimaOS, um daemon Docker que falha repetidamente após o reinício indica um problema atual relacionado com o serviço, o armazenamento, o runtime ou a configuração. Reiniciar o Docker pode ser uma ação de diagnóstico, mas recolha a falha real antes de transformar um reinício manual numa prática normal a cada arranque.
As evidências atuais úteis incluem:
-
systemctl status docker.service; -
journalctl -u docker.service; - espaço livre no disco do sistema;
- substituições recentes do runtime/GPU ou modificações no anfitrião;
- a versão atual exata do ZimaOS.
Um sintoma semelhante pode ter uma causa subjacente diferente
Outra discussão sobre a versão 1.4.3 relatou que o Docker falhava porque uma substituição personalizada do runtime NVIDIA permanecia na configuração do systemd. Trata-se de uma causa diferente do problema de temporização do arranque neste tópico de origem.
Não remova ficheiros de substituição de serviços, a menos que os registos indiquem que uma substituição específica está efetivamente a impedir o daemon de funcionar.
Perguntas frequentes sobre o Docker Daemon 1.4.3
A IceWhale forneceu oficialmente um reinício manual do Docker?
Sim. Zima-Giorgio publicou systemctl restart docker docker.socket como solução temporária da versão 1.4.3.
O utilizador de origem confirmou que funcionou?
Sim, para o arranque atual. A falha voltou após o reinício.
Que versão documentou a correção do arranque ao nível do produto?
O ZimaOS 1.4.4 corrigiu um tempo de arranque insuficiente do serviço Docker, que podia causar uma falha no arranque.
