Un container Docker che rimane contrassegnato come «in esecuzione» ma non può essere arrestato è diverso da un normale arresto anomalo dell’applicazione qBittorrent. In questa segnalazione di febbraio 2026 su ZimaOS 1.5.4, qBittorrent ha funzionato per circa tre-sei ore, poi il traffico di rete è sceso a zero e Docker non è più riuscito ad arrestare o rimuovere il container correttamente.
L’utente originale ha provato diverse immagini e versioni di qBittorrent, modificato le risorse di memoria e CPU, riavviato Docker, ricreato il container e ha comunque riprodotto lo stesso errore. Il riavvio dell’host ZimaOS è stata l’unica operazione che ha eliminato lo stato bloccato.
Il container risultava in esecuzione anche dopo l’interruzione dell’attività
L’errore Docker riportato dall’utente indicava che il sistema aveva provato a terminare il container, ma non aveva ricevuto alcun evento di uscita. Questo fa pensare a un livello diverso rispetto al normale arresto anomalo di un processo.
L’I/O di rete è sceso a zero quando si è verificato il blocco
L’analisi della community ha indicato un’attesa I/O non interrompibile
Un membro della community ha ipotizzato che il processo fosse bloccato nello stato D di Linux, un’attesa non interrompibile solitamente associata all’I/O. L’autore del post originale ha poi riferito che neppure un SIGKILL diretto faceva scomparire il processo, un comportamento compatibile con un processo bloccato all’interno del kernel.
Si tratta di un importante indizio per la risoluzione dei problemi, ma nella discussione non è mai arrivata una conferma da parte degli ingegneri di IceWhale. Pertanto, va descritto come una diagnosi della community, non come una regressione comprovata del kernel di ZimaOS.
È stato osservato un uso elevato della cache, ma non è stato dimostrato che fosse la causa
Linux utilizza normalmente la RAM altrimenti libera per la cache del filesystem, quindi un valore elevato della cache non indica automaticamente una perdita di memoria.
Perché cambiare le immagini di qBittorrent non ha risolto il problema
L’utente ha riprodotto il problema con diverse varianti di immagini e tag di versione di qBittorrent. Ciò indebolisce la teoria secondo cui fosse responsabile una singola immagine del container, ma non permette comunque di stabilire se il fattore scatenante fosse l’archiviazione, la rete, la virtualizzazione, il kernel, Docker o un’interazione tra questi elementi.
Si trattava di un caso relativo a ZimaOS 1.5.4
Il problema appartiene a una specifica versione storica. La discussione non contiene né una soluzione permanente né un test che dimostri se una versione successiva di ZimaOS abbia eliminato il comportamento. Prima di ripetere vecchie procedure di risoluzione dei problemi a basso livello, confronta il tuo sistema con la versione corrente di ZimaOS.
Domande frequenti sul container zombie di qBittorrent
È stato dimostrato che qBittorrent andasse in crash?
No. L’aspetto insolito era che il processo diventava impossibile da terminare mentre Docker continuava a considerare il container in esecuzione.
Che cosa significa lo stato D in questo contesto?
È un’attesa non interrompibile nel kernel, comunemente associata all’I/O. Un membro della community lo ha usato per spiegare perché anche una terminazione forzata potesse non riuscire.
Il riavvio di Docker ha risolto il problema?
No, nel caso descritto nella fonte. Solo il riavvio completo dell’host ha ripristinato il processo bloccato.
IceWhale ha confermato la causa principale?
No. L’autore del post originale ha taggato il team chiedendo un’indagine, ma la discussione pubblicata si è conclusa senza una diagnosi ufficiale o una soluzione permanente.
