Ein Docker-Container, der weiterhin als „running“ markiert ist, sich aber nicht stoppen lässt, unterscheidet sich von einem normalen Absturz der qBittorrent-Anwendung. In diesem Bericht zu ZimaOS 1.5.4 vom Februar 2026 lief qBittorrent etwa drei bis sechs Stunden, anschließend fiel der Netzwerkverkehr auf null, und Docker konnte den Container nicht mehr ordnungsgemäß stoppen oder entfernen.
Der ursprüngliche Nutzer probierte mehrere qBittorrent-Images und -Versionen aus, änderte die Speicher- und CPU-Zuweisungen, startete Docker neu, erstellte den Container neu und konnte den Fehler dennoch weiterhin reproduzieren. Nur ein Neustart des ZimaOS-Hosts beseitigte den festgefahrenen Zustand.
Der Container wirkte weiterhin aktiv, nachdem die Aktivität beendet war
Die von Docker gemeldete Fehlermeldung besagte, dass versucht wurde, den Container zu beenden, jedoch kein Exit-Ereignis empfangen wurde. Das deutet auf eine andere Ebene als einen normalen Prozessabsturz hin.
Die Netzwerk-E/A fiel beim Auftreten des Einfrierens auf null
Die Community-Analyse deutete auf einen nicht unterbrechbaren E/A-Schlafzustand hin
Ein Mitglied der Community vermutete, dass der Prozess im Linux-D-State festhing, einem nicht unterbrechbaren Wartezustand, der normalerweise mit E/A-Vorgängen verbunden ist. Der ursprüngliche Verfasser berichtete anschließend, dass selbst ein direktes SIGKILL den Prozess nicht verschwinden ließ, was zu einem innerhalb des Kernels blockierten Prozess passt.
Das ist ein wichtiger Hinweis für die Fehlersuche, doch im Thread gab es keine Bestätigung durch die IceWhale-Entwicklung. Daher sollte dies als Diagnose der Community und nicht als bewiesener ZimaOS-Kernelregress beschrieben werden.
Eine hohe Cache-Nutzung wurde beobachtet, aber nicht als Ursache nachgewiesen
Linux verwendet normalerweise ansonsten freien Arbeitsspeicher für den Dateisystem-Cache. Eine große Cache-Anzeige ist daher nicht automatisch ein Speicherleck.
Warum der Wechsel der qBittorrent-Images das Problem nicht klärte
Der Nutzer konnte das Problem mit mehreren qBittorrent-Image-Varianten und Versions-Tags reproduzieren. Dadurch wird die Theorie abgeschwächt, dass ein einzelnes Container-Image verantwortlich war. Es lässt sich dadurch jedoch weiterhin nicht feststellen, ob der Auslöser im Speicher, Netzwerk, in der Virtualisierung, im Kernel, in Docker oder im Zusammenspiel mehrerer dieser Komponenten lag.
Dies war ein Fall unter ZimaOS 1.5.4
Der Fehler gehört zu einer bestimmten historischen Version. Der Thread enthält weder eine dauerhafte Lösung noch einen Test, der zeigt, ob eine spätere ZimaOS-Version dieses Verhalten beseitigt hat. Bevor Sie die alte, systemnahe Fehlersuche reproduzieren, vergleichen Sie Ihr System mit der aktuellen ZimaOS-Version.
FAQ zu Zombie-Containern mit qBittorrent
Wurde nachgewiesen, dass qBittorrent selbst abstürzte?
Nein. Ungewöhnlich war, dass der Prozess nicht beendet werden konnte, während Docker weiterhin davon ausging, dass der Container ausgeführt wurde.
Was bedeutet D-State in diesem Zusammenhang?
Es handelt sich um einen nicht unterbrechbaren Kernel-Wartezustand, der häufig mit E/A-Vorgängen verbunden ist. Ein Mitglied der Community nutzte ihn, um zu erklären, warum selbst eine erzwungene Beendigung fehlschlagen konnte.
Hat ein Neustart von Docker das Problem gelöst?
Nein, nicht im ursprünglichen Fall. Erst ein vollständiger Neustart des Hosts stellte den festgefahrenen Prozess wieder her.
Hat IceWhale die Ursache bestätigt?
Nein. Der ursprüngliche Verfasser markierte das Team zur Untersuchung, doch der veröffentlichte Thread endete ohne offizielle Diagnose oder dauerhafte Lösung.
