Gunicorne est-il installé à l'intérieur ou à l'extérieur du virtualenv ?

à l'intérieur. à l'heure actuelle, je pense que c'est un problème d'application puisque gunicorn démarre lorsque je supprime la plupart des paramètres, c'est juste que vous ne pouvez pas dire ce qui échoue lorsque vous regardez cette sortie.

Essayez avec "--debug --log-level debug". Voyez si vous obtenez plus d'informations.

c'est la sortie avec le niveau du journal de débogage, j'en ai peur

:désappointé:
Je ne sais pas encore ce qui se passe. Après le message "Booting worker", je m'attends à voir "Exception in worker process" s'il y a un problème. Juste après minuit ici, mais je vais dormir dessus et peut-être trouver quelque chose.

Merci mec, si je trouve moi-même, je vous le ferai savoir. Je travaille maintenant sur les paramètres.py en activant les éléments jusqu'à ce que je rencontre à nouveau l'erreur. Débogage à l'ancienne :)

@benoitc pourquoi log.exception n'a-t-il pas fonctionné ?

Je n'aime généralement pas utiliser celui-ci car il ne s'agit que d'un python si cela a du sens.

Le son de débogage est plus approprié là-bas. Le vrai plus il y a le retraçage :)

En fait, j'ai un problème similaire et je pense que cela a à voir avec les autorisations d'écriture sur le fichier journal. Si je rends les fichiers journaux (stderr et stdout) accessibles en écriture publique, cela semble fonctionner correctement. Donc, je suppose que cela m'amène à la question de savoir quand vous démarrez pour la première fois gunicorn à partir de Supervisord, les fichiers journaux sont créés sous root avant que gunicorn ne prenne le relais. Quelle est la meilleure façon de s'assurer que les fichiers journaux sont créés par gunicorn et non par Supervisord ?

Comment lancez-vous gunicorn? Le reproduisez-vous avec la dernière tête ?

Je le lance avec superviseur. Voici ma config gunicorn pour superviseur :

[programme:sliceweb]
répertoire = /opt/src/slicephone/webapp/webapp/
commande = /opt/src/slicephone/webapp/scripts/gunicorn.sh
stdout_logfile = /opt/logs/supervisord.stdout.log
stderr_logfile = /opt/logs/supervisord.stderr.log

Et le script gunicorn réel (notez comment je touche et je chown les fichiers journaux à l'utilisateur/groupe gunicorn):

!/bin/bash

définir -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"

utilisateur/groupe à exécuter en tant que

UTILISATEUR=www-données
GROUP=www-données
cd $WEBAPPDIR/webapp
test -d $LOGDIR || mkdir -p $LOGDIR
echo WebAppDir : $WEBAPPDIR
echo "Utilisateur : $USER"
echo "Groupe : $GROUP"

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

Bonne question sur la dernière tête. le gel pip montre qu'il s'agit de 0,14.1 (.2 est le dernier n'est-ce pas ?)

Avez-vous résolu le problème ? J'ai le même problème et actuellement je n'ai aucune idée de comment le résoudre.

Cela devrait être résolu oui. Quelle version de gunicorn utilisez-vous ? Pouvez-vous me donner plus d'informations sur votre config pour que je puisse la reproduire ? Merci.

@panyam as -tu essayé avec 0.14.3 ?

@benoitc Désolé mon pote, je ne l'ai pas essayé sur 0.14.3. J'ai réussi à le faire fonctionner sur 0.14.1 en faisant de l'utilisateur gunicorn le propriétaire des fichiers journaux dès que Supervisord démarre le script.

Juste pour clarifier, je ne pense pas que ce soit un problème de gunicorn. @anyeguyue - le meilleur endroit pour vérifier cela serait de regarder le journal supervisé ou le journal gunicorn (généralement dans /var/log/gunicorn/....) pour voir si vous avez une erreur "autorisation refusée".

Je viens de rencontrer le même problème, résolu par le premier "python manage.py syncdb" qui a conduit à une erreur. Après avoir résolu ce problème de configuration, gunicorn a fonctionné (après avoir redémarré nginx).

J'ai également résolu ce problème mais d'une manière différente. La première ligne du fichier gunicorn_django était "#!/opt/django/env/mysite/bin/python", qui est le chemin de mon chemin python virtualenviroment. Le problème a été résolu en le remplaçant par "#!/usr/bin/env python", bien qu'ils aient tous deux utilisé le même interpréteur python, mais il existe une différence PYTHONPATH, c'est pourquoi il a échoué auparavant.

@anyeguyue J'ai rencontré le même problème sur gunicorn 0.14.5 et Django 1.4, mais avec des symptômes encore pires : gunicorn_django -b 0.0.0.0:8000 refusé de s'exécuter. Votre solution fonctionne et est assez évidente : il faut toujours demander à /usr/bin/env quel python utiliser ! Merci.

@asimihsan， heureux de vous aider

J'ai également eu ce problème. Il s'est avéré qu'il y avait un problème avec des importations incorrectes dans mon code. Si vous voulez déboguer, essayez d'exécuter gunicorn_django --preload - cela va, espérons-le, cracher la bonne exception.

Pour toute personne confrontée au même problème, le problème est généralement quelque chose dans Django lui-même.
Activez votre venv et exécutez ./manage.py runserver

Cela vous donnera généralement un message d'erreur plus détaillé.

:+1: @fergalmoran m'a aidé à résoudre mon problème (c'était un problème avec PIL)

Je suis confronté au même problème... et je ne sais pas comment le résoudre

@pythdasch, il y a eu quelques problèmes différents dont on a parlé ici. Si vous pouvez fournir plus d'informations, veuillez ouvrir un nouveau ticket, ou simplement envoyer un message à la liste de diffusion et d'autres pourront peut-être vous aider à déboguer.

Je pense que nous avons résolu le problème de @pythdasch » sur #gunicorn. @pythdasch , pouvez-vous confirmer ?

Je confirme, merci à berker :)

Mon wsgi était dans le même dossier que mon manage.py, j'ai donc dû mettre le chemin wsgi:application et non le projet. wsgi:application

(C'était le mauvais chemin vers wsgi. Dans ce cas, il fallait wsgi:application au lieu de project.wsgi:application)

@tilgovi oui désolé je suis allé sur le canal irc gunicorn pour le résoudre :)

J'ai rencontré le même problème hier, avec gunicorn 0.18 et l'invocation suivante :

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

C'était dû à une ImportError dans mon application Flask. Le point à retenir ici est que gunicorn n'affiche pas le retraçage de l'application si le travailleur se bloque au démarrage, j'ai donc dû démarrer l'application Flask manuellement pour voir le problème réel.

Je me demande si nous pourrions l'obtenir pour afficher le retraçage réel

Ce serait très sympa. IMO, la prochaine meilleure chose, si l'affichage du retraçage d'origine n'est pas possible, serait d'inclure un message suggérant d'exécuter l'application directement, au lieu d'utiliser gunicorn, pour rechercher l'erreur réelle.

Si je comprends bien le problème, Gunicorn affiche déjà les messages d'exception comme 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

et d'autres types de messages d'erreur :

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

J'ai rencontré le même problème lorsque j'ai essayé d'exécuter l'application comme ceci :

gunicorn app:application -b localhost:3000

Le problème était la présence d'un répertoire nommé app en plus du fichier app.py . Cela a fonctionné après avoir renommé le fichier python.

@brouberol J'ai rencontré le même problème même maintenant. Lorsqu'une application Flask a un module provoquant une erreur d'importation, Gunicorn n'enregistre pas le traçage mais le serveur intégré de Flask peut le faire.

Ce que nous pouvons faire, c'est que si Gunicorn n'a pas réussi à démarrer le travailleur sans informations plus spécifiques dans un journal d'erreurs, essayez d'abord le serveur intégré de Flask.

exécuter guncorn avec --preload peut voir le journal des erreurs

Pour moi, Django runserver a bien fonctionné. Le problème était d'importer le Django settings dans le fichier gunicorn.conf.py . La suppression de cette importation a résolu le problème.