Se o Stirling PDF permanecer no ecrã inicial do ZimaOS como «A instalar», verifique primeiro se o contentor Docker existe realmente e está em execução. Um cartão de instalação bloqueado pode ser um problema do estado do frontend ou da gestão de aplicações, enquanto um contentor que reinicia repetidamente aponta para um erro de implementação real. Considere estas situações como falhas diferentes.
O tópico de origem nunca chegou a uma solução verificada: reinstalar não limpou o estado e um reinício completo do ZimaOS não ajudou o utilizador original. Por isso, o guia seguro consiste em diagnosticar o estado do contentor, os registos, os metadados da App Store e o comportamento atual do pacote, em vez de afirmar que reiniciar é a solução.
Passo 1: Verifique se o Stirling PDF está em execução
No terminal do anfitrião ZimaOS:
docker ps -a --format 'table {.Names} {.Image} {.Status}' | grep -i stirlingSe houver um contentor do Stirling em execução, teste diretamente a porta publicada da interface Web. Se funcionar através do endereço IP e da porta, a aplicação está operacional e o cartão bloqueado é provavelmente um problema do estado da interface ou da gestão.
Passo 2: Verifique os registos do contentor
docker logs --tail 200 <stirling-container-name>Procure conflitos de portas, falhas de permissões, variáveis de ambiente inválidas ou ciclos de reinício. Não desinstale repetidamente antes de saber por que razão o contentor atual está a falhar.
Passo 3: Force a atualização do painel do ZimaOS
Utilize uma janela de navegação privada ou limpe os dados em cache do site relativos ao endereço local do ZimaOS. Se o cartão de instalação desaparecer numa sessão limpa, o backend poderá já estar correto.
Passo 4: Verifique simultaneamente a App Store e o estado do Docker
Se a interface indicar «a instalar», mas o Docker não mostrar nenhum contentor do Stirling, a tarefa de gestão da aplicação poderá estar obsoleta. Se o Docker mostrar um contentor que reinicia constantemente, o estado apresentado pelo frontend está a refletir uma implementação realmente incompleta.
Utilize as definições Docker atuais do Stirling PDF
A documentação atual do Stirling PDF utiliza a imagem oficial e volumes de configuração persistentes, sem exigir modificações específicas do anfitrião ZimaOS.
O guia Docker do Stirling PDF é a fonte de referência ao reconstruir a definição da aplicação.
Não elimine dados persistentes apenas para remover o cartão
Se o Stirling PDF já tiver criado dados de configuração ou de utilizadores, remover os dados da aplicação pode transformar um problema meramente visual do estado de instalação numa perda de dados. Faça uma cópia de segurança dos volumes mapeados antes de efetuar uma limpeza manual do Docker.
Quando é apropriado remover manualmente o contentor Docker
Se o ZimaOS não conseguir remover, através da interface, um contentor órfão claramente falhado, os utilizadores avançados podem remover o contentor específico depois de registarem a respetiva imagem, portas e mapeamentos de volumes. Não elimine imagens, redes ou volumes não relacionados.
Após a limpeza, atualize a App Store e reinstale a partir de um pacote atual ou de uma definição Compose do projeto original.
Verifique a versão atual do ZimaOS
O caso de origem remonta a meados de 2025. Desde então, o ZimaOS atual recebeu várias correções relacionadas com a App Store, o arranque do Docker, as portas da interface Web e a compatibilidade com YAML. Atualize para uma versão estável atual antes de considerar o antigo sintoma de instalação bloqueada um erro atual do produto.
O guia de resolução de problemas do Docker apresenta o modelo mais abrangente dos contentores.
Verifique se a tarefa de instalação ainda produz atividade
Se o cartão permanecer indefinidamente no mesmo progresso, compare as transferências do Docker, a criação do contentor e a atividade da rede ao longo de vários minutos. Uma imagem que esteja realmente a ser transferida deverá apresentar alterações no estado da imagem ou das camadas, enquanto uma tarefa obsoleta do frontend pode permanecer inalterada mesmo quando nada está a acontecer.
Verifique se existem conflitos de portas antes de reinstalar
O Stirling PDF expõe normalmente um serviço Web. Se a porta do anfitrião selecionada pelo pacote já estiver ocupada, a imagem pode ser transferida com sucesso, mas o contentor poderá não iniciar. Inspecione os registos do contentor e as associações de portas atuais em vez de premir repetidamente «Instalar».
Confirme que os caminhos persistentes permitem escrita
Um contentor também pode falhar após a transferência da imagem se a respetiva configuração ou diretório de trabalho estiver mapeado para uma pasta do anfitrião onde o serviço não consiga escrever. Verifique se o caminho do anfitrião existe e tem a propriedade adequada para o contentor, em vez de utilizar permissões demasiado amplas em todo o /DATA.
Perguntas frequentes
Reiniciar o ZimaOS elimina uma instalação bloqueada do Stirling PDF?
Pode eliminar um estado temporário, mas não resolveu o caso do utilizador original. Verifique primeiro o contentor Docker e os respetivos registos.
E se o Stirling PDF abrir apesar de o painel indicar «A instalar»?
Então, é provável que a aplicação esteja operacional e que o problema esteja no estado do frontend ou da gestão de aplicações do ZimaOS.
Devo eliminar os dados da aplicação do Stirling PDF?
Não, não apenas para remover o cartão de instalação. Faça uma cópia de segurança dos volumes persistentes antes de qualquer limpeza destrutiva.
Devo utilizar a imagem oficial atual do Stirling?
Sim. Se reconstruir a aplicação, siga a documentação Docker atual do projeto original, em vez de utilizar um manifesto antigo.
