gunicorn이 virtualenv 내부에 설치되어 있습니까 아니면 외부에 설치되어 있습니까?

내부에. 지금쯤이면 대부분의 설정을 버릴 때 gunicorn이 시작되기 때문에 앱 문제라고 생각합니다. 해당 출력을 볼 때 무엇이 ​​실패했는지 알 수 없다는 것뿐입니다.

"--debug --log-level debug"로 시도하십시오. 추가 정보가 있는지 확인하세요.

이것은 내가 두려워하는 디버그 로그 수준의 출력입니다.

:실망한:
아직 무슨 일이 일어나고 있는지 잘 모르겠습니다. "Booting worker" 메시지 뒤에 문제가 있는 경우 "Exception in worker process"가 표시될 것으로 예상합니다. 자정이 조금 넘었지만 잠을 자고 뭔가 생각해낼 수 있을 것입니다.

고마워, 내가 스스로 알아내면 알려줄게. 나는 이제 오류가 다시 발생할 때까지 settings.py를 통해 작업하고 있습니다. 올드 스쿨 디버깅 :)

@benoitc log.exception 이 작동하지 않는 이유는 무엇입니까?

나는 일반적으로 이것이 의미가있는 경우 파이썬 일뿐이므로 사용하는 것을 좋아하지 않습니다.

거기에 더 적절한 디버그 사운드. 거기에 진짜 추가는 역추적입니다 :)

사실 나도 비슷한 문제가 있고 로그 파일에 대한 쓰기 권한과 관련이 있다고 생각합니다. 로그 파일(stderr 및 stdout)을 공개적으로 쓰기 가능하게 만들면 제대로 작동하는 것 같습니다. 그래서 내가 supervisord에서 gunicorn을 처음 시작할 때 gunicorn이 인계받기 전에 루트 아래에 로그 파일이 생성되는지에 대한 질문을 하게 되는 것 같습니다. 로그 파일이 Supervisord가 아닌 gunicorn에 의해 생성되도록 관리하는 가장 좋은 방법은 무엇입니까?

어떻게 gunicorn을 시작합니까? 마지막 머리로 재현합니까?

나는 감독자와 함께 그것을 시작합니다. 다음은 Supervisord에 대한 내 gunicorn 구성입니다.

[프로그램:슬라이스웹]
디렉토리 = /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 사용자/그룹에 로그 파일을 터치하고 chown하는 방법 참고):

!/bin/bash

세트 -e
DATASTORE_SOFTWARE="XXXXX"
ACCESS_LOGFILE=/opt/logs/gunicorn.slice.access.log
ERROR_LOGFILE=/opt/logs/gunicorn.slice.error.log
로그 파일=/opt/logs/gunicorn.slice.log
LOGDIR=$(디렉토리 이름 $LOGFILE)
WEBAPPDIR=$(디렉터리 이름 $0)/../
NUM_WORKERS=3
DEBUG_FLAGS="--debug --로그 수준 디버그"

실행할 사용자/그룹

USER=www-data
그룹=www-data
cd $WEBAPPDIR/webapp
테스트 -d $LOGDIR || mkdir -p $LOGDIR
에코 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 죄송합니다 친구

명확히하기 위해 나는 이것이 gunicorn 문제라고 생각하지 않습니다. @anyeguyue - 이것을 확인하는 가장 좋은 곳은 감독자 로그 또는 gunicorn 로그(일반적으로 /var/log/gunicorn/....에 있음)를 살펴보고 거기에 "권한 거부됨" 오류가 있는지 확인하는 것입니다.

방금 동일한 문제가 발생하여 첫 번째 'python manage.py syncdb'로 해결되어 오류가 발생했습니다. 해당 설정 문제를 수정한 후 gunicorn이 작동했습니다(nginx를 다시 시작한 후).

이 문제도 해결했지만 다른 방법으로 해결했습니다. gunicorn_django 파일의 첫 번째 줄은 내 가상 환경 파이썬 경로의 경로인 "#!/opt/django/env/mysite/bin/python"이었습니다. "#!/usr/bin/env python"으로 교체하여 문제가 해결되었지만 둘 다 동일한 파이썬 인터프리터를 사용했지만 PYTHONPATH 차이가 있기 때문에 이전에 실패한 것입니다.

@anyeguyue 나는 gunicorn 0.14.5 및 Django 1.4에서 동일한 문제에 직면했지만 더 나쁜 증상이 있습니다. gunicorn_django -b 0.0.0.0:8000 실행이 거부되었습니다. 수정 사항은 작동하고 매우 분명합니다. 항상 /usr/bin/env which python 를 사용해야 합니다! 감사 해요.

@asimihsan, 도움이 되어서 기쁩니다

나는 또한이 문제가 있었다. 내 코드에서 잘못된 가져오기에 문제가 있는 것으로 나타났습니다. 디버그하려면 gunicorn_django --preload를 실행해 보십시오. 그러면 올바른 예외가 발생하기를 바랍니다.

동일한 문제에 직면한 사람에게 문제는 일반적으로 django 자체에 있는 문제입니다.
venv를 활성화하고 ./manage.py runserver를 실행하십시오.

이렇게 하면 일반적으로 더 자세한 오류 메시지가 표시됩니다.

:+1: @fergalmoran 내 문제를 해결하는 데 도움이 되었습니다(PIL의 문제였습니다).

같은 문제에 직면해 있는데... 해결 방법을 모르겠습니다.

@pythdasch 여기에서 이야기한 몇 가지 다른 문제가 있습니다. 추가 정보를 제공할 수 있는 경우 새 티켓을 열거나 메일링 리스트에 메시지를 보내면 다른 사람들이 디버깅을 도울 수 있습니다.

#gunicorn 에서 @pythdasch의 문제를 해결 @pythdasch , 확인할 수 있습니까?

Berker 덕분에 확인했습니다 :)

내 wsgi는 내 manage.py와 같은 폴더에 있으므로 프로젝트가 아닌 wsgi:application 경로를 넣어야 했습니다. wsgi:응용 프로그램

(wsgi에 대한 잘못된 경로였습니다. 이 경우 project.wsgi:application 대신 wsgi:application이어야 함)

@tilgovi 네 죄송합니다 irc 채널 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

내 Flask 응용 프로그램의 ImportError 때문이었습니다. 여기서 중요한 점은 작업자가 부팅 시 충돌하는 경우 gunicorn이 응용 프로그램의 역추적을 표시하지 않기 때문에 실제 문제를 확인하려면 Flask 앱을 ​​수동으로 시작해야 한다는 것입니다.

실제 역추적을 표시할 수 있는지 궁금합니다.

이것은 매우 좋을 것입니다. IMO 다음으로 좋은 방법은 원본 트레이스백을 표시할 수 없는 경우 실제 오류를 찾기 위해 gunicorn을 사용하는 대신 응용 프로그램을 직접 실행하라는 메시지를 포함하는 것입니다.

문제를 올바르게 이해했다면 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.py 파일 외에도 app 라는 디렉토리가 있다는 것이었습니다. 파이썬 파일의 이름을 바꾼 후에 작동했습니다.

@brouberol 지금도 같은 문제가 발생했습니다. Flask 응용 프로그램에 가져오기 오류를 일으키는 일부 모듈이 있는 경우 Gunicorn은 역추적을 기록하지 않지만 Flask의 내장 서버는 기록할 수 있습니다.

우리가 할 수 있는 것은 Gunicorn이 오류 로그에 더 자세한 정보 없이 작업자를 부팅하지 못한 경우 먼저 Flask의 내장 서버를 시도하는 것입니다.

--preload로 guncorn을 실행하면 오류 로그를 볼 수 있습니다.

저에게는 Django runserver 잘 작동했습니다. gunicorn.conf.py 파일에서 Django settings 를 가져오는 것이 문제였습니다. 해당 가져오기를 제거하면 문제가 해결되었습니다.