هل تم تثبيت برنامج Gunicorn داخل Virtualenv أو خارجه؟

في داخل. أعتقد الآن أنها مشكلة في التطبيق منذ أن بدأ برنامج gunicorn عندما ألغيت معظم الإعدادات ، إنه فقط لا يمكنك معرفة ما هو الفشل عند النظر إلى هذا الإخراج.

جرب باستخدام "--debug --log-level debug". انظر إذا حصلت على المزيد من المعلومات.

هذا هو الناتج مع مستوى سجل التصحيح أخشى

:خائب الامل:
لست متأكدًا مما يحدث حتى الآن. بعد رسالة "Booting worker" أتوقع رؤية "استثناء في عملية العامل" إذا كانت هناك مشكلة. بعد منتصف الليل فقط هنا ، لكنني سأنام عليه وربما أخرج بشيء.

شكرًا يا رجل ، إذا اكتشفت ذلك بنفسي ، فسأعلمك بذلك. أنا أعمل الآن من خلال الإعدادات. تصحيح أخطاء المدرسة القديمة :)

benoitc لماذا لم يعمل log.exception ؟

لا أحب عمومًا استخدام ذلك لأن هذا مجرد شيء من نوع بيثون إذا كان ذلك منطقيًا.

يبدو التصحيح أكثر ملاءمة هناك. الإضافة الحقيقية هناك هي traceback :)

في الواقع أواجه مشكلة مماثلة وأعتقد أن الأمر يتعلق بأذونات الكتابة في ملف السجل. إذا جعلت ملفات السجل (stderr و stdout) قابلة للكتابة علنًا ، فيبدو أنها تعمل بشكل جيد. لذلك أعتقد أن هذا يقودني إلى السؤال حول متى تبدأ تشغيل برنامج Gunicorn من المشرف ، يتم إنشاء ملفات السجل تحت الجذر قبل أن يتولى Gunicorn المسؤولية. ما هي أفضل طريقة لإدارة ضمان إنشاء ملفات السجل بواسطة Gunicorn وليس بواسطة المشرف؟

كيف تطلق جونيكورن؟ هل تقوم بإعادة إنتاجه برأس أخير؟

أطلقته مع المشرف. هنا هو تكوين gunicorn الخاص بي للمشرف:

[البرنامج: sliceweb]
الدليل = / 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):

! / بن / باش

مجموعة ه
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 = "- تصحيح الأخطاء - تصحيح مستوى السجل"

مستخدم / مجموعة ليتم تشغيلها باسم

USER = www-data
GROUP = www-data
cd $ WEBAPPDIR / webapp
اختبار -d $ LOGDIR || mkdir -p $ LOGDIR
صدى WebAppDir: $ WEBAPPDIR
صدى "المستخدم: $ USER"
صدى "المجموعة: $ 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

سؤال جيد حول الرأس الأخير. يُظهر تجميد النقطة أنه 0.14.1 (.2 هو الأحدث أليس كذلك؟)

هل حللت المشكلة؟ لدي نفس المشكلة وليس لدي حاليًا أي فكرة عن كيفية حلها.

يجب حلها نعم. أي إصدار من gunicorn تقوم بتشغيله؟ هل يمكنك تزويدي بمزيد من المعلومات حول التكوين الخاص بك حتى أتمكن من إعادة إنتاجه؟ شكرا.

لمpanyam حاولت مع 0.14.3؟

benoitc آسف

فقط للتوضيح لا أعتقد أن هذه مشكلة جونية. anyeguyue - أفضل مكان للتحقق من ذلك هو البحث في سجل المشرف أو سجل gunicorn (عادةً في / var / log / gunicorn / ....) لمعرفة ما إذا كان لديك خطأ "تم رفض الإذن" هناك.

لقد حصلت للتو على نفس المشكلة ، تم حلها عن طريق أول "python manager.py syncdb" مما أدى إلى حدوث خطأ. بعد إصلاح مشكلة الإعداد ، عمل Gunicorn (بعد إعادة تشغيل nginx).

لقد حللت هذه المشكلة أيضًا ولكن بطريقة مختلفة. كان السطر الأول من ملف gunicorn_django هو "#! / opt / django / env / mysite / bin / 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 الصورة المشكلة على #gunicorn. pythdasch ، هل يمكنك التأكيد؟

أؤكد ، بفضل بيركر :)

كان ملف wsgi الخاص بي في نفس المجلد الموجود به manager.py الخاص بي ، لذلك كان علي أن أضع مسار wsgi: التطبيق وليس المشروع. wsgi: التطبيق

(كان هذا هو المسار الخاطئ إلى wsgi. في هذه الحالة يجب أن يكون wsgi: application بدلاً من project.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 الخاص بي. takeway هنا هو أن gunicorn لا يعرض التتبع من التطبيق إذا تعطل العامل عند الإقلاع ، لذلك اضطررت إلى بدء تطبيق Flask يدويًا لمعرفة المشكلة الفعلية.

أتساءل عما إذا كان بإمكاننا جعله يعرض التتبع الفعلي

سيكون هذا لطيفا جدا. IMO ، أفضل شيء تالي ، إذا كان عرض traceback الأصلي غير ممكن ، هو تضمين رسالة تقترح تشغيل التطبيق مباشرة ، بدلاً من استخدام 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 أيضًا بالإضافة إلى الملف app.py . عملت بعد إعادة تسمية ملف بيثون.

brouberol لقد صادفت نفس المشكلة حتى الآن. عندما يحتوي تطبيق Flask على بعض الوحدات النمطية التي تسبب خطأ استيراد ، فلن يقوم Gunicorn بتسجيل التتبع ولكن خادم Flask المدمج يمكنه ذلك.

ما يمكننا القيام به هو أنه إذا فشل Gunicorn في تمهيد العامل بدون مزيد من المعلومات المحددة في أي سجل أخطاء ، فجرّب أولاً خادم Flask المدمج.

تشغيل guncorn مع - يستطيع التحميل المسبق رؤية سجل الأخطاء

بالنسبة لي ، عمل Django runserver بشكل جيد. كانت المشكلة هي استيراد ملف Django settings في الملف gunicorn.conf.py . أدت إزالة هذا الاستيراد إلى حل المشكلة.