Un conteneur Docker qui reste marqué comme « en cours d’exécution » mais qui ne peut pas être arrêté est différent d’un plantage normal de l’application qBittorrent. Dans ce rapport de février 2026 concernant ZimaOS 1.5.4, qBittorrent a fonctionné pendant environ trois à six heures, puis le trafic réseau est tombé à zéro, et Docker n’a plus pu arrêter ni supprimer proprement le conteneur.
L’utilisateur à l’origine du rapport a essayé plusieurs images et versions de qBittorrent, modifié les allocations de mémoire et de processeur, redémarré Docker, recréé le conteneur, mais a tout de même reproduit le même problème. Le redémarrage de l’hôte ZimaOS a été la seule action permettant de supprimer l’état bloqué.
Le conteneur semblait toujours fonctionner après l’arrêt de l’activité
L’erreur Docker signalée par l’utilisateur indiquait qu’il avait tenté de tuer le conteneur, mais n’avait reçu aucun événement de sortie. Cela suggère un problème situé à un autre niveau qu’un simple plantage de processus.
Les entrées-sorties réseau sont tombées à zéro au moment du blocage
L’analyse de la communauté a évoqué une attente d’entrées-sorties non interruptible
Un membre de la communauté a estimé que le processus était probablement bloqué dans l’état D de Linux, une attente non interruptible généralement associée aux entrées-sorties. L’auteur du rapport a ensuite indiqué qu’un SIGKILL direct ne faisait même pas disparaître le processus, ce qui est cohérent avec un processus bloqué dans le noyau.
Il s’agit d’un indice de dépannage important, mais le sujet n’a jamais reçu de confirmation de la part des ingénieurs d’IceWhale. Il faut donc parler d’un diagnostic de la communauté, et non d’une régression avérée du noyau de ZimaOS.
Une utilisation élevée du cache a été observée, sans qu’il soit prouvé qu’elle soit la cause
Linux utilise normalement la mémoire vive autrement libre pour le cache du système de fichiers. Une valeur de cache élevée n’est donc pas automatiquement le signe d’une fuite mémoire.
Pourquoi le changement d’images qBittorrent n’a pas permis de trancher
L’utilisateur a reproduit le problème avec plusieurs variantes d’images qBittorrent et plusieurs balises de version. Cela affaiblit l’hypothèse selon laquelle une seule image de conteneur serait responsable, mais ne permet toujours pas de déterminer si le déclencheur était lié au stockage, au réseau, à la virtualisation, au noyau, à Docker ou à une interaction entre ces éléments.
Il s’agissait d’un cas concernant ZimaOS 1.5.4
Le problème concernait une version historique précise. Le sujet ne contient aucun correctif définitif ni aucun test indiquant si une version ultérieure de ZimaOS a supprimé ce comportement. Avant de reproduire d’anciennes procédures de dépannage bas niveau, comparez votre système avec la version actuelle de ZimaOS.
FAQ sur le conteneur zombie de qBittorrent
Est-il prouvé que qBittorrent lui-même a planté ?
Non. Le point inhabituel était que le processus était impossible à tuer alors que Docker pensait toujours que le conteneur fonctionnait.
Que signifie l’état D dans ce contexte ?
Il s’agit d’une attente non interruptible dans le noyau, généralement associée aux entrées-sorties. Un membre de la communauté s’en est servi pour expliquer pourquoi même une terminaison forcée pouvait échouer.
Le redémarrage de Docker a-t-il résolu le problème ?
Non, dans le cas décrit. Seul un redémarrage complet de l’hôte a permis de récupérer le processus bloqué.
IceWhale a-t-il confirmé la cause première ?
Non. L’auteur du rapport a identifié l’équipe pour demander une analyse, mais le sujet publié s’est terminé sans diagnostic officiel ni correctif définitif.
