O tópico continha mais do que um problema de arranque de aplicações
Depois de atualizar do ZimaOS 1.4.1 para a versão 1.4.2, o autor da publicação original descobriu que algumas aplicações, incluindo o Portainer, não pareciam iniciar automaticamente. Políticas de reinício do Docker, como a menos que seja parado e sempre não alterou o resultado visível, enquanto clicar na aplicação no painel a iniciou.
Outros utilizadores relataram depois sintomas relacionados, mas distintos. Um grupo descobriu que os contentores já estavam acessíveis através do respetivo endereço Web direto, enquanto o painel do ZimaOS se comportava como se estivessem parados. Outro utilizador confirmou mais tarde que alguns contentores realmente falhavam porque os caminhos dos volumes suportados por SMB não estavam montados quando o arranque da aplicação ocorreu.
Caso um: o contentor funcionava, mas o painel não o conseguia abrir
Um utilizador documentou uma sequência de quatro passos. Primeiro, o painel apresentou a aplicação como parada e, em seguida, avisou que poderia estar indisponível. Seguir a ligação disponibilizada abriu uma nova janela do navegador, onde a aplicação funcionava normalmente. Colar diretamente o mesmo endereço e porta no navegador também funcionou.
A equipa da IceWhale considerou este comportamento parte da investigação. O tópico não demonstra que alterar uma política de reinício do Docker corrija este problema do estado do painel.
Caso dois: falha nas atualizações de aplicações e nas definições para um utilizador
Outro participante, que executava a versão 1.4.3, relatou breves erros ao atualizar o Radarr e o Sonarr e afirmou que as alterações às definições não eram aplicadas. Reinstalar as aplicações não ajudou nesse ambiente. Mais tarde, o participante afirmou que alterar os espelhos de registo permitiu novamente alterar as definições e, separadamente, restaurou a propriedade das pastas de aplicações relevantes para corresponder ao UID 1000 configurado.
Estas foram alterações comunicadas por utilizadores, não uma solução universal para todas as falhas após reiniciar. Editar a configuração do daemon do Docker ou alterar recursivamente a propriedade pode afetar todo o anfitrião, pelo que as evidências da discussão não devem ser generalizadas para além do ambiente do participante.
Caso três: o armazenamento SMB não estava pronto quando os contentores iniciaram
Mais tarde, o autor original identificou uma causa concreta para três contentores. Os respetivos volumes estavam mapeados para uma partilha SMB. Os registos mostraram que os contentores tentaram iniciar antes de o sistema de ficheiros SMB estar disponível, falharam e permaneceram parados. Iniciá-los manualmente mais tarde funcionou porque, entretanto, a partilha já tinha sido montada.
Isto explica por que motivo alterar sempre para a menos que seja parado não ajudou esses contentores: uma política de reinício não pode fazer com que um caminho de montagem bind indisponível fique pronto mais cedo. A dependência relevante era a disponibilidade do armazenamento e a ordem de arranque.
O que a versão 1.4.3 confirmou e não confirmou
Uma resposta da IceWhale pediu aos utilizadores que testassem a versão 1.4.3. Um participante afirmou que o comportamento do painel se manteve, enquanto o autor original pensou inicialmente que a versão 1.4.3 tinha ajudado, mas mais tarde reproduziu a falha de ordem de arranque do SMB. Outra resposta observou que uma aplicação tem de ser iniciada primeiro para que o serviço de gestão de aplicações saiba qual foi o seu último estado em execução.
Por conseguinte, a discussão não sustenta a afirmação generalizada de que a versão 1.4.3 corrigiu todos os problemas de arranque da versão 1.4.2. Sustenta uma distinção de diagnóstico: primeiro, verifique se o contentor está realmente parado; depois, consulte os respetivos registos e as dependências de armazenamento.
Perguntas frequentes
Porque é que uma aplicação abre através do URL, mas aparece como parada no ZimaOS?
Esse padrão surgiu como um problema de lançamento ou comunicação de estado no painel. O próprio serviço já podia estar em execução e acessível no endereço e na porta configurados.
Porque é que apenas os contentores que utilizam uma partilha SMB falham depois de reiniciar?
No caso confirmado, esses contentores iniciaram antes de a montagem SMB estar pronta. Funcionaram quando foram iniciados manualmente depois de a partilha ficar disponível.
Alterar a política de reinício do Docker resolveu o problema?
Não. O autor original testou ambos sempre e a menos que seja parado sem resolver os contentores afetados.
