使用Gunicorn部署Django时Worker无日志持续退出问题

当前日志输出 #

Sep 9 05:57:41 PM  [2023-09-09 22:57:41 +0000] [52] [INFO] Starting gunicorn 20.1.0
Sep 9 05:57:41 PM  [2023-09-09 22:57:41 +0000] [52] [INFO] Listening at: http://0.0.0.0:10000 (52)
Sep 9 05:57:42 PM  [2023-09-09 22:57:42 +0000] [52] [INFO] Using worker: sync
Sep 9 05:57:42 PM  [2023-09-09 22:57:42 +0000] [53] [INFO] Booting worker with pid: 53
Sep 9 05:57:42 PM  [2023-09-09 22:57:42 +0000] [54] [INFO] Booting worker with pid: 54
Sep 9 05:57:42 PM  [2023-09-09 22:57:42 +0000] [55] [INFO] Booting worker with pid: 55
Sep 9 05:57:42 PM  [2023-09-09 22:57:42 +0000] [56] [INFO] Booting worker with pid: 56
Sep 9 06:08:06 PM  [2023-09-09 23:08:06 +0000] [52] [INFO] Handling signal: term
Sep 9 06:08:06 PM  [2023-09-09 23:08:06 +0000] [53] [INFO] Worker exiting (pid: 53)
Sep 9 06:08:06 PM  [2023-09-09 23:08:06 +0000] [54] [INFO] Worker exiting (pid: 54)
Sep 9 06:08:06 PM  [2023-09-09 23:08:06 +0000] [55] [INFO] Worker exiting (pid: 55)
Sep 9 06:08:06 PM  [2023-09-09 23:08:06 +0000] [56] [INFO] Worker exiting (pid: 56)
Sep 9 06:08:12 PM  [2023-09-09 23:08:12 +0000] [52] [INFO] Shutting down: Master

排查步骤 #

• 强制输出worker错误日志：修改启动命令，把worker的错误输出定向到本地文件，同时拉满日志级别：

  gunicorn wsgi:application --log-level debug --error-logfile ./gunicorn_error.log
  

  这样worker启动失败的错误会被持久化到文件，不会随进程退出丢失。

• 直接测试WSGI入口：手动运行wsgi.py，验证应用本身是否能正常启动，排查导入错误或配置问题：

  python wsgi.py
  

  如果有依赖缺失、配置错误等问题，这里会直接输出报错信息。

• 核对依赖环境：检查当前运行环境的依赖包是否齐全，版本是否匹配，必要时重新安装：

  pip install -r requirements.txt
  

• 单worker模式测试：暂时只启动1个worker，排除多worker资源竞争或冲突问题：

  gunicorn wsgi:application --workers 1 --log-level debug
  

• 检查系统终止信号原因：日志里出现Handling signal: term，说明主进程收到了终止信号，可能是系统OOM（内存不足）或平台自动重启机制导致。可以查看系统日志（比如/var/log/syslog或dmesg）确认是否有资源耗尽的记录。

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