Een Docker-container die als ‘actief’ gemarkeerd blijft maar niet kan worden gestopt, verschilt van een normale crash van de qBittorrent-applicatie. In dit rapport uit februari 2026 over ZimaOS 1.5.4 werkte qBittorrent ongeveer drie tot zes uur, waarna het netwerkverkeer naar nul daalde en Docker de container niet meer netjes kon stoppen of verwijderen.
De oorspronkelijke gebruiker probeerde meerdere qBittorrent-images en -versies, wijzigde de geheugen- en CPU-toewijzingen, startte Docker opnieuw op, maakte de container opnieuw aan en zag dezelfde fout nog steeds terugkomen. Alleen het opnieuw opstarten van de ZimaOS-host maakte een einde aan de vastgelopen toestand.
De container leek actief nadat de activiteit was gestopt
De Docker-fout die de gebruiker rapporteerde, gaf aan dat Docker probeerde de container te beëindigen, maar geen exitgebeurtenis ontving. Dat wijst op een andere laag dan een normale procescrash.
Netwerk-I/O daalde naar nul toen de vastloper optrad
Analyse van de community wees op ononderbreekbare I/O-slaap
Een communitylid stelde dat het proces waarschijnlijk vastzat in de Linux-D-status, een ononderbreekbare wachttoestand die meestal met I/O wordt geassocieerd. De oorspronkelijke poster meldde daarna dat zelfs een directe SIGKILL het proces niet liet verdwijnen, wat overeenkomt met een proces dat binnen de kernel geblokkeerd is.
Dit is een sterke aanwijzing voor het oplossen van problemen, maar in de thread kwam nooit een bevestiging van IceWhale Engineering. Daarom moet dit worden beschreven als een diagnose van de community, niet als een bewezen kernelregressie in ZimaOS.
Hoog cachegebruik werd waargenomen, maar niet als oorzaak bewezen
Linux gebruikt normaal gesproken vrij RAM voor de bestandssysteemcache, dus een groot cachegetal wijst niet automatisch op een geheugenlek.
Waarom het wijzigen van qBittorrent-images geen uitsluitsel gaf
De gebruiker reproduceerde het probleem met meerdere varianten van qBittorrent-images en versietags. Dat maakt de theorie minder waarschijnlijk dat één specifieke containerimage verantwoordelijk was, maar het maakt nog steeds niet duidelijk of de oorzaak lag bij opslag, netwerken, virtualisatie, de kernel, Docker of een combinatie daarvan.
Dit was een geval met ZimaOS 1.5.4
De fout hoort bij een specifieke historische release. De thread bevat geen permanente oplossing en ook geen test waaruit blijkt of een latere ZimaOS-versie dit gedrag heeft verholpen. Voordat je oude, laag-niveau probleemoplossing opnieuw uitvoert, vergelijk je systeem met de huidige ZimaOS-release.
Veelgestelde vragen over een zombiecontainer van qBittorrent
Is bewezen dat qBittorrent zelf crashte?
Nee. Het ongebruikelijke was dat het proces niet meer kon worden beëindigd terwijl Docker nog steeds dacht dat de container actief was.
Wat betekent de D-status in deze context?
Het is een ononderbreekbare wachttoestand in de kernel die vaak met I/O wordt geassocieerd. Een communitylid gebruikte dit om uit te leggen waarom zelfs geforceerd beëindigen kon mislukken.
Loste het opnieuw opstarten van Docker het probleem op?
Nee, niet in het oorspronkelijke geval. Alleen een volledige herstart van de host herstelde het vastgelopen proces.
Heeft IceWhale de hoofdoorzaak bevestigd?
Nee. De oorspronkelijke poster tagde het team voor onderzoek, maar de gepubliceerde thread eindigde zonder officiële diagnose of permanente oplossing.
