Gunicorn: OSError: [त्रुटि 0] त्रुटि

मेरी स्मृति से, यह त्रुटि तब होती है जब कोई क्लाइंट एसएसएल के बिना कनेक्ट करने का प्रयास करता है। क्या आपके साथ ऐसा हो सकता है?

मैं आपकी पोस्ट को दूसरे मुद्दे पर देखता हूं जिसे मैंने बंद कर दिया है। अगर मेरी टिप्पणी का कारण नहीं है तो क्षमा करें।

क्या कोई पैटर्न है जिसके लिए अनुरोध इस तरह विफल हो जाते हैं?

@usmetanina किस तरह के ग्राहक Gunicorn से भी जुड़ते हैं? क्या आपके पास इससे कनेक्ट करने के लिए स्पष्ट रूप से उपयोग किया गया कोई SSL विकल्प है?

क्या यह पहले ही हल हो गया है? @usmetanina , क्योंकि मेरे पास बिल्कुल वही समस्या है

@benoitc मुझे अक्सर python3.6 और gunicorn 19.9.0 का उपयोग करके @usmetanina की सटीक त्रुटि दिखाई देती है ।

मैं डॉकटर कंटेनर के भीतर चल रहे फ्लास्क ऐप के साथ गनिकोर्न शुरू करने के लिए नीचे दी गई जानकारी का उपयोग करता हूं।

gunicorn --workers=3 --bind=0.0.0.0:8000 --config=gunicorn_config.py --preload main

कॉन्फ़िगरेशन फ़ाइल इस तरह दिखती है (डोमेन-with-cert.com निश्चित रूप से वास्तविक डोमेन नाम के लिए प्लेसहोल्डर है):

workers = 3
bind = '0.0.0.0:443'
certfile = '/etc/letsencrypt/live/domain-with-cert.com/fullchain.pem'
keyfile = '/etc/letsencrypt/live/domain-with-cert.com/privkey.pem'

इसे डिबग करने पर कोई विचार सहायक होगा। अगर आपको और जानकारी चाहिए तो बस मुझे बताएं।

@willpatera , मेरी टिप्पणी देखें:

मेरी स्मृति से, यह त्रुटि तब होती है जब कोई क्लाइंट एसएसएल के बिना कनेक्ट करने का प्रयास करता है। क्या आपके साथ ऐसा हो सकता है?

@tilgovi मैंने उपरोक्त टिप्पणी देखी। मुझे पूरा यकीन है कि क्लाइंट एसएसएल से जुड़ रहा है। कोई डिबगिंग सुझाव?

@willpatera मैं कहूंगा, एक्सेस लॉग चालू करें और देखें कि क्या आप यह निर्धारित कर सकते हैं कि कौन सा अनुरोध समस्या का कारण बनता है। यदि आपके पास गनिकोर्न के सामने एक रिवर्स प्रॉक्सी है, तो सुनिश्चित करें कि इसमें एक्सेस लॉग हैं ताकि आप देख सकें कि कौन सा अनुरोध गनिकोर्न के साथ त्रुटि का कारण बनता है, भले ही गनिकोर्न इसे कभी लॉग न करे।

@tilgovi मुझे वही समस्याएं आ रही हैं। निम्नलिखित जानकारी को थोड़ा संपादित करना पड़ा क्योंकि यह गलत थी:
गनिकोर्न के लिए जो अनुरोध किया जा रहा है वह हमेशा एक ही अनुरोध है (लेकिन एक अलग शरीर के साथ)। तो इसमें कोई शक नहीं कि यह https है न कि http।
मैं जो नोटिस करता हूं वह यह है कि यह हमेशा तब होता है जब अनुरोधों की मात्रा बढ़ रही होती है। जब सर्वर व्यस्त होता है तो ऐसा लगता है कि अनुरोधों को ठीक से संभालने में परेशानी हो रही है।

हो सकता है कि इसका श्रमिकों से कोई लेना-देना हो या ऐसा ही कुछ? यदि आपके पास कोई कॉन्फ़िगरेशन सुझाव है तो मैं खुशी से उनका परीक्षण करना चाहूंगा।

हाय दोस्तों, मैं अभी भी इसे हल करने का एक तरीका ढूंढ रहा हूं। वर्तमान में हमारे पास एकमात्र विकल्प सादा HTTP में डाउनग्रेड करना है, जो बिल्कुल भी संभव नहीं है।

मैंने वही देखा है। Gunicorn + Flask (एक लोड बैलेंसर के पीछे) चलाने वाला एक प्रोडक्शन सर्वर था जो महीनों तक ठीक रहा, फिर अचानक हर अनुरोध में यह त्रुटि हुई जब तक कि मैंने Gunicorn को फिर से शुरू नहीं किया:

[2019-11-21 07:27:36 +0000] [24245] [ERROR] Socket error processing request.
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/workers/sync.py", line 134, in handle
    req = six.next(parser)
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/http/parser.py", line 41, in __next__
    self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/http/message.py", line 181, in __init__
    super(Request, self).__init__(cfg, unreader)
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/http/message.py", line 54, in __init__
    unused = self.parse(self.unreader)
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/http/message.py", line 193, in parse
    self.get_data(unreader, buf, stop=True)
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/http/message.py", line 184, in get_data
    data = unreader.read()
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/http/unreader.py", line 38, in read
    d = self.chunk()
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/http/unreader.py", line 65, in chunk
    return self.sock.recv(self.mxchunk)
  File "/usr/lib/python3.6/ssl.py", line 997, in recv
    return self.read(buflen)
  File "/usr/lib/python3.6/ssl.py", line 874, in read
    return self._sslobj.read(len, buffer)
  File "/usr/lib/python3.6/ssl.py", line 633, in read
    v = self._sslobj.read(len)
OSError: [Errno 0] Error

इन त्रुटियों से पहले के लॉग में कुछ भी संकेत नहीं करता है कि ट्रिगर क्या हो सकता था।

यह Gunicorn 19.9.0 के साथ सिंगल-कोरेड सर्वर पर 3 कर्मचारियों के साथ चल रहा था।

चूंकि यह पहली बार है जब मैंने इस मुद्दे को देखा है, मैं वादा नहीं कर सकता कि मैं इसे कभी भी पुन: पेश करूंगा। हालांकि, अगर कोई लॉगिंग या अन्य डायग्नोस्टिक कोड है, तो कोई भी मुझे अपने सर्वर पर जोड़ना चाहेगा जो कि फिर से होने की स्थिति में कुछ उपयोगी जानकारी प्रदान कर सके, मैं सभी के लिए तैयार हूं।

क्या आपका एलबी एक विशिष्ट समापन बिंदु कहता है? यह एलबी अनुरोध का उत्तर कैसे देता है?

जब मैंने "लोड बैलेंसर" कहा, तो मुझे वास्तव में सीडीएन या कैशिंग लेयर कहना चाहिए था। विशेष रूप से: यह अमेज़ॅन क्लाउडफ़्रंट है। यह हमारे Gunicorn सर्वर (EC2 इंस्टेंस पर चल रहा है) के अनुरोधों पर आगे बढ़ता है और कुछ समय के लिए परिणामों को कैश करता है।

एचआरएम को अमेज़ॅन क्लाउडफ़्रंट आपके लिए एसएसएल अनुरोध समाप्त नहीं करना चाहिए? @ एक्सप्लोडिंग गोभी । गनिकोर्न को ssl पर क्यों सुनना पड़ता है?

@benoitc तो, एसएसएल के साथ आर्किटेक्चर में शामिल दो परतें हैं। HTTPS पर हमारे CloudFront डोमेन के माध्यम से हमारी वेबसाइट पर सार्वजनिक कनेक्ट के सदस्य, और फिर CloudFront Gunicorn चल रहा है, यह भी HTTPS का उपयोग करके (एक अलग डोमेन नाम और प्रमाणपत्र के साथ) हमारे बैकएंड नोड के लिए अनुरोध करता है, परिणाम कैश, और करने के लिए यह कार्य करता है सह लोक।

मुझे लगता है कि शायद आप सोच रहे हैं कि उस सेकेंड के लिए एसएसएल का उपयोग करने का क्या मतलब है, आंतरिक अनुरोध है? यह निश्चित रूप से बहस योग्य है यह व्यर्थ है (हालांकि संभवतः नहीं - यह अमेज़ॅन को अपने आंतरिक नेटवर्क में हमारे कॉम पर जासूसी करना बंद कर देता है, और ऐसे नियामक कारण भी हैं जिनमें मैं नहीं जाऊंगा, मेरी कंपनी के उद्योग को देखते हुए, हमें यह सुनिश्चित करने की आवश्यकता हो सकती है कि हमें मिल गया है पाइपलाइन के साथ सभी तरह से एन्क्रिप्शन)। व्यर्थ है या नहीं, हम करते हैं। \_(ツ)_/¯

क्या ऐसा हो सकता है कि क्लाउडफ़्रंट आपके एंडपॉइंट पर एक सादा HTTP अनुरोध भेज रहा हो? यदि आपके पास क्लाउडफ़्रंट लॉग तक पहुंच है, तो आपको इसे देखने में सक्षम होना चाहिए।

@benoitc मुझे नहीं लगता कि CloudFront किसी भी लॉग को उजागर करता है जो उपयोगी होगा, लेकिन मुझे यकीन है कि यह HTTP से कनेक्ट करने का प्रयास नहीं कर रहा था, क्योंकि:

• हमारा वितरण "केवल HTTPS" पर Gunicorn मूल से कनेक्ट करने के लिए CloudFront कंसोल में कॉन्फ़िगर किया गया है
• पोर्ट 80 . पर Gunicorn नहीं सुन रहा है
• अगर मैं HTTP पर हमारे बैकएंड सर्वर से कनेक्ट करने का प्रयास करता
• जब मुझे ऊपर उद्धृत OSError मिल रहा था, तो बैकएंड सर्वर पर Gunicorn को फिर से शुरू करने से समस्या तुरंत ठीक हो गई, जो कि Gunicorn छोर पर कुछ गलत होने की ओर इशारा करता है, क्लाउडफ्रंट के अंत में नहीं

@ExplodingCabbage ठीक है मैं 20.0.1 के बाहर होने के बाद इस पर एक नज़र डालूंगा। एक आखिरी बात, आप पायथन के किस संस्करण का उपयोग कर रहे हैं?

3.6.8

मुझे एहसास हुआ कि मैंने ऊपर अपनी कहानी से एक विवरण छोड़ दिया है: Gunicorn को फिर से शुरू करने से पहले, मैंने SSL प्रमाणपत्र Gunicorn को LetsEncrypt के साथ अपडेट किया। मैंने इसका उल्लेख करने के लिए नहीं सोचा था क्योंकि मैंने कल गलत निष्कर्ष निकाला था कि ऐसा कोई तरीका नहीं था कि जिस दिन त्रुटियां शुरू हुईं और प्रमाणपत्र अद्यतन वास्तव में समस्या को ठीक करने के लिए प्रासंगिक नहीं था, उस दिन प्रमाणपत्र समाप्त हो जाएगा।

हालाँकि, कुछ लॉग की जाँच करने से, मुझे अब पता चला है कि त्रुटियाँ वास्तव में उस दिन शुरू हुई थीं जब पिछले प्रमाणपत्र की समय सीमा समाप्त होने वाली थी।

यहां अभी भी कुछ रहस्य है, और सुधार के लिए कुछ संभावित कमरा (वास्तव में यह त्रुटि क्या दर्शाती है, और गनिकोर्न एक अधिक उपयोगी संदेश क्यों नहीं दे सकता है?), लेकिन मैंने पहले जो कथा दी थी - जिसमें यह त्रुटि नीले रंग से शुरू हुई थी बिना किसी स्पष्ट कारण के - सही नहीं है। मुझे लगता है कि CloudFront Gunicorn सर्वर से एक समय सीमा समाप्त प्रमाणपत्र को देखने के जवाब में कनेक्शन को समाप्त कर रहा था, और Gunicorn, इसे समझने और इसे सार्थक रूप से रिपोर्ट करने में सक्षम होने के बजाय, एक संदेश रहित OSError बबल अप देता है।

रिपोर्ट करने से पहले मेरे बत्तखों को एक पंक्ति में नहीं रखने के लिए मैं क्षमा चाहता हूँ। दूसरी ओर, यदि आप परिदृश्य को अधिक सुरुचिपूर्ण ढंग से आज़माना और संभालना चाहते हैं, तो शायद यह इस अपवाद को अपनी इच्छानुसार पुन: पेश करना आसान बना देगा।

@ExplodingCabbage ओह यह काफी

मैंने अभी एक ही समस्या में पुनरुत्पादित रूप से भाग लिया है और मुझे कुछ हद तक विश्वास है कि यह किसी प्रकार की संसाधन थकावट का परिणाम है।

मेरे लिए यह एक अवरुद्ध कॉल और अनुरोधों को जमा करने पर एक टाइमआउट भूलकर ट्रिगर किया गया था।

एचटीएच

नमस्कार! मैं इस सटीक मुद्दे का अनुभव कर रहा हूं। मेरे पास नेटवर्क लोड बैलेंसर के पीछे एक ईसीएस क्लस्टर पर चलने वाली एक बंदूक/फ्लास्क सेवा है। कुछ संस्करण विशिष्टता:

python    - 3.7.4
gunicorn  - 19.9.0
flask     - 1.0.4

सेवा बिना किसी समस्या के टीएलएस का उपयोग करने वाले क्लाइंट से आने वाले अनुरोधों का जवाब देने में सक्षम है, हालांकि मेरे लॉग OSErrors से भरे हुए हैं। जहां तक ​​मैं बता सकता हूं, ये लोड बैलेंसर (टीसीपी) से आने वाले स्वास्थ्य जांच अनुरोधों के परिणामस्वरूप हैं।

मैं सुनने वाले बंदरगाह पर मैन्युअल रूप से एक टीसीपी कनेक्शन खोलकर और बंद करके स्थानीय रूप से त्रुटि को पुन: उत्पन्न करने में सक्षम था (इस मामले में 8000):

$ nc -vz 127.0.0.1 8000
localhost [127.0.0.1] 8000 (irdmi) open

जिसके परिणामस्वरूप निम्नलिखित त्रुटि फेंकी जा रही है:

Traceback (most recent call last):
    File "/nix/store/nh3v0c2nipihwblkdn0mh2kqyv3jq9nz-python3-3.7.4-env/lib/python3.7/site-packages/gunicorn/workers/sync.py" line 134 in handle
        req = six.next(parser)
    File "/nix/store/nh3v0c2nipihwblkdn0mh2kqyv3jq9nz-python3-3.7.4-env/lib/python3.7/site-packages/gunicorn/http/parser.py" line 41 in __next__
        self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
    File "/nix/store/nh3v0c2nipihwblkdn0mh2kqyv3jq9nz-python3-3.7.4-env/lib/python3.7/site-packages/gunicorn/http/message.py" line 181 in __init__
        super(Request, self).__init__(cfg, unreader)
    File "/nix/store/nh3v0c2nipihwblkdn0mh2kqyv3jq9nz-python3-3.7.4-env/lib/python3.7/site-packages/gunicorn/http/message.py" line 54 in __init__
        unused = self.parse(self.unreader)
    File "/nix/store/nh3v0c2nipihwblkdn0mh2kqyv3jq9nz-python3-3.7.4-env/lib/python3.7/site-packages/gunicorn/http/message.py" line 193 in parse
        self.get_data(unreader, buf, stop=True)
    File "/nix/store/nh3v0c2nipihwblkdn0mh2kqyv3jq9nz-python3-3.7.4-env/lib/python3.7/site-packages/gunicorn/http/message.py" line 184 in get_data
        data = unreader.read()
    File "/nix/store/nh3v0c2nipihwblkdn0mh2kqyv3jq9nz-python3-3.7.4-env/lib/python3.7/site-packages/gunicorn/http/unreader.py" line 38 in read
        d = self.chunk()
    File "/nix/store/nh3v0c2nipihwblkdn0mh2kqyv3jq9nz-python3-3.7.4-env/lib/python3.7/site-packages/gunicorn/http/unreader.py" line 65 in chunk
        return self.sock.recv(self.mxchunk)
    File "/nix/store/azwzsm1pkbzjxpkiq88w68p4jdghgasl-python3-3.7.4/lib/python3.7/ssl.py" line 1056 in recv
        return self.read(buflen)
    File "/nix/store/azwzsm1pkbzjxpkiq88w68p4jdghgasl-python3-3.7.4/lib/python3.7/ssl.py" line 931 in read
        return self._sslobj.read(len)
OSError: [Errno 0] Error

उम्मीद है ये मदद करेगा!

हम्म, कुछ अतिरिक्त शोध के बाद ऐसा लगता है कि यह वास्तव में एक बग हो सकता है जिस तरह से पाइथन ssl लाइब्रेरी लिनक्स पर रैग्ड ईओएफ को संभालती है: https://bugs.python.org/issue31122

जैसा कि @shevisjohnson द्वारा उल्लेख किया गया है यदि आप "nc -vz hostname port_no" निष्पादित
हम नीचे लॉगिंग तंत्र का उपयोग करके लॉग फ़ाइल में इस त्रुटि को दबा सकते हैं।

$cat logging_config.yml

version: 1

formatters:
  simple:
    format: " %(asctime)s || %(name)s || %(levelname)s || %(message)s"

  test_api:
    format: "[%(asctime)s] [%(process)s] [%(levelname)s] %(message)s"

handlers:

  console:
    class: logging.StreamHandler
    level: DEBUG
    formatter: simple
    stream: ext://sys.stdout

  test_api_file_handler:
     class: logging.handlers.RotatingFileHandler
     level: DEBUG
     formatter: test_api
     filename: logs/test.log
     maxBytes: 2000000000
     backupCount: 1
     encoding: utf8

loggers:

  test_api: 
    level: DEBUG
    handlers: [test_api_file_handler]
    propagate: 0

root:
  level: DEBUG
  handlers: [console]

यहाँ पायथन फ़ाइल है।

import logging
import yaml
from flask import Flask

app = Flask(__name__)

def logSetter(logger_name:str) -> logging:
    with open("logging_config.yml", 'r') as f:
        config = yaml.safe_load(f)
    logging.config.dictConfig(config)
    logger = logging.getLogger(logger_name)
    return logger

logger=logSetter(logger_name="test_api")

@app.route("/api/test")
def hello():
     app.logger.info("hey from api")
     return "Hello from Python!"

आशा है कि इससे सहायता मिलेगी।

हमने देखा है कि कई Gunicorn ऐप्स समवर्ती लोड के दौरान उत्पादन में इस त्रुटि के साथ विफल हो रहे हैं।

विश्वसनीय पुनरुत्पादन के साथ आने में केवल एक क्षण लगा: hey का उपयोग करके gthread कार्यकर्ता का उपयोग करके नवीनतम Gunicorn (20.0.4) को 100 समवर्ती अनुरोध भेजने के लिए:

$ hey -n 100 -c 100 https://127.0.0.1:8000

```
$ गनिकोर्न ऐप: ऐप -k gthread --certfile=... --keyfile=...
...
[2020-07-11 19:10:58 +0000] [3628247] [त्रुटि] सॉकेट त्रुटि प्रसंस्करण अनुरोध।
ट्रेसबैक (सबसे हालिया कॉल अंतिम):
वापसी स्वयं._sslobj.read(len)
OSError: [त्रुटि 0] त्रुटि

Using a Debian 9 / Linux 4.14.67 based environment.

The WSGI app to reproduce need not be anything beyond:
```python
# app.py
def app(environ, start_response):
    start_response("200 OK", [])
    return ""

मामले में यह भी मदद करता है!

यदि मूल कारण वास्तव में https://bugs.python.org/issue31122 है :

• 4 मार्च को एक फिक्स सबमिट किया गया था (पायथन/सीपीथन # 18772), लेकिन इसे अभी भी कोर डेवलपर द्वारा स्वीकार नहीं किया गया है। शायद एक Gunicorn अनुरक्षक वहाँ एक टिप्पणी छोड़कर या BPO-31122 पर यह कहते हुए कि यह gunicorn उपयोगकर्ताओं को प्रभावित कर रहा है, मदद करेगा?
• Gunicorn को अभी भी Python के समर्थित संस्करणों के लिए इसके आसपास काम करने की आवश्यकता होगी जो कि जारी होने वाले फिक्स को पूर्व निर्धारित करते हैं। यह भी पूछने लायक है कि क्या उसी टिप्पणी में कोई समाधान है?

यह मेरे संगठन को उत्पाद में भी प्रभावित कर रहा है।

मैंने देखा कि बगफिक्स 3.8 और 3.9 शाखाओं में उतरा, लेकिन वे <= 3.7 ईओएल पर विचार कर रहे हैं और हम अभी भी थोड़े समय के लिए 3.6 पर अटके हुए हैं। क्या इस समय इस मुद्दे का कोई ज्ञात समाधान गनिकोर्न में ही है? क्या कुछ योजनाबद्ध है?

हम देख रहे हैं कि इसे ट्रिगर करने के लिए सेवा को इतना अधिक क्या कहा जा सकता है, लेकिन मैं सिर्फ यह पता लगाने की कोशिश कर रहा हूं कि क्या किया जा सकता है, क्योंकि इसके परिणामस्वरूप प्रभावित नोड्स पर भारी संसाधन स्पाइक्स होते हैं।

3.8 से पहले बैकपोर्ट करने का कोई इरादा नहीं होने के बारे में जिड्डी की टिप्पणी के अलावा, अगर किसी और को यह समस्या हो रही है, तो यह भी ध्यान दें कि फिक्स को CPython 3.8.6 में शामिल किया जाना तय है ।

यह बताने में परेशानी हो रही है कि यह ट्रेसबैक कहां से निकलता है - मेरे मामले में, gevent का उपयोग सीधे डब्लूएसजीआई ऐप सर्वर के रूप में करते हुए, इसलिए यह मानते हुए कि यह गीवेंट/ग्रीनलेट के भीतर कहीं लॉगिंग कॉल है, लेकिन इसे अभी तक नहीं मिल रहा है। Gunicorn के लिए, यह यहाँ होता है, तुल्यकालिक श्रमिकों के लिए:

https://github.com/benoitc/gunicorn/blob/e636bf81989bb833d2b99104feb11e86c3f2c43a/gunicorn/workers/sync.py#L150

Gunicorn मामले में, यदि आप केवल लॉग में शोर के बारे में चिंतित हैं, तो कुछ ऐसा करने में सक्षम हो सकते हैं जैसे:

import logging

class HandshakeFilter(logging.Filter):
    # example: https://docs.python.org/3/howto/logging-cookbook.html
    # I have not tested this
    def filter(self, record):
        return "socket error processing request" in record.msg.casefold()

logging.getLogger("gunicorn").addFilter(HandshakeFilter())

संबंधित gevent मुद्दा: https://github.com/gevent/gevent/issues/1671