我之前帮不少开发者排查过这类部署后的SystemExit:1问题，结合你用的Python3.6+Django+Gunicorn+Supervisor技术栈，大概率是以下几个方向出了问题：

• Gunicorn启动配置错误
  最常见的坑是WSGI应用路径写错了，比如你启动命令里写的gunicorn myproject.wsgi:application，但实际你的Django项目的wsgi.py不在myproject目录下，或者文件名拼写错误。另外如果绑定的端口被其他进程（比如Nginx、其他服务）占用，Gunicorn启动失败就会抛出SystemExit:1。还有worker数量设置得远超服务器CPU核心数，也可能导致启动异常。

• Django项目初始化失败
  比如settings.py里的数据库配置有误：密码错误、数据库主机无法连接、目标数据库不存在，Django启动时连不上数据库会直接退出。另外如果没执行python manage.py collectstatic，部分生产环境配置下Django会因找不到静态文件路径报错退出；如果SECRET_KEY没正确设置（比如环境变量未加载），Django启动也会失败。还要检查项目代码是否有语法错误，比如某个app的models.py或views.py存在语法问题，启动时导入失败也会触发这个错误。

• Supervisor配置的权限或路径问题
  比如Supervisor使用的运行用户没有项目目录的读写权限，或者Gunicorn的命令路径写错了（比如你用了虚拟环境，但配置里没写虚拟环境的绝对路径，比如/home/youruser/venv/bin/gunicorn，而是直接写gunicorn，系统找不到命令就会退出）。另外Supervisor的日志目录如果没有写入权限，Gunicorn启动时无法写入日志也可能导致退出。

• 依赖缺失或版本兼容问题
  本地测试没问题，但部署到服务器后可能漏装了某些依赖包，Django启动时导入失败就会退出。另外Python3.6版本较老，部分新的Django版本（比如Django3.2+）虽支持3.6，但可能存在隐性兼容问题，导致启动失败。

• 端口权限问题
  如果Gunicorn绑定了80、443这类1024以下的端口，而运行Gunicorn的用户不是root，就会因没有端口绑定权限启动失败，抛出SystemExit:1。这种情况要么改用root用户运行（不推荐），要么改成绑定8000、8080这类高位端口，再通过Nginx反向代理。

排查小技巧 #

可以先手动在服务器上运行Gunicorn的启动命令，比如：

cd /path/to/your/project && /path/to/venv/bin/gunicorn yourproject.wsgi:application --bind 0.0.0.0:8000

直接查看终端输出的具体错误信息，比Sentry的泛泛提示更有用。另外也可以查看Supervisor的日志文件（一般在/var/log/supervisor/目录下），里面会记录更详细的启动失败原因。

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