gunicorn 是安装在 virtualenv 内部还是外部？

里面。 到目前为止，我认为这是一个应用程序问题，因为当我丢弃大部分设置时，gunicorn 会启动，只是在查看该输出时您无法判断出什么问题。

尝试使用“--debug --log-level debug”。 看看你是否得到更多信息。

恐怕这是带有调试日志级别的输出

：失望的：
我不确定发生了什么。 在“引导工作人员”消息之后，如果出现问题，我希望看到“工作进程中的异常”。 刚刚过了午夜，但我会继续睡，也许能想出点什么。

谢谢老兄，如果我自己弄明白了，我会告诉你的。 我现在正在通过 settings.py 打开东西，直到我再次遇到错误。 老派调试:)

@benoitc为什么log.exception不起作用？

我通常不喜欢使用那个，因为如果有意义的话，这只是 Python 的东西。

调试声音在那里更合适。 真正的补充是回溯:)

实际上我有一个类似的问题，我认为这与日志文件的写权限有关。 如果我使日志文件（stderr 和 stdout）可公开写入，它似乎工作正常。 所以我想这让我想到了当你第一次从 su​​pervisord 启动 gunicorn 时，日志文件是在 gunicorn 接管之前在 root 下创建的。 管理确保日志文件由 gunicorn 创建而不是由 supervisord 创建的最佳方法是什么？

你如何发射 gunicorn？ 你用最后一个头复制它吗？

我用supervisord启动它。 这是我用于 supervisord 的 gunicorn 配置：

[程序：sliceweb]
目录 = /opt/src/slicephone/webapp/webapp/
命令 = /opt/src/slicephone/webapp/scripts/gunicorn.sh
stdout_logfile = /opt/logs/supervisord.stdout.log
stderr_logfile = /opt/logs/supervisord.stderr.log

和实际的 gunicorn 脚本（注意我是如何将日志文件触摸和 chown 给 gunicorn 用户/组的）：

!/bin/bash

设置 -e
DATASTORE_SOFTWARE="XXXXX"
ACCESS_LOGFILE=/opt/logs/gunicorn.slice.access.log
ERROR_LOGFILE=/opt/logs/gunicorn.slice.error.log
LOGFILE=/opt/logs/gunicorn.slice.log
LOGDIR=$(目录名 $LOGFILE)
WEBAPPDIR=$(目录名$0)/../
NUM_WORKERS=3
DEBUG_FLAGS="--debug --log-level debug"

用户/组作为运行

用户=www-数据
GROUP=www-数据
cd $WEBAPPDIR/webapp
测试 -d $LOGDIR || mkdir -p $LOGDIR
回声 WebAppDir：$WEBAPPDIR
回声“用户：$ USER”
回声“组：$ GROUP”

触摸 $ACCESS_LOGFILE $ERROR_LOGFILE $LOGFILE
chown -R $USER:$GROUP $ACCESS_LOGFILE $ERROR_LOGFILE $LOGFILE

导出 DATASTORE_SOFTWARE=$DATASTORE_SOFTWARE ; exec /opt/virtenvs/django_slice/bin/gunicorn_django $DEBUG_FLAGS -w $NUM_WORKERS --user=$USER --group=$GROUP --log-level=debug --log-file=$LOGFILE --access-logfile= $ACCESS_LOGFILE --error-logfile=$ERROR_LOGFILE

关于最新头像的好问题。 pip freeze 显示它是 0.14.1（.2 是最新的不是吗？）

你解决问题了吗？ 我有同样的问题，目前我不知道如何解决这个问题。

应该可以解决的。 你运行的是哪个版本的 gunicorn？ 您能否提供有关您的配置的更多信息，以便我可以重现它？ 谢谢。

@panyam你试过 0.14.3 吗？

@benoitc抱歉，我没有在 0.14.3 上尝试过。 我设法通过让 gunicorn 用户在 supervisord 启动脚本后立即成为日志文件的所有者来使其在 0.14.1 上运行。

只是为了澄清我不认为这是一个gunicorn问题。 @anyeguyue - 检查这个的最佳位置是查看 supervisord 日志或 gunicorn 日志（通常在 /var/log/gunicorn/....），看看那里是否有“权限被拒绝”错误。

我刚刚遇到了同样的问题，首先通过导致错误的“python manage.py syncdb”解决了。 修复该设置问题后，gunicorn 工作（重新启动 nginx 后）。

我也解决了这个问题，但方式不同。 gunicorn_django文件的第一行是“#!/opt/django/env/mysite/bin/python”，是我的虚拟环境python路径。 将其替换为“#!/usr/bin/env python”解决了问题，虽然他们都使用了相同的python解释器，但是有一些PYTHONPATH差异，这就是之前失败的原因。

@anyeguyue我在 gunicorn 0.14.5 和 Django 1.4 上遇到了同样的问题，但症状更糟： gunicorn_django -b 0.0.0.0:8000拒绝运行。 您的修复有效，并且非常明显：您应该始终询问/usr/bin/env哪个python ！ 谢谢。

@asimihsan，乐于助人

我也有这个问题。 结果发现我的代码中存在错误导入的问题。 如果您想调试，请尝试运行 gunicorn_django --preload - 这有望吐出正确的异常。

对于任何面临同样问题的人来说，问题通常出在 django 本身。
激活你的 venv 并运行 ./manage.py runserver

这通常会为您提供更详细的错误消息。

:+1: @fergalmoran帮我解决了我的问题（这是 PIL 的问题）

我也遇到了同样的问题。。。不知道怎么解决

@pythdasch这里讨论了几个不同的问题。 如果您可以提供更多信息，请打开一个新票证，或者简单地向邮件列表发送消息，其他人可能会帮助您调试。

我想我们在#gunicorn 上解决了@pythdasch的问题。 @pythdasch ，你能确认一下吗？

我确认，感谢 berker :)

我的 wsgi 与我的 manage.py 位于同一文件夹中，因此我必须放置路径wsgi:application而不是 project。 wsgi：应用程序

（这是 wsgi 的错误路径。在这种情况下需要是 wsgi:application 而不是 project.wsgi:application）

@tilgovi是的，对不起，我去了 irc 频道 gunicorn 来解决它:)

我昨天遇到了同样的问题，gunicorn 0.18 和以下调用：

gunicorn 'app:create_app()' --name X --workers 5 --user=apprunner --group=apprunner --bind='0.0.0.0:5000' --log-config=resource/config/di/logging.conf --timeout=360 --debug --log-level debug

这是由于我的 Flask 应用程序中的导入错误。 这里的要点是，如果工作程序在启动时崩溃，gunicorn 不会显示来自应用程序的回溯，因此我必须手动启动 Flask 应用程序以查看实际问题。

我想知道我们是否可以让它显示实际的回溯

这将是非常好的。 IMO，下一个最好的事情是，如果无法显示原始回溯，将包含一条建议直接运行应用程序的消息，而不是使用 gunicorn，以查找实际错误。

如果我正确理解了问题，Gunicorn 已经显示了诸如 ImportError 之类的异常消息：

$ gunicorn a:app --error-logfile=- --access-logfile=-
[2014-12-10 17:13:31 +0000] [12176] [INFO] Starting gunicorn 19.2.0
[2014-12-10 17:13:31 +0000] [12176] [INFO] Listening at: http://127.0.0.1:8000 (12176)
[2014-12-10 17:13:31 +0000] [12176] [INFO] Using worker: sync
[2014-12-10 17:13:31 +0000] [12181] [INFO] Booting worker with pid: 12181
[2014-12-10 17:13:31 +0000] [12181] [ERROR] Exception in worker process:
Traceback (most recent call last):
  File "/home/berker/projects/gunicorn/gunicorn/arbiter.py", line 517, in spawn_worker
    worker.init_process()
  File "/home/berker/projects/gunicorn/gunicorn/workers/base.py", line 117, in init_process
    self.wsgi = self.app.wsgi()
  File "/home/berker/projects/gunicorn/gunicorn/app/base.py", line 67, in wsgi
    self.callable = self.load()
  File "/home/berker/projects/gunicorn/gunicorn/app/wsgiapp.py", line 65, in load
    return self.load_wsgiapp()
  File "/home/berker/projects/gunicorn/gunicorn/app/wsgiapp.py", line 52, in load_wsgiapp
    return util.import_app(self.app_uri)
  File "/home/berker/projects/gunicorn/gunicorn/util.py", line 355, in import_app
    __import__(module)
  File "/home/berker/projects/testdjango/a.py", line 1, in <module>
    from flask import Flask
ImportError: No module named flask

和其他类型的错误消息：

$ gunicorn a:app --error-logfile=- --access-logfile=-
[2014-12-10 17:18:52 +0000] [12294] [INFO] Starting gunicorn 19.2.0
[2014-12-10 17:18:52 +0000] [12294] [ERROR] Connection in use: ('127.0.0.1', 8000)
[2014-12-10 17:18:52 +0000] [12294] [ERROR] Retrying in 1 second.
[2014-12-10 17:18:53 +0000] [12294] [ERROR] Connection in use: ('127.0.0.1', 8000)
[2014-12-10 17:18:53 +0000] [12294] [ERROR] Retrying in 1 second.
[2014-12-10 17:18:54 +0000] [12294] [ERROR] Connection in use: ('127.0.0.1', 8000)
[2014-12-10 17:18:54 +0000] [12294] [ERROR] Retrying in 1 second.

当我尝试像这样运行应用程序时，我遇到了同样的问题：

gunicorn app:application -b localhost:3000

问题是除了文件app.py之外，还存在一个名为app的目录。 它在重命名 python 文件后工作。

@brouberol我现在也遇到了同样的问题。 当 Flask 应用程序有一些导致导入错误的模块时，Gunicorn 不会记录回溯，但 Flask 的内置服务器可以。

我们可以做的是，如果 Gunicorn 无法在任何错误日志中没有更具体的信息的情况下启动 worker，首先尝试 Flask 的内置服务器。

用 --preload 运行 guncorn 可以看到错误日志

对我来说，Django runserver工作得很好。 问题是在gunicorn.conf.py文件中导入 Django settings 。 删除该导入解决了问题。