Gunicorn: OSError: [Errno 9] واصف ملف تالف

تم إنشاؤها على ١٠ سبتمبر ٢٠١٨  ·  19تعليقات  ·  مصدر: benoitc/gunicorn

أواجه هذه المشكلة في صورة raspbian

[2018-09-10 20:40:11 +0800] [21421] [هام] مهلة العامل (رقم التعريف: 21699)
[2018-09-10 20:40:11 +0800] [21699] [خطأ] طلب معالجة خطأ مأخذ التوصيل.
Traceback (آخر مكالمة أخيرة):
ملف "/usr/lib/python3/dist-packages/gunicorn/workers/async.py" ، السطر 62 ، في المقبض
six.reraise (* sys.exc_info ())
ملف "/usr/lib/python3/dist-packages/gunicorn/six.py" ، السطر 625 ، قيد التطوير
رفع القيمة
ملف "/usr/lib/python3/dist-packages/gunicorn/workers/async.py" ، السطر 35 ، في المقبض
listener_name = listener.getsockname ()
OSError: [Errno 9] واصف ملف تالف

Feedback Requested Investigation

التعليق الأكثر فائدة

  1. يمكنني إعادة إنتاج خطأ السجل هذا من خلال الإعداد باستخدام gunicorn و uvicorn . تبدأ رسالة الخطأ هذه في الظهور مع uvicorn==0.11.4 وليس الإصدار السابق 0.11.3 (كلاهما في OSx وفي حاوية Linux). يتوافق هذا مع التقارير أعلاه مع uvicorn ، حيث تكون الإصدارات المبلغ عنها أكبر من 0.11.4 . الدليل في النهاية
  2. في ارتكاب المسؤولين عن هذا الخطأ غير هذه واحدة . تكمن المشكلة في هذه الأسطر القليلة من الالتزام المذكور للتو. يغير الالتزام فقط ترتيب كتلتين من التعليمات البرمجية. إذا عدت عن هذا التغيير في الترتيب ، فسيختفي خطأ السجل ، مع الاستمرار في اجتياز مجموعة الاختبار التي تبلغ uvicorn
  3. يحدث خطأ السجل نفسه إذا كان أحدهما: يستخدم starlette و fastapi أعلى المكدس gunicorn+uvicorn كما هو مذكور أعلاه ؛ - تشغيل أحدث إصدار من uvicorn 12.X بدلاً من 0.11.4 ؛ - يعمل بـ gunicorn مع أكثر من عامل واحد فقط uvicorn

دليل . في مجلد جديد على OSX ، قم بتشغيل البرنامج النصي المرفق test.sh (تم اختباره على OSX). للاختبار في حاوية Linux ، احفظ كل من البرنامج النصي وملف Docker ثم اقرأ رأس Dockerfile. أنا أيضا أرفق سجل البرنامج النصي.

benoitc ، ما رأيك في هذا الالتزام uvicorn الذي يبدو أنه يتسبب في حدوث الخطأ؟ يبدو أن المشكلة في الواجهة بين gunicorn و uvicorn . هل يمكنك التعليق على طلب كتلتين من الكود تم تغييرهما في الالتزام المذكور أعلاه في uvicorn ؟ قد يساعد هذا في معرفة سبب حدوث ذلك مع الحالات الأخرى أيضًا. حتى الآن تم الإبلاغ عن هذا أيضًا بـ aiohttp ، gevent ، Flask-SocketIO sanic . أرفق أيضًا سجل البرنامج النصي لتسهيله.

log_test.log

ملف _test.sh_

#!/bin/bash
python3 -m venv venv
source venv/bin/activate
pip install gunicorn==20.0.04 uvicorn==0.11.4
# create simple uvicorn app
printf "async def app(scope, receive, send):\n    await send()\n" > example.py
# spin up gunicorn with 1 uvicorn worker, and then send TERM signal to gunicorn
gunicorn example:app -w 1 -k uvicorn.workers.UvicornWorker &
sleep 5 && pkill -f gunicorn
sleep 1
# you will see 1 log entry like this one:
# [XX] [YY] [INFO] Error while closing socket [Errno 9] Bad file descriptor

printf "\n\n[INFO] if you instead bump down uvicorn's version from 11.4 to 11.3 [Errno 9] goes away:\n\n"
pip install uvicorn==0.11.3
gunicorn example:app -w 1 -k uvicorn.workers.UvicornWorker &
sleep 5 && pkill -f gunicorn

ملف _Dockerfile_

# run with:
# docker run -it $(docker build -q .)
FROM python:3.8
COPY test.sh .
RUN chmod +x /test.sh
CMD /test.sh

ال 19 كومينتر

@ leond08 شكرا على التذكرة!

لفهم كيفية حدوث ذلك ، هل يمكنك تقديم المزيد من المعلومات؟

  • أي إصدار من Gunicorn تقوم باختباره
  • أي عامل تستخدمه
  • متى يحدث هذا

أنا أستخدم أحدث إصدار من gunicorn3
أنا أستخدم Eventlet and gevent من أجل هذا
أقوم بتشغيل تطبيق flask الخاص بي - Flask-SocketIO

أبدأ مهمتي في الخلفية بعد أن قام المستخدم بالنقر فوق الزر
تتمثل وظيفتي الأساسية في الاستماع إلى حدث ما ،
بعد النقر فوق الزر "تم" ، يجب أن تتوقف مهمة الخلفية
ثم أرسل رسالة ترسل إلى جميع المستخدمين

واجهت نفس المشكلة مع aiohttp + gunicorn ، لاحظ نفس الرسالة في كل مرة عند استخدام ctrl + c.

[INFO] خطأ أثناء إغلاق المقبس [Errno 9] واصف ملف تالف

أنا لا أعيد إنتاجها. أظن أن طلبك يغلق بعض ملفات fds مما أدى إلى ظهور المشكلة أعلاه.

نحن نواجه نفس المشكلة ، الشيء الوحيد هو أنها تحدث فقط في 1 من 8 حاويات تعمل في سرب عمال التحميل.

لقد واجهنا نفس المشكلة مع 1 من 9 حاويات ، يبدو أنها مرتبطة بـ docker و python3 و gevent.

جونيكورن 20.0.4 + aiohttp 3.6.2

يعمل Gunicorn كخادم dev:

gunicorn --reload app:make_app --bind localhost:5000 --worker-class aiohttp.GunicornWebWorker --workers 2 --access-logfile -

ينتهي كل Ctrl + C تقريبًا بـ

^C[2020-05-23 21:49:50 +0200] [38524] [INFO] Handling signal: int
Exception ignored when trying to write to the signal wakeup fd:
Exception ignored when trying to write to the signal wakeup fd:
Traceback (most recent call last):
  File "/usr/lib/python3.8/asyncio/unix_events.py", line 42, in _sighandler_noop
Traceback (most recent call last):
  File "/usr/lib/python3.8/asyncio/unix_events.py", line 42, in _sighandler_noop
    def _sighandler_noop(signum, frame):
    def _sighandler_noop(signum, frame):
OSError: [Errno 9] Bad file descriptor
OSError: [Errno 9] Bad file descriptor
[2020-05-23 21:49:50 +0200] [38526] [INFO] Worker exiting (pid: 38526)
[2020-05-23 21:49:50 +0200] [38528] [INFO] Worker exiting (pid: 38528)
[2020-05-23 21:49:50 +0200] [38524] [INFO] Shutting down: Master

لا يهم ما إذا كان التطبيق قد تعامل مع أي طلب أم لا.

مع Sanic 20.3.0:

^C[2020-05-26 13:24:55 +0200] [27706] [INFO] Handling signal: int
[2020-05-26 13:24:55 +0200] [27769] [INFO] Stopping server: 27769, connections: 0
[2020-05-26 13:24:55 +0200] [27769] [INFO] Error while closing socket [Errno 9] Bad file descriptor
[2020-05-26 13:24:55 +0200] [27769] [INFO] Worker exiting (pid: 27769)
[2020-05-26 13:24:55 +0200] [27771] [INFO] Stopping server: 27771, connections: 0
[2020-05-26 13:24:55 +0200] [27771] [INFO] Error while closing socket [Errno 9] Bad file descriptor
[2020-05-26 13:24:55 +0200] [27771] [INFO] Worker exiting (pid: 27771)
[2020-05-26 13:24:55 +0200] [27706] [INFO] Shutting down: Master

نفس الشيء هنا مع فئة العمال Gunicorn 20.0.4 + Uvicorn 0.11.5 في كل Ctrl + C

INFO:     [12621] [gunicorn.error] Handling signal: int
INFO:     [12635] [gunicorn.error] Error while closing socket [Errno 9] Bad file descriptor
INFO:     [12634] [gunicorn.error] Error while closing socket [Errno 9] Bad file descriptor
INFO:     [12635] [gunicorn.error] Worker exiting (pid: 12635)
INFO:     [12634] [gunicorn.error] Worker exiting (pid: 12634)
INFO:     [12621] [gunicorn.error] Shutting down: Master

أي مثال على التطبيق؟ وأي إصدار من Python نتحدث عنه أيضًا؟

Ubuntu 20.04 ، قدم النظام Python 3.8.2 في virtualenv

مثال للتطبيق: https://github.com/zgoda/newsloop-server/tree/d603a1c10c9e8be3d998f62ccc55dd73f4677115 (مع aiohttp) أو https://github.com/zgoda/newsloop-server/tree/b2a8a7f09fa051b0384 الاحتجاج الدقيق gunicorn في تعليقي السابق.

تجعلني الاختلافات في الإخراج بين aiohttp و Sanic أشك في وجود شيء خاطئ يتعلق بالعاملين.

نفس المشكلة ، بيثون 3.8.0
سانك 19.12.2
جونيكورن 20.0.4

تحرير: يحدث هذا عندما أقوم بالتشغيل محليًا على جهاز Mac الخاص بي ، ولكن ليس عند التشغيل داخل عامل إرساء Linux ، قد يساعدك

مرحبا،
أعتقد أن هذه المشكلة https://github.com/benoitc/gunicorn/issues/2064 لها نفس الأسباب.
لدينا تقريبًا نفس الأخطاء كما في الإصدار ، لكننا نستخدم gunicorn - 19.9.0

أواجه هذا أيضًا ، FastAPI + أحدث عمال Gunicorn و uvicorn مع Python 3.8.5

بمجرد أن أتوقف عن استخدام uvicorn (على سبيل المثال ، أزل هذا الخط من تكوين gunicorn الخاص بي):

worker_class = "uvicorn.workers.UvicornWorker"

تختفي الأخطاء.

كما هو موضح أعلاه ، يحدث هذا عند إيقاف Gunicorn باستخدام Ctrl + C أو إرسال إشارة قتل رشيقة إلى PID.

[2020-09-12 11:56:37 +1000] [100390] [INFO] Starting gunicorn 20.0.4
[2020-09-12 11:56:37 +1000] [100390] [INFO] Listening at: http://0.0.0.0:6000 (100390)
[2020-09-12 11:56:37 +1000] [100390] [INFO] Using worker: uvicorn.workers.UvicornWorker
[2020-09-12 11:56:37 +1000] [100392] [INFO] Booting worker with pid: 100392
[2020-09-12 11:56:38 +1000] [100392] [INFO] Started server process [100392]
[2020-09-12 11:56:38 +1000] [100392] [INFO] Waiting for application startup.
[2020-09-12 11:56:38 +1000] [100392] [INFO] Application startup complete.
[2020-09-12 11:56:48 +1000] [100390] [INFO] Handling signal: term
[2020-09-12 11:56:48 +1000] [100392] [INFO] Shutting down
[2020-09-12 11:56:48 +1000] [100392] [INFO] Error while closing socket [Errno 9] Bad file descriptor
[2020-09-12 11:56:48 +1000] [100392] [INFO] Waiting for application shutdown.
[2020-09-12 11:56:48 +1000] [100392] [INFO] Application shutdown complete.
[2020-09-12 11:56:48 +1000] [100392] [INFO] Finished server process [100392]
[2020-09-12 11:56:48 +1000] [100392] [INFO] Worker exiting (pid: 100392)
[2020-09-12 11:56:48 +1000] [100390] [INFO] Shutting down: Master

إليك نسخة طبق الأصل من المشكلة:

[fots<strong i="6">@workstation</strong> testing]$ python3.8 -V
Python 3.8.5
[fots<strong i="7">@workstation</strong> testing]$ python3.8 -m venv ~/.virtualenv/testing
[fots<strong i="8">@workstation</strong> testing]$ source ~/.virtualenv/testing/bin/activate
(testing) [fots<strong i="9">@workstation</strong> testing]$ pip install fastapi gunicorn uvicorn
Collecting fastapi
  Using cached fastapi-0.61.1-py3-none-any.whl (48 kB)
Collecting gunicorn
  Using cached gunicorn-20.0.4-py2.py3-none-any.whl (77 kB)
Collecting uvicorn
  Using cached uvicorn-0.11.8-py3-none-any.whl (43 kB)
Collecting pydantic<2.0.0,>=1.0.0
  Using cached pydantic-1.6.1-cp38-cp38-manylinux2014_x86_64.whl (11.5 MB)
Collecting starlette==0.13.6
  Using cached starlette-0.13.6-py3-none-any.whl (59 kB)
Requirement already satisfied: setuptools>=3.0 in /home/fots/.virtualenv/testing/lib/python3.8/site-packages (from gunicorn) (47.1.0)
Collecting h11<0.10,>=0.8
  Using cached h11-0.9.0-py2.py3-none-any.whl (53 kB)
Collecting websockets==8.*
  Using cached websockets-8.1-cp38-cp38-manylinux2010_x86_64.whl (78 kB)
Collecting httptools==0.1.*; sys_platform != "win32" and sys_platform != "cygwin" and platform_python_implementation != "PyPy"
  Using cached httptools-0.1.1-cp38-cp38-manylinux1_x86_64.whl (227 kB)
Collecting uvloop>=0.14.0; sys_platform != "win32" and sys_platform != "cygwin" and platform_python_implementation != "PyPy"
  Using cached uvloop-0.14.0-cp38-cp38-manylinux2010_x86_64.whl (4.7 MB)
Collecting click==7.*
  Using cached click-7.1.2-py2.py3-none-any.whl (82 kB)
Installing collected packages: pydantic, starlette, fastapi, gunicorn, h11, websockets, httptools, uvloop, click, uvicorn
Successfully installed click-7.1.2 fastapi-0.61.1 gunicorn-20.0.4 h11-0.9.0 httptools-0.1.1 pydantic-1.6.1 starlette-0.13.6 uvicorn-0.11.8 uvloop-0.14.0 websockets-8.1
WARNING: You are using pip version 20.1.1; however, version 20.2.3 is available.
You should consider upgrading via the '/home/fots/.virtualenv/testing/bin/python3.8 -m pip install --upgrade pip' command.
(testing) [fots<strong i="10">@workstation</strong> testing]$ ls -l
total 4
-rw-rw-r-- 1 fots fots 117 Sep 12 12:13 main.py
(testing) [fots<strong i="11">@workstation</strong> testing]$ cat main.py
from fastapi import FastAPI

app = FastAPI()


@app.get("/")
async def root():
    return {"message": "Hello World"}
(testing) [fots<strong i="12">@workstation</strong> testing]$ gunicorn -k uvicorn.workers.UvicornWorker main:app
[2020-09-12 12:19:05 +1000] [105788] [INFO] Starting gunicorn 20.0.4
[2020-09-12 12:19:05 +1000] [105788] [INFO] Listening at: http://127.0.0.1:8000 (105788)
[2020-09-12 12:19:05 +1000] [105788] [INFO] Using worker: uvicorn.workers.UvicornWorker
[2020-09-12 12:19:05 +1000] [105790] [INFO] Booting worker with pid: 105790
[2020-09-12 12:19:05 +1000] [105790] [INFO] Started server process [105790]
[2020-09-12 12:19:05 +1000] [105790] [INFO] Waiting for application startup.
[2020-09-12 12:19:05 +1000] [105790] [INFO] Application startup complete.
^C[2020-09-12 12:19:06 +1000] [105788] [INFO] Handling signal: int
[2020-09-12 12:19:06 +1000] [105790] [INFO] Shutting down
[2020-09-12 12:19:06 +1000] [105790] [INFO] Error while closing socket [Errno 9] Bad file descriptor
[2020-09-12 12:19:06 +1000] [105790] [INFO] Waiting for application shutdown.
[2020-09-12 12:19:06 +1000] [105790] [INFO] Application shutdown complete.
[2020-09-12 12:19:06 +1000] [105790] [INFO] Finished server process [105790]
[2020-09-12 12:19:06 +1000] [105790] [INFO] Worker exiting (pid: 105790)
[2020-09-12 12:19:07 +1000] [105788] [INFO] Shutting down: Master

وإليك الناتج pip freeze :

click==7.1.2
fastapi==0.61.1
gunicorn==20.0.4
h11==0.9.0
httptools==0.1.1
pydantic==1.6.1
starlette==0.13.6
uvicorn==0.11.8
uvloop==0.14.0
websockets==8.1

حاولت تثبيت uvicorn و gunicorn من GitHub (الفرع الرئيسي) للتأكد من أنني حصلت على أحدث الإصلاحات ولكن المشكلة استمرت.

أتمنى أن يساعدك هذا
فوتيس

  1. يمكنني إعادة إنتاج خطأ السجل هذا من خلال الإعداد باستخدام gunicorn و uvicorn . تبدأ رسالة الخطأ هذه في الظهور مع uvicorn==0.11.4 وليس الإصدار السابق 0.11.3 (كلاهما في OSx وفي حاوية Linux). يتوافق هذا مع التقارير أعلاه مع uvicorn ، حيث تكون الإصدارات المبلغ عنها أكبر من 0.11.4 . الدليل في النهاية
  2. في ارتكاب المسؤولين عن هذا الخطأ غير هذه واحدة . تكمن المشكلة في هذه الأسطر القليلة من الالتزام المذكور للتو. يغير الالتزام فقط ترتيب كتلتين من التعليمات البرمجية. إذا عدت عن هذا التغيير في الترتيب ، فسيختفي خطأ السجل ، مع الاستمرار في اجتياز مجموعة الاختبار التي تبلغ uvicorn
  3. يحدث خطأ السجل نفسه إذا كان أحدهما: يستخدم starlette و fastapi أعلى المكدس gunicorn+uvicorn كما هو مذكور أعلاه ؛ - تشغيل أحدث إصدار من uvicorn 12.X بدلاً من 0.11.4 ؛ - يعمل بـ gunicorn مع أكثر من عامل واحد فقط uvicorn

دليل . في مجلد جديد على OSX ، قم بتشغيل البرنامج النصي المرفق test.sh (تم اختباره على OSX). للاختبار في حاوية Linux ، احفظ كل من البرنامج النصي وملف Docker ثم اقرأ رأس Dockerfile. أنا أيضا أرفق سجل البرنامج النصي.

benoitc ، ما رأيك في هذا الالتزام uvicorn الذي يبدو أنه يتسبب في حدوث الخطأ؟ يبدو أن المشكلة في الواجهة بين gunicorn و uvicorn . هل يمكنك التعليق على طلب كتلتين من الكود تم تغييرهما في الالتزام المذكور أعلاه في uvicorn ؟ قد يساعد هذا في معرفة سبب حدوث ذلك مع الحالات الأخرى أيضًا. حتى الآن تم الإبلاغ عن هذا أيضًا بـ aiohttp ، gevent ، Flask-SocketIO sanic . أرفق أيضًا سجل البرنامج النصي لتسهيله.

log_test.log

ملف _test.sh_

#!/bin/bash
python3 -m venv venv
source venv/bin/activate
pip install gunicorn==20.0.04 uvicorn==0.11.4
# create simple uvicorn app
printf "async def app(scope, receive, send):\n    await send()\n" > example.py
# spin up gunicorn with 1 uvicorn worker, and then send TERM signal to gunicorn
gunicorn example:app -w 1 -k uvicorn.workers.UvicornWorker &
sleep 5 && pkill -f gunicorn
sleep 1
# you will see 1 log entry like this one:
# [XX] [YY] [INFO] Error while closing socket [Errno 9] Bad file descriptor

printf "\n\n[INFO] if you instead bump down uvicorn's version from 11.4 to 11.3 [Errno 9] goes away:\n\n"
pip install uvicorn==0.11.3
gunicorn example:app -w 1 -k uvicorn.workers.UvicornWorker &
sleep 5 && pkill -f gunicorn

ملف _Dockerfile_

# run with:
# docker run -it $(docker build -q .)
FROM python:3.8
COPY test.sh .
RUN chmod +x /test.sh
CMD /test.sh

كان لدي نفس المشكلة بالضبط. ها هي حالتي.

موجز: أحاول إنشاء تطبيق اختبار لـ Django dwebsocket مع gunicorn. عندما أحاول استخدام websocket_client لاختبار النتيجة ، يحدث هذا الخطأ في كل مرة بعد إغلاق مقبس الويب.

بيئة :
صورة عامل ميناء: بيثون: 3.7
إصدار python: python3.7.6
gunicorn: الإصدار = 20.0.4 ، العمل = gevent
إصدار Django: Django == 2.2
إصدار dwebsocket: 0.5.12

رمز:

view.py

from dwebsocket import accept_websocket

<strong i="16">@accept_websocket</strong>
def my_ws(request):
    if request.is_websocket():
        ws = request.websocket
        while True:
            msg = ws.wait(timeout=15)
            if msg is None:
                print('get None message')
                break
            else:
                msg = b'echo :' + msg
                ws.send(msg)
                print('send ws seccess')
        print('websocket close')

urls.py

from websocketInfo.views import  my_ws
from django.conf.urls import url

urlpatterns = [
    url(r'my_ws/$', my_ws, name='my_ws')
]

websocket_client

from websocket import create_connection
ws = create_connection("ws://127.0.0.1:8080/my_ws/")
print("Sending 'Hello, World'...")
ws.send("Hello, World")
print("Receiving...")
result = ws.recv()
print(result)
ws.close()
print('ws close')

أمر لتشغيل خادم gunicorn

gunicorn MyWebsocket.wsgi -b 0.0.0.0:8000 -w 3 -k gevent

خرج الخطأ

send ws seccess
get None message
websocket close
[2021-01-13 02:43:56 +0000] [101] [ERROR] Socket error processing request.
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/base_async.py", line 65, in handle
    util.reraise(*sys.exc_info())
  File "/usr/local/lib/python3.7/site-packages/gunicorn/util.py", line 625, in reraise
    raise value
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/base_async.py", line 55, in handle
    self.handle_request(listener_name, req, client, addr)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/ggevent.py", line 143, in handle_request
    super().handle_request(listener_name, req, sock, addr)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/base_async.py", line 128, in handle_request
    util.reraise(*sys.exc_info())
  File "/usr/local/lib/python3.7/site-packages/gunicorn/util.py", line 625, in reraise
    raise value
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/base_async.py", line 114, in handle_request
    resp.write(item)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/http/wsgi.py", line 326, in write
    self.send_headers()
  File "/usr/local/lib/python3.7/site-packages/gunicorn/http/wsgi.py", line 322, in send_headers
    util.write(self.sock, util.to_bytestring(header_str, "latin-1"))
  File "/usr/local/lib/python3.7/site-packages/gunicorn/util.py", line 286, in write
    sock.sendall(data)
  File "/usr/local/lib/python3.7/site-packages/gevent/_socket3.py", line 523, in sendall
    return _socketcommon._sendall(self, data_memory, flags)
  File "/usr/local/lib/python3.7/site-packages/gevent/_socketcommon.py", line 367, in _sendall
    chunk_size = max(socket.getsockopt(SOL_SOCKET, SO_SNDBUF), 1024 * 1024)
  File "/usr/local/lib/python3.7/site-packages/gevent/_socket3.py", line 156, in __getattr__
    return getattr(self._sock, name)
  File "/usr/local/lib/python3.7/site-packages/gevent/_socket3.py", line 66, in _dummy
    raise OSError(EBADF, 'Bad file descriptor')
OSError: [Errno 9] Bad file descriptor

ChrisXiaoShu يخبرنا تتبع المكدس الذي نشرته أن كائن المقبس المحدد هذا قد تم إغلاقه بشكل صريح على مستوى Python (وذلك عندما تستخدم gevent _dummy لإنشاء الاستثناءات نفسها التي يقوم بها نظام التشغيل). هذا يعني أن جزءًا من مكدس التطبيق الخاص بك يقوم بإغلاق المقبس قبل إعادة الاستجابة للسماح لـ gunicorn بمعالجته ؛ عند حدوث الخطأ ، لم يرسل gunicorn حتى رؤوس استجابة HTTP.

نوع من نفس المشكلة في حالتي ، مع اختلاف أن هذا الخطأ يحدث دون فعل أي شيء. أحيانًا بعد 5 دقائق ، وأحيانًا بعد ساعتين ...

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات