¿Gunicorn está instalado dentro o fuera del virtualenv?

dentro. A estas alturas, creo que es un problema de la aplicación, ya que gunicorn comienza cuando elimino la mayoría de las configuraciones, es solo que no puedes saber qué está fallando al mirar esa salida.

Pruebe con "--debug --log-level debug". Vea si obtiene más información.

esta es la salida con el nivel de registro de depuración me temo

:decepcionado:
No estoy seguro de lo que está pasando todavía. Después del mensaje "Arrancando trabajador", espero ver "Excepción en el proceso de trabajo" si hay un problema. Pasada la medianoche aquí, pero dormiré y tal vez se me ocurra algo.

Gracias, hombre, si lo averiguo yo mismo, te lo haré saber. Ahora estoy trabajando en settings.py encendiendo cosas hasta que vuelvo a encontrar el error. Depuración de la vieja escuela :)

@benoitc ¿ log.exception no funcionó?

En general, no me gusta usar ese, ya que esto es solo una cosa de Python si tiene sentido.

La depuración suena más apropiada allí. La verdadera adición es el rastreo :)

En realidad, tengo un problema similar y creo que tiene que ver con los permisos de escritura en el archivo de registro. Si hago que los archivos de registro (stderr y stdout) se puedan escribir públicamente, parece que funciona bien. Así que supongo que eso me lleva a la pregunta de cuándo inicia por primera vez gunicorn desde supervisord, los archivos de registro se crean bajo root antes de que gunicorn se haga cargo. ¿Cuál es la mejor manera de garantizar que los archivos de registro sean creados por gunicorn y no por supervisor?

¿Cómo lanzas gunicorn? ¿Lo reproduces con última cabeza?

Lo lanzo con supervisor. Aquí está mi configuración de gunicorn para supervisor:

[programa: sliceweb]
directorio = / opt / src / slicephone / webapp / webapp /
comando = /opt/src/slicephone/webapp/scripts/gunicorn.sh
stdout_logfile = /opt/logs/supervisord.stdout.log
stderr_logfile = /opt/logs/supervisord.stderr.log

Y la secuencia de comandos de gunicorn real (observe cómo toco y uso los archivos de registro para el usuario / grupo de gunicorn):

! / 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 = "- depuración --depuración a nivel de registro"

usuario / grupo para ejecutar como

USUARIO = www-data
GRUPO = www-datos
cd $ WEBAPPDIR / aplicación web
prueba -d $ LOGDIR || mkdir -p $ LOGDIR
echo WebAppDir: $ WEBAPPDIR
echo "Usuario: $ USER"
echo "Grupo: $ GROUP"

toque $ ACCESS_LOGFILE $ ERROR_LOGFILE $ LOGFILE
chown -R $ USER: $ GROUP $ ACCESS_LOGFILE $ ERROR_LOGFILE $ LOGFILE

exportar 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

Buena pregunta sobre la última cabeza. pip freeze muestra que es 0.14.1 (.2 es el último, ¿no?)

¿Has resuelto el problema? Tengo el mismo problema y actualmente no tengo idea de cómo resolverlo.

Debería resolverse sí. ¿Qué versión de gunicorn estás ejecutando? ¿Puede proporcionarme más información sobre su configuración para que pueda reproducirla? Gracias.

@panyam, ¿lo intentaste con 0.14.3?

@benoitc Lo siento amigo, no lo probé en 0.14.3. Logré que funcionara en 0.14.1 haciendo que el usuario de gunicorn sea el propietario de los archivos de registro tan pronto como supervisor inicia el script.

Solo para aclarar, no creo que esto sea un problema de Gunicorn. @anyeguyue : el mejor lugar para verificar esto sería mirar el registro del supervisor o el registro de gunicorn (generalmente en / var / log / gunicorn / ....) para ver si tiene un error de "permiso denegado" allí.

Acabo de tener el mismo problema, resuelto por el primer 'python manage.py syncdb' que condujo a un error. Después de solucionar ese problema de configuración, gunicorn funcionó (después de reiniciar nginx).

También resolví este problema, pero de una manera diferente. La primera línea del archivo gunicorn_django era "#! / Opt / django / env / mysite / bin / python", que es la ruta de mi ruta de python virtualenviroment. El problema se resolvió reemplazándolo como "#! / Usr / bin / env python", aunque ambos usaron el mismo intérprete de Python, pero hay alguna diferencia de PYTHONPATH, por eso falló antes.

@anyeguyue Enfrenté el mismo problema en gunicorn 0.14.5 y Django 1.4, pero con síntomas aún peores: gunicorn_django -b 0.0.0.0:8000 negó a ejecutar. Su solución funciona y es bastante obvia: ¡uno siempre debe preguntar /usr/bin/env qué python usar! Gracias.

@asimihsan, encantado de ayudar

También tuve este problema. Resultó que había algún problema con importaciones incorrectas en mi código. Si desea depurar, intente ejecutar gunicorn_django --preload; con suerte, esto arrojará la excepción correcta.

Para cualquiera que se enfrente al mismo problema, el problema suele ser algo en el propio django.
Active su venv y ejecute ./manage.py runserver

Por lo general, esto le dará un mensaje de error más detallado.

: +1: @fergalmoran Me ayudó a resolver mi problema (era un problema con PIL)

Estoy enfrentando el mismo problema ... y no sé cómo resolverlo.

@pythdasch ha habido un par de problemas diferentes de los que se ha hablado aquí. Si puede proporcionar más información, abra un nuevo ticket o simplemente envíe un mensaje a la lista de correo y es posible que otros puedan ayudarlo a depurar.

Creo que resolvimos el problema de @pythdasch en #gunicorn. @pythdasch , ¿puedes confirmar?

Lo confirmo, gracias a berker :)

Mi wsgi estaba en la misma carpeta que mi manage.py, así que tuve que poner la ruta wsgi: application y no project. wsgi: aplicación

(Era la ruta incorrecta a wsgi. En este caso, tenía que ser wsgi: application en lugar de project.wsgi: application)

@tilgovi si

Ayer encontré el mismo problema, con gunicorn 0.18 y la siguiente invocación:

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

Fue debido a un ImportError en mi aplicación Flask. La conclusión aquí es que gunicorn no muestra el rastreo de la aplicación si el trabajador falla en el arranque, por lo que tuve que iniciar la aplicación Flask manualmente para ver el problema real.

Me pregunto si podríamos hacer que muestre el rastreo real

Esto estaría muy bien. En mi opinión, la siguiente mejor opción, si no es posible mostrar el rastreo original, sería incluir un mensaje que sugiera ejecutar la aplicación directamente, en lugar de usar gunicorn, para buscar el error real.

Si entiendo el problema correctamente, Gunicorn ya muestra los mensajes de excepción como 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

y otro tipo de mensajes de error:

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

Enfrenté el mismo problema cuando intenté ejecutar la aplicación de esta manera:

gunicorn app:application -b localhost:3000

El problema había sido la presencia de un directorio llamado app además del archivo app.py . Funcionó después de cambiar el nombre del archivo Python.

@brouberol Me encontré con el mismo problema incluso ahora. Cuando una aplicación de Flask tiene algún módulo que causa un error de importación, Gunicorn no registra el rastreo, pero el servidor integrado de Flask sí.

Lo que podemos hacer es que si Gunicorn no pudo iniciar el trabajador sin información más específica en cualquier registro de errores, primero intente con el servidor integrado de Flask.

ejecutar guncorn con --preload puede ver el registro de errores

Para mí, Django runserver funcionó bien. El problema era importar Django settings en el archivo gunicorn.conf.py . Eliminar esa importación resolvió el problema.