「実行中」と表示されたまま停止できないDockerコンテナは、qBittorrentアプリケーションが通常どおりクラッシュするケースとは異なります。2026年2月のZimaOS 1.5.4に関するこの報告では、qBittorrentはおよそ3～6時間動作した後、ネットワーク通信がゼロになり、Dockerからコンテナを正常に停止または削除できなくなりました。
元のユーザーは、複数のqBittorrentイメージとバージョンを試し、メモリとCPUの割り当てを変更し、Dockerを再起動してコンテナを再作成しましたが、それでも同じ障害が再現しました。停止した状態を解消できたのは、ZimaOSホストを再起動することだけでした。
通信が停止した後もコンテナは実行中に見えた
ユーザーが報告したDockerエラーには、コンテナを強制終了しようとしたものの、終了イベントを受信できなかったと表示されていました。これは、通常のプロセスクラッシュとは異なる層の問題であることを示しています。
フリーズ発生時にネットワークI/Oがゼロまで低下した
コミュニティの分析では、割り込み不能なI/Oスリープが示唆された
コミュニティの回答者は、そのプロセスがLinuxのDステート、つまり通常I/Oに関連する割り込み不能な待機状態で停止していた可能性が高いと指摘しました。その後、元の投稿者は、直接SIGKILLを送ってもプロセスが消えなかったと報告しました。これは、プロセスがカーネル内部でブロックされている場合と一致します。
これはトラブルシューティング上の有力な手がかりですが、スレッドではIceWhaleのエンジニアによる確認は得られていません。そのため、これはコミュニティによる診断として説明すべきであり、ZimaOSのカーネル回帰バグであることが証明されたわけではありません。
キャッシュ使用量の多さは確認されたが、原因とは証明されていない
Linuxは通常、空いているRAMをファイルシステムキャッシュに使用するため、キャッシュの数値が大きいからといって、必ずしもメモリリークとは限りません。
qBittorrentのイメージを変更しても問題が解決しなかった理由
ユーザーは、複数のqBittorrentイメージのバリエーションとバージョンタグで問題を再現しました。これは、特定のコンテナイメージが原因だったという説を弱めますが、トリガーがストレージ、ネットワーク、仮想化、カーネル、Docker、またはそれらの相互作用のどれだったのかまでは特定できません。
これはZimaOS 1.5.4で発生した事例
この障害は、特定の過去のリリースに関するものです。スレッドには恒久的な修正方法や、後のZimaOSバージョンでこの挙動が解消されたかどうかを確認するテスト結果はありません。過去の低レベルなトラブルシューティングを再現する前に、システムを現在のZimaOSリリースと比較してください。
qBittorrentゾンビコンテナに関するよくある質問
qBittorrent自体がクラッシュしたことは証明されていますか？
いいえ。異常だったのは、Dockerがコンテナを実行中だと認識したまま、プロセスが強制終了できなくなったことです。
この場合のDステートとは何ですか？
I/Oに関連することが多い、カーネル内の割り込み不能な待機状態です。コミュニティの回答者は、強制終了さえ失敗する理由を説明するためにこの状態を用いました。
Dockerを再起動すれば解決しましたか？
元の事例では解決しませんでした。停止したプロセスを復旧できたのは、ホスト全体を再起動した場合だけでした。
IceWhaleは根本原因を確認しましたか？
いいえ。元の投稿者は調査を求めてチームをタグ付けしましたが、公開されたスレッドは公式の診断や恒久的な修正がないまま終了しています。
