Docker环境下Gunicorn gevent worker被signal 11终止如何排查

可能的原因及解决方案 #

1. gevent兼容性问题 #

• 你使用的Python 3.6版本较旧，搭配gunicorn 20.1.0和对应版本的gevent可能存在兼容性bug，尤其是gevent底层依赖的libev库在Docker的精简镜像环境下可能缺少必要的系统依赖，或者存在架构不兼容的情况。
• 解决方案：先尝试切换为默认的sync worker测试是否能正常启动，如果可以基本确认是gevent的问题。可以尝试升级gevent版本，或者在Dockerfile中提前安装libev、libevent等系统依赖，如果你使用的是alpine镜像，建议切换为debian系基础镜像，alpine的musl libc经常会导致这类C扩展的段错误。

2. 应用加载逻辑问题 #

• 你当前配置的preload_app为False，worker进程启动时才会加载应用代码，如果你的应用在初始化阶段调用了存在问题的C扩展（比如numpy、pandas、opencv等包的旧版本，或者自行编译的C扩展），在Docker环境的库版本和本地不一致时就会触发段错误。
• 解决方案：启动命令添加--preload参数，让主进程先加载应用代码，加载阶段如果有问题会直接抛出明确的错误信息，方便定位。也可以先在Docker容器内直接执行python wsgi.py跳过gunicorn启动应用，排查是否是应用本身在容器环境的启动问题。

3. 动态链接库缺失或版本不匹配 #

• 本地运行正常但Docker内报错，大概率是容器内的系统动态链接库和本地环境不一致，你的应用依赖的某些C扩展包是基于本地系统库编译的，打包到Docker内后找不到对应的库版本就会触发内存访问错误。
• 解决方案：不要直接将本地的虚拟环境打包进镜像，在Docker构建阶段执行pip install重新安装所有依赖，确保所有C扩展都是基于容器内的系统库编译的。可以执行ldd命令检查你的Python依赖的动态链接库是否存在缺失。

4. Docker资源限制问题 #

• 如果你的Docker容器分配的内存过小，应用初始化阶段申请内存失败也可能触发段错误。
• 解决方案：检查容器的内存限制配置，调高内存阈值后重试，或者在无资源限制的模式下启动容器测试是否正常。

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