लिनक्स कर्नेल द्वारा FIN_WAIT2 राज्य में कनेक्शन बंद क्यों नहीं किए गए हैं?


11

मेरे पास एक लंबे समय से चली आ रही प्रक्रिया में एक समस्या है जिसे क्यूब-प्रॉक्सी को कुबेरनेट्स का हिस्सा कहा जाता है ।

समस्या यह है कि समय-समय पर एक कनेक्शन FIN_WAIT2 राज्य में छोड़ दिया जाता है।

$ sudo netstat -tpn | grep FIN_WAIT2
tcp6       0      0 10.244.0.1:33132        10.244.0.35:48936       FIN_WAIT2   14125/kube-proxy
tcp6       0      0 10.244.0.1:48340        10.244.0.35:56339       FIN_WAIT2   14125/kube-proxy
tcp6       0      0 10.244.0.1:52619        10.244.0.35:57859       FIN_WAIT2   14125/kube-proxy
tcp6       0      0 10.244.0.1:33132        10.244.0.50:36466       FIN_WAIT2   14125/kube-proxy

ये कनेक्शन समय के साथ प्रक्रिया को गलत बनाते हुए ढेर हो जाते हैं। मैंने पहले से ही Kubernetes बग-ट्रैकर के लिए एक समस्या की सूचना दी थी, लेकिन मैं यह समझना चाहूंगा कि लिनक्स कर्नेल द्वारा ऐसे कनेक्शन बंद क्यों नहीं किए जाते हैं।

अपने प्रलेखन (tcp_fin_timeout के लिए खोज) के अनुसार FIN_WAIT2 राज्य में कनेक्शन X सेकंड के बाद कर्नेल द्वारा बंद कर दिया जाना चाहिए, जहां X को / proc से पढ़ा जा सकता है। मेरी मशीन पर यह 60 पर सेट है:

$ cat /proc/sys/net/ipv4/tcp_fin_timeout
60

इसलिए अगर मैं इसे सही ढंग से समझता हूं तो ऐसे कनेक्शन 60 सेकंड तक बंद होने चाहिए। लेकिन यह मामला नहीं है, उन्हें ऐसे राज्य में घंटों के लिए छोड़ दिया जाता है।

जबकि मैं यह भी समझता हूं कि FIN_WAIT2 कनेक्शन बहुत असामान्य हैं (इसका मतलब है कि मेजबान कनेक्शन के दूरस्थ छोर से कुछ एसीके के लिए इंतजार कर रहा है जो पहले से ही चले गए हो सकते हैं) मुझे नहीं मिलता कि ये कनेक्शन सिस्टम द्वारा "बंद" क्यों नहीं हैं ।

वहाँ कुछ भी मैं इसके बारे में कर सकता है?

ध्यान दें कि संबंधित प्रक्रिया को पुनरारंभ करना एक अंतिम उपाय है।


1
वैसे, फिन- WAIT2 में, कनेक्शन एक एसीके के लिए इंतजार नहीं कर रहा है (यह भेजा गया फिन पहले ही स्वीकार कर लिया गया है, यही कारण है कि हम फिन-वीआईटी 1 में नहीं हैं)। इसके बजाय, दूसरे छोर पर अभी भी असीमित मात्रा में डेटा भेजने का विकल्प है।
हेगन वॉन एटिजन

जवाबों:


14

यदि कनेक्शन अनाथ है, तो कर्नेल टाइमआउट केवल लागू होता है। यदि कनेक्शन अभी भी एक सॉकेट से जुड़ा हुआ है, तो प्रोग्राम जो उस सॉकेट का मालिक है, कनेक्शन के बंद होने के समय के लिए जिम्मेदार है। संभवत: इसने कॉल किया है shutdownऔर कनेक्शन बंद होने का इंतजार कर रहा है। जब तक शटडाउन पूरा होने के लिए आवेदन पसंद है, तब तक प्रतीक्षा कर सकते हैं।

विशिष्ट स्वच्छ शट डाउन प्रवाह इस प्रकार है:

  1. एप्लिकेशन कनेक्शन को बंद करने का निर्णय लेता है और कनेक्शन के राइट साइड को बंद कर देता है।

  2. आवेदन दूसरी तरफ से अपने आधे कनेक्शन को बंद करने की प्रतीक्षा करता है।

  3. एप्लिकेशन कनेक्शन के दूसरे पक्ष के बंद होने का पता लगाता है और इसके सॉकेट को बंद कर देता है।

जब तक यह पसंद है तब तक एप्लिकेशन चरण 2 पर प्रतीक्षा कर सकता है।

ऐसा लगता है कि एप्लिकेशन को टाइमआउट की आवश्यकता है। एक बार जब यह कनेक्शन बंद करने का निर्णय ले लेता है, तो उसे समय की उचित मात्रा के बाद दूसरी तरफ के लिए बंद करने का इंतजार करना चाहिए।


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

मैं आपके उत्तर को अधिक विस्तार से समझना चाहता हूं। क्या आप बता सकते हैं कि अनाथ कनेक्शन क्या है?
एडम रोमनेक

1
@AdamRomanek एक अनाथ कनेक्शन कोई संबद्ध सॉकेट के साथ एक है, वह है, जिसे केवल कर्नेल द्वारा ही एक्सेस किया जा सकता है और कोई भी प्रक्रिया किसी ऑपरेशन को नहीं कर सकती है।
डेविड श्वार्ट्ज

यह मदद करेगा ... " blog.cloudflare.com/…
जॉन ग्रीन

2

यदि सॉकेट बंद है (), लेकिन अभी बंद नहीं () है, तो सॉकेट फिन_ एडिट 2 स्थिति में रहेगा। और चूंकि एप्लिकेशन अभी भी फ़ाइल डिस्क्रिप्टर का मालिक है, कर्नेल को साफ करने के लिए परेशान नहीं करेगा।


जो पहले से ही स्वीकृत उत्तर में उल्लिखित है।
राल्फफ्राइडल

मैंने विशेष रूप से जोड़ा है कि करीब () नहीं कहा जाता है।
एल। यान
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.