gunicornはvirtualenvの内部または外部にインストールされていますか？

中身。 ほとんどの設定を破棄するとgunicornが起動するため、今ではアプリの問題だと思います。その出力を見たときに何が失敗しているかがわからないだけです。

「--debug--log-leveldebug」を試してください。 さらに情報が得られるかどうかを確認してください。

これは私が恐れているデバッグログレベルの出力です

：残念だった：
まだ何が起こっているのかわかりません。 「Bootingworker」メッセージの後に、問題がある場合は「Exception inworkerprocess」が表示されると思います。 ここは真夜中過ぎですが、寝て何か思いつくかもしれません。

ありがとう、私がそれを自分で理解したら、私はあなたに知らせます。 私は今、再びエラーが発生するまで、settings.pyをオンにして作業しています。 古い学校のデバッグ:)

@benoitc log.exceptionが機能しなかったのはなぜですか？

それが理にかなっているなら、これは単なるPythonのものなので、私は一般的にそれを使用するのは好きではありません。

そこでより適切なデバッグサウンド。 本当の追加はトレースバックです:)

実際、私は同様の問題を抱えており、ログファイルへの書き込み権限に関係していると思います。 ログファイル（stderrとstdout）を公開して書き込み可能にすると、正常に機能しているように見えます。 ですから、監督からgunicornを最初に起動したとき、gunicornが引き継ぐ前にログファイルがルートの下に作成されるという質問に私を連れて来ると思います。 ログファイルが監視対象ではなくgunicornによって作成されていることを確認するための最良の方法は何ですか？

どのようにgunicornを起動しますか？ 最後の頭で再現しますか？

スーパーバイザーで起動します。 これが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スクリプト（ログファイルをgunicornユーザー/グループにタッチしてchownする方法に注意してください）：

！/ bin / bash

set -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 = $（dirname $ LOGFILE）
WEBAPPDIR = $（dirname $ 0）/../
NUM_WORKERS = 3
DEBUG_FLAGS = "-debug --log-level debug"

実行するユーザー/グループ

USER = www-data
GROUP = www-data
cd $ WEBAPPDIR / webapp
test -d $ LOGDIR || mkdir -p $ LOGDIR
エコーWebAppDir：$ WEBAPPDIR
echo "ユーザー：$ USER"
echo "Group：$ GROUP"

$ ACCESS_LOGFILE $ ERROR_LOGFILE $ LOGFILEをタッチします
chown -R $ USER：$ GROUP $ ACCESS_LOGFILE $ ERROR_LOGFILE $ LOGFILE

export 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

最新の頭についての良い質問。 pipfreezeは0.14.1であることを示しています（.2は最新ではありませんか？）

あなたは問題を解決しましたか？ 私は同じ問題を抱えていますが、現在、これを解決する方法がわかりません。

はい、解決する必要があります。 どのバージョンのgunicornを実行していますか？ 構成を再現できるように、構成に関する詳細情報を教えていただけますか？ ありがとう。

@panyam 0.14.3で試しましたか？

@benoitc申し訳ありませんが、0.14.3では試していません。 スーパーバイザーがスクリプトを開始するとすぐに、gunicornユーザーをログファイルの所有者にすることで、0.14.1で動作させることができました。

明確にするために、これはgunicornの問題ではないと思います。 @ anyeguyue-これを確認するのに最適な場所は、監視対象ログまたはgunicornログ（通常は/ var / log / gunicorn / ....）を調べて、そこに「許可が拒否されました」エラーがあるかどうかを確認することです。

同じ問題が発生しましたが、最初の「python manage.py syncdb」で解決され、エラーが発生しました。 その設定の問題を修正した後、gunicornは機能しました（nginxを再起動した後）。

私もこの問題を解決しましたが、別の方法で解決しました。 gunicorn_djangoファイルの最初の行は「＃！/ opt / django / env / mysite / bin / python」でした。これは、私のvirtualenviromentpythonパスのパスです。 問題は「＃！/ usr / bin / envpython」に置き換えることで解決しましたが、どちらも同じpythonインタープリターを使用していましたが、PYTHONPATHにいくつかの違いがあるため、以前は失敗していました。

@anyeguyue gunicorn0.14.5とgunicorn_django -b 0.0.0.0:8000は実行を拒否しました。 修正は機能し、非常に明白です。常に/usr/bin/envどのpythonを使用するかを尋ねる必要があります。 ありがとう。

@ asimihsan、お役に立ててうれしい

私もこの問題を抱えていました。 私のコードの間違ったインポートに問題があったことがわかりました。 デバッグしたい場合は、gunicorn_django --preloadを実行してみてください。これにより、適切な例外が発生することが期待されます。

同じ問題に直面している人にとって、問題は通常django自体にあるものです。
venvをアクティブにして、。/ manage.pyrunserverを実行します

これにより、通常、より詳細なエラーメッセージが表示されます。

：+1： @fergalmoran問題の解決に

私は同じ問題に直面しています...そしてそれを解決する方法がわかりません

@pythdaschここで話されているいくつかの異なる問題があります。 さらに情報を提供できる場合は、新しいチケットを開くか、メーリングリストにメッセージを送信してください。他の人がデバッグに役立つ場合があります。

#gunicornで@pythdaschの問題を解決したと思います。 @pythdasch 、確認できますか？

確認します、berkerのおかげで:)

私のwsgiはmanage.pyと同じフォルダーにあったので、プロジェクトではなくパスwsgi：applicationを配置するwsgi：application

（これはwsgiへの間違ったパスでした。この場合、project.wsgi：applicationではなくwsgi：applicationである必要がありました）

@tilgoviはい申し訳ありませんが私はそれを解決するためにircチャンネルgunicornに行きました:)

昨日、gunicorn0.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アプリケーションのImportErrorが原因でした。 ここでのポイントは、ワーカーが起動時にクラッシュした場合、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という名前のディレクトリも存在することapp.py 。 Pythonファイルの名前を変更した後に機能しました。

@brouberol私は今でも同じ問題に遭遇しました。 Flaskアプリケーションにインポートエラーの原因となるモジュールがある場合、Gunicornはトレースバックをログに記録しませんが、Flaskの組み込みサーバーはログに記録します。

私たちにできることは、Gunicornがエラーログに具体的な情報がないままワーカーを起動できなかった場合は、最初にFlaskの組み込みサーバーを試してみることです。

--preloadを指定してguncornを実行すると、エラーログが表示されます

私にとって、Django runserverは問題なく動作しました。 問題は、Django settingsをgunicorn.conf.pyファイルにインポートすることでした。 そのインポートを削除すると、問題が解決しました。