Um contentor Docker que permanece marcado como “em execução”, mas que não pode ser parado, é diferente de uma falha normal da aplicação qBittorrent. Neste relatório de fevereiro de 2026 sobre o ZimaOS 1.5.4, o qBittorrent funcionou durante aproximadamente três a seis horas; depois, o tráfego de rede caiu para zero e o Docker deixou de conseguir parar ou remover o contentor de forma limpa.
O utilizador original experimentou várias imagens e versões do qBittorrent, alterou as alocações de memória e CPU, reiniciou o Docker, recriou o contentor e, ainda assim, reproduziu a mesma falha. Reiniciar o anfitrião ZimaOS foi a única ação que eliminou o estado bloqueado.
O contentor parecia estar em execução depois de a atividade ter parado
O erro do Docker comunicado pelo utilizador indicava que este tentou terminar o contentor, mas não recebeu um evento de saída. Isto aponta para uma camada diferente da de uma falha normal do processo.
A E/S de rede caiu para zero quando ocorreu o bloqueio
A análise da comunidade apontou para um estado de espera de E/S não interrompível
Um membro da comunidade defendeu que o processo provavelmente estava bloqueado no estado D do Linux, uma espera não interrompível normalmente associada a E/S. O autor original comunicou então que nem mesmo um SIGKILL direto fazia o processo desaparecer, o que é compatível com um processo bloqueado dentro do kernel.
Esta é uma pista de diagnóstico importante, mas o tópico nunca recebeu confirmação da equipa de engenharia da IceWhale. Por isso, deve ser descrita como um diagnóstico da comunidade, não como uma regressão comprovada do kernel do ZimaOS.
Foi observado um uso elevado da cache, mas não foi provado que fosse a causa
O Linux utiliza normalmente a RAM que não está a ser usada para a cache do sistema de ficheiros, pelo que um valor elevado de cache não significa automaticamente uma fuga de memória.
Por que motivo a alteração das imagens do qBittorrent não resolveu a questão
O utilizador reproduziu o problema com várias variantes de imagens e etiquetas de versão do qBittorrent. Isto enfraquece a teoria de que uma única imagem do contentor fosse responsável, mas ainda não identifica se o fator desencadeante foi o armazenamento, a rede, a virtualização, o kernel, o Docker ou uma interação entre estes elementos.
Este foi um caso do ZimaOS 1.5.4
A falha pertence a uma versão histórica específica. O tópico não contém uma correção permanente nem um teste que demonstre se uma versão posterior do ZimaOS eliminou este comportamento. Antes de reproduzir procedimentos de diagnóstico antigos e de baixo nível, compare o seu sistema com a versão atual do ZimaOS.
FAQ sobre o contentor zombie do qBittorrent
Foi provado que o próprio qBittorrent estava a falhar?
Não. O aspeto invulgar foi o processo ter ficado impossível de terminar enquanto o Docker continuava a considerar que o contentor estava em execução.
O que significa o estado D neste contexto?
É uma espera não interrompível no kernel, normalmente associada a E/S. Um membro da comunidade utilizou este conceito para explicar por que motivo até uma terminação forçada podia falhar.
Reiniciar o Docker resolveu o problema?
Não no caso original. Apenas um reinício completo do anfitrião recuperou o processo bloqueado.
A IceWhale confirmou a causa principal?
Não. O autor original identificou a equipa para investigação, mas o tópico publicado terminou sem um diagnóstico oficial ou uma correção permanente.
