Solução da comunidade

ZimaOS 1.4.3 não consegue ligar-se ao daemon do Docker: reinício manual e a correção da versão 1.4.4

An August 2025 ZimaBoard 832 thread where ZimaOS 1.4.3 stopped starting Docker automatically after upgrade. IceWhale called it a known Docker-service issue and provided a manual restart command. The user confirmed the command worked, but the failure returned after reboot. ZimaOS 1.4.4 later fixed insufficient Docker startup timing.

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.
Caixa de diálogo de instalação da App Store do ZimaOS, mostrando Não é possível ligar ao daemon do Docker em unix:///var/run/docker.sock
O painel não conseguia aceder ao Docker através de /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

Painel do ZimaOS após o reinício, mostrando o Jellyfin como iniciado, enquanto o widget do sistema indica que não existe atividade real de CPU ou RAM da aplicação
O mosaico da aplicação podia parecer ativo após o reinício, embora o serviço Docker não tivesse restaurado o verdadeiro estado de execução da aplicação.

Reiniciar o Docker Restaurou o Estado Real da Aplicação

Painel do ZimaOS após o reinício do Docker, mostrando o estado real do Jellyfin e a atividade restaurada dos recursos do sistema
Depois de reiniciar o Docker, a interface refletiu o estado real da aplicação e o utilizador conseguiu iniciar o Jellyfin normalmente.

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.