Gunicorn установлен внутри virtualenv или снаружи?

внутри. к настоящему моменту я думаю, что это проблема приложения, так как пулемет запускается, когда я выкидываю большинство настроек, просто вы не можете сказать, что не удается, глядя на этот вывод.

Попробуйте с "--debug --log-level debug". Посмотри, получишь ли ты дополнительную информацию.

это результат с уровнем журнала отладки, я боюсь

:разочарованный:
Я еще не уверен, что происходит. После сообщения «Загрузка рабочего процесса» я ожидаю увидеть «Исключение в рабочем процессе», если есть проблема. Здесь только за полночь, но я посплю и, может быть, что-нибудь придумаю.

Спасибо, чувак, если я сам разберусь, я дам тебе знать. Я сейчас прорабатываю settings.py, включаю все, пока снова не нахожу ошибку. Олдскульная отладка :)

@benoitc, почему log.exception не работает?

Обычно я не люблю его использовать, потому что это просто питон, если в этом есть смысл.

Отладочный звук там более уместен. Настоящее дополнение - это трассировка :)

На самом деле у меня аналогичная проблема, и я думаю, что это связано с разрешениями на запись в файл журнала. Если я сделаю файлы журнала (stderr и stdout) общедоступными, они, похоже, будут работать нормально. Итак, я думаю, это подводит меня к вопросу о том, когда вы впервые запускаете Gunicorn из супервизора, файлы журнала создаются под root, прежде чем Gunicorn вступит во владение. Как лучше всего обеспечить, чтобы файлы журналов создавались Gunicorn, а не супервизором?

Как запустить пулемет? Вы воспроизводите это с последней головы?

Запускаю с супервизором. Вот мой конфиг для супервизора:

[программа: sleweb]
каталог = / 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):

! / 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 = $ (имя каталога $ LOGFILE)
WEBAPPDIR = $ (имя каталога $ 0) /../
NUM_WORKERS = 3
DEBUG_FLAGS = "- отладка - отладка на уровне журнала"

пользователь / группа для запуска от имени

ПОЛЬЗОВАТЕЛЬ = www-data
ГРУППА = www-данные
cd $ WEBAPPDIR / webapp
test -d $ LOGDIR || mkdir -p $ ЛОГДИР
echo WebAppDir: $ WEBAPPDIR
echo "Пользователь: $ USER"
echo "Группа: $ GROUP"

коснитесь $ ACCESS_LOGFILE $ ERROR_LOGFILE $ LOGFILE
chown -R $ USER: $ GROUP $ ACCESS_LOGFILE $ ERROR_LOGFILE $ LOGFILE

экспорт 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

Хороший вопрос по последней голове. pip freeze показывает, что это 0.14.1 (.2 - последняя версия, не так ли?)

Ты решил проблему? У меня такая же проблема, и в настоящее время я не знаю, как ее решить.

Это надо решить да. Какую версию Gunicorn вы используете? Не могли бы вы предоставить мне дополнительную информацию о своей конфигурации, чтобы я мог ее воспроизвести? Спасибо.

@panyam вы пробовали с 0.14.3?

@benoitc Извините,

Просто чтобы прояснить, я не думаю, что это проблема стрельбы. @anyeguyue - лучшее место для проверки - это посмотреть журнал супервизора или журнал стрельбы (обычно в / var / log / gunicorn / ....), чтобы узнать, есть ли там ошибка "доступ запрещен".

У меня возникла та же проблема, которую решил сначала python manage.py syncdb, что привело к ошибке. После устранения этой проблемы с настройками Gunicorn работал (после перезапуска nginx).

Я тоже решил эту проблему, но по-другому. Первая строка файла gunicorn_django была "#! / Opt / django / env / mysite / bin / python", это путь моего виртуального пути к python. Проблема решена заменой его на "#! / Usr / bin / env python", хотя они оба использовали один и тот же интерпретатор Python, но есть некоторая разница в PYTHONPATH, поэтому раньше он не удался.

@anyeguyue Я столкнулся с той же проблемой на Gunicorn 0.14.5 и Django 1.4, но с еще худшими симптомами: gunicorn_django -b 0.0.0.0:8000 отказался запускаться. Ваше исправление работает и довольно очевидно: всегда нужно спрашивать /usr/bin/env какой python использовать! Спасибо.

@asimihsan ， рад помочь

У меня тоже была эта проблема. Выяснилось, что в моем коде возникла проблема с неправильным импортом. Если вы хотите отладить, попробуйте запустить gunicorn_django --preload - это, надеюсь, выдаст правильное исключение.

Для тех, кто сталкивается с той же проблемой, проблема обычно в самом django.
Активируйте ваш venv и запустите ./manage.py runserver

Обычно это дает более подробное сообщение об ошибке.

: +1: @fergalmoran Помог мне решить мою проблему (это была проблема с PIL)

У меня такая же проблема ... и не знаю, как ее решить

@pythdasch здесь

Я думаю , что мы решили @pythdasch проблемы «s на #gunicorn. @pythdasch , вы можете подтвердить?

Подтверждаю, спасибо berker :)

Мой wsgi находился в той же папке, что и мой manage.py, поэтому мне пришлось указать путь wsgi: приложение

(Это был неправильный путь к wsgi. В этом случае должен был быть wsgi: application вместо project.wsgi: application)

@tilgovi да, извините, я пошел на irc channel gunicorn, чтобы решить эту проблему :)

Вчера я столкнулся с той же проблемой с Gunicorn 0.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

Это произошло из-за ошибки ImportError в моем приложении Flask. Подсказка здесь в том, что gunicorn не отображает обратную трассировку из приложения, если рабочий вылетает при загрузке, поэтому мне пришлось запустить приложение Flask вручную, чтобы увидеть реальную проблему.

Интересно, сможем ли мы заставить его отображать фактическую трассировку

Это было бы очень хорошо. ИМО, следующая лучшая вещь, если отображение исходной трассировки невозможно, - это включить сообщение, предлагающее запустить приложение напрямую, вместо использования пушки, для поиска фактической ошибки.

Если я правильно понимаю проблему, 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 в дополнение к файлу app.py . Это сработало после переименования файла python.

@brouberol Я столкнулся с той же проблемой даже сейчас. Когда в приложении Flask есть какой-либо модуль, вызывающий ошибку импорта, Gunicorn не регистрирует трассировку, а встроенный сервер Flask может.

Что мы можем сделать, так это то, что если Gunicorn не удалось загрузить воркер без более конкретной информации в каком-либо журнале ошибок, сначала попробуйте встроенный сервер Flask.

запустите guncorn с --preload, чтобы увидеть журнал ошибок

Для меня Django runserver работал нормально. Проблема заключалась в импорте Django settings в файл gunicorn.conf.py . Удаление этого импорта решило проблему.