O gunicorn está instalado dentro ou fora do virtualenv?

dentro. a esta altura, acho que é um problema de aplicativo, já que o gunicorn começa quando eu descarto a maioria das configurações, só que você não pode dizer o que está falhando ao olhar para essa saída.

Tente com "--debug --log-level debug". Veja se consegue mais informações.

esta é a saída com o nível de registro de depuração, receio

: desapontado:
Não tenho certeza do que está acontecendo ainda. Após a mensagem "Booting worker", espero ver "Exceção no processo de trabalho" se houver um problema. Só depois da meia-noite aqui, mas vou dormir sobre isso e talvez inventar alguma coisa.

Obrigado cara, se eu descobrir sozinho, eu te direi. agora estou trabalhando em settings.py ativando coisas até que eu acertei o erro novamente. Depuração à moda antiga :)

@benoitc por que log.exception não funcionou?

Geralmente não gosto de usar esse, pois é apenas uma coisa do python, se isso faz sentido.

Debug soa mais apropriado lá. A verdadeira adição aí é o traceback :)

Na verdade, estou tendo um problema semelhante e acho que tem a ver com as permissões de gravação no arquivo de log. Se eu tornar os arquivos de log (stderr e stdout) graváveis ​​publicamente, parece que está funcionando bem. Acho que isso me leva à questão de quando você inicia o gunicorn pelo supervisord pela primeira vez, os arquivos de log são criados sob o root antes que o gunicorn assuma. Qual é a melhor maneira de garantir que os arquivos de log sejam criados pelo gunicorn e não pelo supervisord?

Como você inicia o gunicorn? Você reproduz com a última cabeça?

Eu lanço com supervisord. Aqui está minha configuração de gunicorn para supervisord:

[programa: sliceeweb]
diretório = / opt / src / slicephone / webapp / webapp /
command = /opt/src/slicephone/webapp/scripts/gunicorn.sh
stdout_logfile = /opt/logs/supervisord.stdout.log
stderr_logfile = /opt/logs/supervisord.stderr.log

E o script gunicorn real (observe como eu toco e chown os arquivos de log para o usuário / grupo 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 = "- depurar - depurar no nível do log"

usuário / grupo para executar como

USER = www-data
GROUP = www-data
cd $ WEBAPPDIR / webapp
test -d $ LOGDIR || mkdir -p $ LOGDIR
echo WebAppDir: $ WEBAPPDIR
echo "Usuário: $ USER"
echo "Grupo: $ GROUP"

toque em $ 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

Boa pergunta sobre a última cabeça. pip freeze mostra que é 0.14.1 (.2 é o mais recente, não é?)

Você resolveu o problema? Tenho o mesmo problema e atualmente não tenho ideia de como resolvê-lo.

Deve ser resolvido sim. Qual versão do gunicorn você está executando? Você pode me fornecer mais informações sobre sua configuração para que eu possa reproduzi-la? Obrigado.

@panyam você tentou com 0.14.3?

@benoitc Desculpe, cara, não experimentei na versão 0.14.3. Consegui fazê-lo funcionar na 0.14.1 tornando o usuário gunicorn o proprietário dos arquivos de log assim que supervisord iniciar o script.

Só para esclarecer, não acho que seja um problema de gunicorn. @anyeguyue - o melhor lugar para verificar isso seria olhar o log do supervisord ou o log do gunicorn (geralmente em / var / log / gunicorn / ....) para ver se você tem um erro de "permissão negada" nele.

Acabei de ter o mesmo problema, resolvido primeiro por 'python manage.py syncdb' que gerou um erro. Depois de corrigir esse problema de configuração, o gunicorn funcionou (após reiniciar o nginx).

Eu resolvi esse problema também, mas de uma maneira diferente. A primeira linha do arquivo gunicorn_django era "#! / Opt / django / env / mysite / bin / python", que é o caminho do meu virtualenviroment python. O problema foi resolvido substituindo-o por "#! / Usr / bin / env python", embora ambos usassem o mesmo interpretador python, mas há algumas diferenças de PYTHONPATH, é por isso que falhou antes.

@anyeguyue Eu enfrentei o mesmo problema no gunicorn 0.14.5 e no Django 1.4, mas com sintomas ainda piores: gunicorn_django -b 0.0.0.0:8000 recusou-se a executar. Sua correção funciona e é bastante óbvia: deve-se sempre perguntar /usr/bin/env qual python usar! Obrigado.

@asimihsan, fico feliz em ajudar

Eu também tive esse problema. Saiu que era algum problema com importações erradas no meu código. Se você quiser depurar, tente executar gunicorn_django --preload - isso irá provavelmente gerar a exceção certa.

Para qualquer pessoa que enfrente o mesmo problema, o problema geralmente é algo no próprio django.
Ative seu venv e execute ./manage.py runserver

Isso geralmente fornecerá uma mensagem de erro mais detalhada.

: +1: @fergalmoran me ajudou a resolver meu problema (era um problema com PIL)

Estou com o mesmo problema ... e não sei como resolvê-lo

@pythdasch , foram falados alguns problemas diferentes aqui. Se você puder fornecer mais informações, abra um novo tíquete ou simplesmente envie uma mensagem para a lista de e-mails e outras pessoas poderão ajudá-lo a depurar.

Eu acho que nós resolvemos @pythdasch 's problema em #gunicorn. @pythdasch , você pode confirmar?

Eu confirmo, graças ao berker :)

Meu wsgi estava na mesma pasta que meu manage.py, então tive que colocar o caminho wsgi: aplicativo e não projeto. wsgi: aplicativo

(Era o caminho errado para wsgi. Nesse caso, precisava ser wsgi: application em vez de project.wsgi: application)

@tilgovi sim, desculpe, fui ao canal irc gunicorn para resolver isso :)

Encontrei o mesmo problema ontem, com gunicorn 0.18 e a seguinte invocação:

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

Foi devido a um ImportError em meu aplicativo Flask. A lição aqui é que o gunicorn não exibe o rastreamento do aplicativo se o trabalhador travar na inicialização, então eu tive que iniciar o aplicativo Flask manualmente para ver o problema real.

Eu me pergunto se conseguiríamos fazer com que exibisse o rastreamento real

Isso seria muito bom. IMO, a próxima melhor coisa, se exibir o traceback original não for possível, seria incluir uma mensagem sugerindo executar o aplicativo diretamente, em vez de usar gunicorn, para procurar o erro real.

Se entendi o problema corretamente, o Gunicorn já mostra as mensagens de exceção 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

e outros tipos de mensagens de erro:

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

Eu enfrentei o mesmo problema quando tentei executar o aplicativo desta forma:

gunicorn app:application -b localhost:3000

O problema era a presença de um diretório chamado app além do arquivo app.py . Funcionou depois de renomear o arquivo python.

@brouberol Eu me deparei com o mesmo problema até agora. Quando um aplicativo Flask tem algum módulo causando erro de importação, o Gunicorn não registra o traceback, mas o servidor embutido do Flask pode.

O que podemos fazer é que, se o Gunicorn falhar ao inicializar o worker sem informações mais específicas em qualquer log de erro, tente primeiro o servidor embutido do Flask.

execute guncorn com --preload pode ver o log de erros

Para mim, Django runserver funcionou bem. O problema era importar o Django settings no arquivo gunicorn.conf.py . Remover essa importação resolveu o problema.