“실행 중”으로 표시되지만 중지할 수 없는 Docker 컨테이너는 일반적인 qBittorrent 애플리케이션 충돌과 다릅니다. 2026년 2월 ZimaOS 1.5.4 보고서에서 qBittorrent는 약 3~6시간 동안 정상적으로 작동한 뒤 네트워크 트래픽이 0으로 떨어졌고, Docker는 더 이상 컨테이너를 정상적으로 중지하거나 삭제할 수 없었습니다.
사용자는 여러 qBittorrent 이미지와 버전을 시도하고, 메모리 및 CPU 할당을 변경하고, Docker를 재시작하고, 컨테이너를 다시 생성했지만 동일한 문제가 계속 재현되었습니다. 멈춘 상태를 해제한 유일한 방법은 ZimaOS 호스트를 재부팅하는 것이었습니다.
활동이 중단된 후에도 컨테이너는 실행 중인 것처럼 보였습니다
사용자가 확인한 Docker 오류에는 컨테이너를 종료하려 했지만 종료 이벤트를 받지 못했다는 내용이 표시되었습니다. 이는 일반적인 프로세스 충돌과는 다른 계층의 문제임을 시사합니다.
멈춤이 발생했을 때 네트워크 I/O가 0으로 떨어졌습니다
커뮤니티 분석에서는 인터럽트할 수 없는 I/O 대기 상태를 지목했습니다
커뮤니티의 한 응답자는 프로세스가 Linux의 D 상태에 빠졌을 가능성이 높다고 설명했습니다. D 상태는 일반적으로 I/O와 관련된 인터럽트할 수 없는 대기 상태입니다. 이후 원 게시자는 직접 SIGKILL을 보내도 프로세스가 사라지지 않았다고 보고했는데, 이는 프로세스가 커널 내부에서 차단된 상태와 일치합니다.
이는 문제 해결에 유용한 강력한 단서이지만, 해당 스레드에서는 IceWhale 엔지니어의 확인이 이루어지지 않았습니다. 따라서 이는 입증된 ZimaOS 커널 회귀 버그가 아니라 커뮤니티의 진단으로 설명해야 합니다.
높은 캐시 사용량은 관찰되었지만 원인으로 입증되지는 않았습니다
Linux는 일반적으로 사용 가능한 RAM을 파일 시스템 캐시로 활용하므로, 캐시 수치가 높다고 해서 자동으로 메모리 누수를 의미하지는 않습니다.
qBittorrent 이미지를 변경해도 문제가 해결되지 않은 이유
사용자는 여러 qBittorrent 이미지 변형과 버전 태그에서 문제를 재현했습니다. 이는 특정 컨테이너 이미지가 원인이었다는 가설을 약화시키지만, 원인이 스토리지, 네트워크, 가상화, 커널, Docker 또는 이들 간의 상호작용 중 무엇인지는 여전히 밝혀 주지 못합니다.
이 사례는 ZimaOS 1.5.4에서 발생했습니다
이 문제는 특정 과거 릴리스에 해당합니다. 스레드에는 영구적인 해결책이나 이후 ZimaOS 버전에서 이 현상이 제거되었는지 확인한 테스트가 없습니다. 과거의 저수준 문제 해결 방법을 다시 시도하기 전에 현재 ZimaOS 릴리스와 시스템을 비교해 보세요.
qBittorrent 좀비 컨테이너 FAQ
qBittorrent 자체가 충돌한 것으로 확인되었나요?
아니요. 특이한 점은 Docker가 컨테이너가 실행 중이라고 인식하는 동안에도 프로세스를 종료할 수 없게 되었다는 것입니다.
이 상황에서 D 상태란 무엇인가요?
일반적으로 I/O와 관련된 인터럽트할 수 없는 커널 대기 상태입니다. 커뮤니티 응답자는 강제 종료조차 실패한 이유를 설명하기 위해 이 상태를 언급했습니다.
Docker를 재시작하면 해결되었나요?
원래 사례에서는 해결되지 않았습니다. 멈춘 프로세스를 복구한 방법은 호스트 전체를 재부팅하는 것뿐이었습니다.
IceWhale이 근본 원인을 확인했나요?
아니요. 원 게시자는 조사를 요청하기 위해 팀을 태그했지만, 게시된 스레드는 공식 진단이나 영구적인 해결책 없이 종료되었습니다.
