Docker容器处于Running状态却僵死无响应的排查求助

核心可能原因 #

• 不可中断睡眠状态（D状态）：进程被内核阻塞（如等待磁盘IO、无超时的网络调用），此时进程脱离用户态，完全不响应信号，这是最常见的僵死原因。
• PID 1信号处理问题：若Python进程是容器的PID 1，Docker默认下PID 1会忽略SIGTERM等信号，导致无法通过常规方式终止。
• 无超时的阻塞操作：代码中存在未设置超时的IO调用（如socket接收、数据库连接、子进程等待），触发永久阻塞。
• 存储/网络故障：容器挂载的磁盘（如NFS、绑定卷）IO hang，或网络链路中断导致进程等待响应。

分步排查步骤 #

1. 确认进程状态
   在主机上执行ps -aux | grep <python进程PID>，观察STAT列：

   • 若显示D，则进程处于不可中断睡眠，卡在内核态操作。
   • 若显示R/S但无响应，可能是用户态死锁或资源耗尽。

2. 抓取进程堆栈

   • 主机安装gdb后，执行gdb -p <python进程PID> --batch -ex "thread apply all bt"，获取全线程堆栈，定位阻塞的系统调用或代码位置。
   • 若无法直接操作容器，可在主机上执行上述命令（容器启动时需加--pid=host共享主机PID namespace，否则先进入容器再执行）。

3. 检查资源与系统日志

   • 用docker stats <容器ID>实时监控CPU、内存占用，排查是否因OOM或CPU耗尽导致假死；查看主机dmesg日志，确认是否有OOM killer触发记录。
   • 查看主机/var/log/syslog或journalctl，排查磁盘IO错误、网络故障（如网卡离线、NFS服务器中断）。

4. 追踪系统调用
   执行strace -p <python进程PID>，查看进程最后卡住的系统调用（如read、write、connect），定位阻塞来源。

5. 验证代码逻辑

   • 检查所有IO操作是否设置超时：如socket.settimeout()、数据库连接超时、subprocess.run(timeout=...)。
   • 确认是否存在子进程僵死：用ps auxf查看进程树，若子进程处于D状态，会导致父进程无限等待。

针对性解决方向 #

• 处理PID 1信号问题：

  • 在Dockerfile中使用tini作为init进程：ENTRYPOINT ["tini", "--", "python", "your_script.py"]，由tini负责转发信号给Python进程。
  • 若Python作为PID 1，需在代码中显式注册信号处理函数（如signal.signal(signal.SIGTERM, handler)）。

• 消除无超时阻塞：给所有可能阻塞的操作添加超时逻辑，避免永久等待。

• 启用Python故障处理：在代码开头添加import faulthandler; faulthandler.enable()，发送kill -SIGUSR1 <PID>可强制打印堆栈（非D状态下有效）。

• 排查存储健康：检查挂载卷的存储设备状态，替换故障磁盘或修复NFS连接。

内容的提问来源于stack exchange，提问作者Yinon_90