为啥我的 gunicorn Python/Flask 工作人员退出信号项？

Posted 2023-03-04

【中文标题】为啥我的 gunicorn Python/Flask 工作人员退出信号项？

【英文标题】：Why are my gunicorn Python/Flask workers exiting from signal term?为什么我的 gunicorn Python/Flask 工作人员退出信号项？

【发布时间】：2017-08-23 14:44:24

【问题描述】：

我有一个 Python/Flask Web 应用程序，我通过 Gunicorn 在 Amazon ECS 上的 docker 映像中部署它。一切都很顺利，然后突然间，包括最后一次成功的请求，我在日志中看到了这一点：

[2017-03-29 21:49:42 +0000] [14] [DEBUG] GET /heatmap_column/e4c53623-2758-4863-af06-91bd002e0107/ADA [2017-03-29 21:49:43 +0000] [1] [INFO] Handling signal: term [2017-03-29 21:49:43 +0000] [14] [INFO] Worker exiting (pid: 14) [2017-03-29 21:49:43 +0000] [8] [INFO] Worker exiting (pid: 8) [2017-03-29 21:49:43 +0000] [12] [INFO] Worker exiting (pid: 12) [2017-03-29 21:49:43 +0000] [10] [INFO] Worker exiting (pid: 10) ... [2017-03-29 21:49:43 +0000] [1] [INFO] Shutting down: Master

进程终止，程序退出。 ECS重启服务，docker镜像再次运行，但同时服务中断。

什么会导致我的程序获得 TERM 信号？我在网上找不到任何关于这种情况的参考资料。请注意，这只发生在 ECS 上的 Docker 中，而不是本地。

【问题讨论】：

尝试检查您的docker logs。

【参考方案1】：

事实证明，在向系统添加登录页面后，健康检查得到了 302 重定向到 /login at /，这导致健康检查失败。所以容器被定期杀死。亚马逊支持很棒！

【讨论】：

没有办法给 2 票，但是谢谢你，你是一个活生生的救星。

【参考方案2】：

要添加到 rjurney 的评论，在 ECS 的 AWS 控制台上，您可以通过检查在您的 ECS 集群下运行的服务的事件选项卡来检查应用程序的状态。这就是我发现健康检查失败和其他问题的方式。

【参考方案3】：

虽然不适用于问题中的问题，但这种行为可能是由容器编排（即 Kubernetes）等外部系统引起的。

例如，

启动成本高的镜像构建的 pod 启动 活性探测超时 Kubernetes 发送 sig term 以优雅地停止容器

在 Kubernetes 场景中，一种解决方案可能是调整 liveness 或就绪探测配置以允许更长的启动时间。

【参考方案4】：

对我来说，事实证明，工人正在退出，因为我的 Docker Swarm 堆栈中的一个容器反复失败，导致回滚过程。 gunicorn 进程在回滚过程开始时收到信号“term”。