Ist Gunicorn innerhalb der Virtualenv oder außerhalb installiert?

Innerhalb. Mittlerweile denke ich, dass es ein App-Problem ist, da Gunicorn startet, wenn ich die meisten Einstellungen wegwerfe.

Versuchen Sie es mit "--debug --log-level debug". Sehen Sie, ob Sie weitere Informationen erhalten.

Dies ist die Ausgabe mit dem Debug-Log-Level, fürchte ich

:enttäuscht:
Ich bin mir noch nicht sicher, was passiert. Nach der Meldung "Booting Worker" erwarte ich, dass "Exception in Worker Process" angezeigt wird, wenn ein Problem auftritt. Kurz nach Mitternacht hier, aber ich werde darüber schlafen und mir vielleicht etwas einfallen lassen.

Danke Mann, wenn ich es selbst herausfinde, lasse ich es dich wissen. Ich arbeite jetzt durch die settings.py und schalte Sachen ein, bis ich den Fehler erneut treffe. Debuggen der alten Schule :)

@benoitc warum hat log.exception nicht funktioniert?

Ich mag es im Allgemeinen nicht, das zu verwenden, da dies nur eine Python-Sache ist, wenn das Sinn macht.

Debug-Sound ist dort besser geeignet. Die eigentliche Ergänzung dort ist der Traceback :)

Tatsächlich habe ich ein ähnliches Problem und ich denke, es hat mit Schreibberechtigungen für die Protokolldatei zu tun. Wenn ich die Protokolldateien (stderr und stdout) öffentlich beschreibbar mache, scheint es gut zu funktionieren. Ich denke, das bringt mich zu der Frage, wenn Sie gunicorn zum ersten Mal von Supervisor aus starten, werden die Protokolldateien unter root erstellt, bevor gunicorn übernimmt. Wie lässt sich am besten sicherstellen, dass Protokolldateien von gunicorn und nicht von Supervisor erstellt werden?

Wie startet man Gunicorn? Reproduzieren Sie es mit dem letzten Kopf?

Ich starte es mit Supervisord. Hier ist meine Gunicorn-Konfiguration für Supervisord:

[Programm:Sliceweb]
Verzeichnis = /opt/src/slicephone/webapp/webapp/
Befehl = /opt/src/slicephone/webapp/scripts/gunicorn.sh
stdout_logfile = /opt/logs/supervisord.stdout.log
stderr_logfile = /opt/logs/supervisord.stderr.log

Und das eigentliche Gunicorn-Skript (beachten Sie, wie ich die Protokolldateien berühre und an den Gunicorn-Benutzer / die Gunicorn-Gruppe teile):

!/bin/bash

setze -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=$(Verzeichnisname $LOGFILE)
WEBAPPDIR=$(Verzeichnisname $0)/../
NUM_WORKERS=3
DEBUG_FLAGS="--debug --log-level debug"

Benutzer/Gruppe zum Ausführen als

USER=www-data
GRUPPE=www-daten
cd $WEBAPPDIR/webapp
test -d $LOGDIR || mkdir -p $LOGDIR
echo WebAppDir: $WEBAPPDIR
echo "Benutzer: $USER"
echo "Gruppe: $GROUP"

Berühren Sie $ACCESS_LOGFILE $ERROR_LOGFILE $LOGFILE
chown -R $USER:$GROUP $ACCESS_LOGFILE $ERROR_LOGFILE $LOGFILE

exportiere 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

Gute Frage zum neuesten Kopf. Pip Freeze zeigt an, dass es 0.14.1 ist (.2 ist das neueste, oder?)

Hast du das Problem gelöst? Ich habe das gleiche Problem und habe momentan keine Ahnung wie ich es lösen kann.

Es sollte ja gelöst werden. Welche Gunicorn-Version nutzt du? Können Sie mir mehr Informationen zu Ihrer Konfiguration geben, damit ich sie reproduzieren kann? Danke.

@panyam hast du es mit 0.14.3 versucht?

@benoitc Entschuldigung, Kumpel, ich habe es nicht auf 0.14.3 versucht. Ich habe es geschafft, es auf 0.14.1 zum Laufen zu bringen, indem ich den gunicorn-Benutzer zum Besitzer der Protokolldateien gemacht habe, sobald Supervisord das Skript startet.

Nur um das klarzustellen, ich glaube nicht, dass dies ein Gunicorn-Problem ist. @anyeguyue - der beste Ort, um dies zu überprüfen, wäre, das Supervisord-Protokoll oder das Gunicorn-Protokoll (normalerweise in /var/log/gunicorn/....)

Ich habe gerade das gleiche Problem bekommen, das zuerst mit 'python manage.py syncdb' gelöst wurde, was zu einem Fehler führte. Nachdem dieses Einstellungsproblem behoben wurde, funktionierte gunicorn (nach dem Neustart von nginx).

Ich habe dieses Problem auch gelöst, aber auf eine andere Art und Weise. Die erste Zeile der Datei gunicorn_django war "#!/opt/django/env/mysite/bin/python", was der Pfad meines Python-Pfads für die virtuelle Umgebung ist. Das Problem wurde gelöst, indem es als "#!/usr/bin/env python" ersetzt wurde, obwohl beide den gleichen Python-Interpreter verwendeten, aber es gibt einige PYTHONPATH-Unterschiede, deshalb war es zuvor fehlgeschlagen.

@anyeguyue Ich hatte das gleiche Problem bei gunicorn 0.14.5 und Django 1.4, aber mit noch schlimmeren Symptomen: gunicorn_django -b 0.0.0.0:8000 weigerte sich zu laufen. Ihr Fix funktioniert und ist ziemlich offensichtlich: Man sollte /usr/bin/env immer fragen, welches python verwendet werden soll! Danke.

@asimihsan， hilft gerne

Ich hatte dieses Problem auch. Es kam heraus, dass es ein Problem mit falschen Importen in meinem Code war. Wenn Sie debuggen möchten, versuchen Sie es mit gunicorn_django --preload - dies wird hoffentlich die richtige Ausnahme ausspucken.

Für jeden, der mit dem gleichen Problem konfrontiert ist, liegt das Problem normalerweise in Django selbst.
Aktivieren Sie Ihr venv und führen Sie ./manage.py runserver . aus

Dadurch erhalten Sie normalerweise eine detailliertere Fehlermeldung.

:+1: @fergalmoran hat mir geholfen, mein Problem zu lösen (es war ein Problem mit PIL)

ich stehe vor dem gleichen Problem... und weiß nicht wie ich es lösen soll

@pythdasch es wurden hier ein paar verschiedene Probleme

Ich denke , wir gelöst @pythdasch ‚s Problem auf #gunicorn. @pythdasch , kannst du das bestätigen?

Ich bestätige, danke an Berker :)

Mein wsgi befand sich im selben Ordner wie mein manage.py, also musste ich den Pfad wsgi:application und nicht das Projekt wsgi: Anwendung

(Es war der falsche Pfad zu wsgi. In diesem Fall musste wsgi:application statt project.wsgi:application sein)

@tilgovi ja Entschuldigung, ich bin zum IRC-Kanal Gunicorn gegangen, um es zu lösen :)

Ich bin gestern auf das gleiche Problem gestoßen, mit gunicorn 0.18 und dem folgenden Aufruf:

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

Es lag an einem ImportError in meiner Flask-Anwendung. Die Erkenntnis hier ist, dass gunicorn das Traceback von der Anwendung nicht anzeigt, wenn der Worker beim Booten abstürzt, also musste ich die Flask-App manuell starten, um das eigentliche Problem zu sehen.

Ich frage mich, ob wir es schaffen könnten, den tatsächlichen Traceback anzuzeigen

Das wäre sehr schön. IMO, das Nächstbeste, wenn die Anzeige des ursprünglichen Tracebacks nicht möglich ist, wäre, eine Nachricht einzufügen, die vorschlägt, die Anwendung direkt auszuführen, anstatt gunicorn zu verwenden, um nach dem tatsächlichen Fehler zu suchen.

Wenn ich das Problem richtig verstehe, zeigt Gunicorn bereits die Ausnahmemeldungen wie ImportError an:

$ 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

und andere Fehlermeldungen:

$ 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.

Ich hatte das gleiche Problem, als ich versuchte, die App wie folgt auszuführen:

gunicorn app:application -b localhost:3000

Das Problem war das Vorhandensein eines Verzeichnisses namens app zusätzlich zur Datei app.py . Es funktionierte nach dem Umbenennen der Python-Datei.

@brouberol Ich bin jetzt auf das gleiche Problem

Was wir tun können, ist, dass, wenn Gunicorn den Worker ohne genauere Informationen in einem Fehlerprotokoll nicht booten konnte, zuerst den eingebauten Server von Flask ausprobieren.

starte guncorn mit --preload kann das Fehlerprotokoll sehen

Bei mir hat Django runserver funktioniert. Das Problem war das Importieren des Django settings in die gunicorn.conf.py Datei. Das Entfernen dieses Imports hat das Problem behoben.