Un contenedor de Docker que permanece marcado como «en ejecución» pero no se puede detener es diferente de un cierre inesperado normal de la aplicación qBittorrent. En este informe de febrero de 2026 sobre ZimaOS 1.5.4, qBittorrent funcionó aproximadamente entre tres y seis horas; después, el tráfico de red cayó a cero y Docker ya no pudo detener ni eliminar el contenedor correctamente.
El usuario original probó varias imágenes y versiones de qBittorrent, modificó las asignaciones de memoria y CPU, reinició Docker, recreó el contenedor y aun así reprodujo el mismo fallo. Reiniciar el sistema anfitrión con ZimaOS fue la única acción que eliminó el estado bloqueado.
El contenedor parecía estar en ejecución después de detenerse la actividad
El error de Docker informado por el usuario indicaba que intentó finalizar el contenedor, pero no recibió un evento de salida. Esto apunta a una capa diferente de la de un cierre inesperado normal del proceso.
La E/S de red cayó a cero cuando se produjo el bloqueo
El análisis de la comunidad apuntó a un estado de espera de E/S no interrumpible
Un miembro de la comunidad sostuvo que el proceso probablemente estaba bloqueado en el estado D de Linux, una espera no interrumpible normalmente asociada con la E/S. Posteriormente, el autor original informó que ni siquiera una señal SIGKILL directa hizo desaparecer el proceso, lo que coincide con un proceso bloqueado dentro del núcleo.
Esta es una pista de diagnóstico importante, pero el hilo nunca recibió una confirmación del equipo de ingeniería de IceWhale. Por tanto, debe describirse como un diagnóstico de la comunidad, no como una regresión demostrada del núcleo de ZimaOS.
Se observó un uso elevado de la caché, pero no se demostró que fuera la causa
Linux normalmente utiliza la memoria RAM que de otro modo estaría libre para la caché del sistema de archivos, por lo que una cifra elevada de caché no implica automáticamente una fuga de memoria.
Por qué cambiar las imágenes de qBittorrent no resolvió el problema
El usuario reprodujo el problema con varias variantes de imagen y etiquetas de versión de qBittorrent. Esto debilita la teoría de que una sola imagen del contenedor fuera la responsable, pero aún no identifica si el desencadenante fue el almacenamiento, la red, la virtualización, el núcleo, Docker o una interacción entre varios de estos componentes.
Este fue un caso de ZimaOS 1.5.4
El fallo corresponde a una versión histórica específica. El hilo no contiene una solución permanente ni una prueba que indique si una versión posterior de ZimaOS eliminó este comportamiento. Antes de reproducir procedimientos antiguos de diagnóstico de bajo nivel, compara tu sistema con la versión actual de ZimaOS.
Preguntas frecuentes sobre el contenedor zombi de qBittorrent
¿Se demostró que qBittorrent se estaba cerrando inesperadamente?
No. Lo inusual fue que el proceso se volviera imposible de finalizar mientras Docker seguía creyendo que el contenedor estaba en ejecución.
¿Qué significa el estado D en este contexto?
Es una espera no interrumpible dentro del núcleo, comúnmente asociada con la E/S. Un miembro de la comunidad lo utilizó para explicar por qué incluso la finalización forzada podía fallar.
¿Reiniciar Docker lo solucionó?
No en el caso original. Solo un reinicio completo del sistema anfitrión recuperó el proceso bloqueado.
¿IceWhale confirmó la causa principal?
No. El autor original mencionó al equipo para solicitar una investigación, pero el hilo publicado terminó sin un diagnóstico oficial ni una solución permanente.
