FIN_WAIT2 রাজ্যে সংযোগগুলি লিনাক্স কার্নেল দ্বারা বন্ধ করা হয়নি কেন?


11

আমি একটি দীর্ঘস্থায়ী প্রক্রিয়া নামক একটি সমস্যা আছে kube-প্রক্সি হচ্ছে অংশ Kubernetes

সমস্যাটি হ'ল সময়ে সময়ে সংযোগটি 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

এই সংযোগগুলি প্রক্রিয়াটিকে দুর্ব্যবহার করে সময়ের সাথে সাথে স্ট্যাক আপ করে। আমি ইতিমধ্যে কুবেরনেটস বাগ-ট্র্যাকারকে একটি সমস্যা রিপোর্ট করেছি তবে আমি বুঝতে চাই যে লিনাক্স কার্নেল দ্বারা কেন এই জাতীয় সংযোগগুলি বন্ধ করা হয় না।

এর ডকুমেন্টেশন অনুসারে (টিসিপি_ফিন_টাইমআউট অনুসন্ধান করুন) FIN_WAIT2 রাজ্যের সংযোগটি X সেকেন্ডের পরে কার্নেল দ্বারা বন্ধ করা উচিত, যেখানে X / proc থেকে পড়া যায়। আমার মেশিনে এটি 60 এ সেট করা আছে:

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

সুতরাং যদি আমি এটি সঠিকভাবে বুঝতে পারি তবে এই জাতীয় সংযোগগুলি 60 সেকেন্ডের মধ্যে বন্ধ করা উচিত। তবে এই ঘটনাটি নয়, তারা এমন অবস্থায় কয়েক ঘন্টা রেখে যায়।

যদিও আমি আরও বুঝতে পেরেছি যে FIN_WAIT2 সংযোগগুলি বেশ অস্বাভাবিক (এর অর্থ হোস্ট সংযোগের দূরবর্তী প্রান্ত থেকে ইতিমধ্যে চলে গেছে এমন কিছু এসকে-র জন্য অপেক্ষা করছে) কেন সিস্টেমগুলি এই সংযোগগুলি "বন্ধ" না করে আমি পাই না I ।

এটি সম্পর্কে আমি কি কিছু করতে পারি?

নোট করুন যে সম্পর্কিত প্রক্রিয়া পুনরায় আরম্ভ করা একটি শেষ অবলম্বন।


1
যাইহোক, FIN-WAIT2 এ, সংযোগটি কোনও এসকে-র জন্য অপেক্ষা করছে না (এটি প্রেরিত এফআইএন ইতিমধ্যে স্বীকৃত হয়েছে, যার কারণেই আমরা ফিন-ওয়েট 1 এ নেই)। পরিবর্তে, অন্য প্রান্তে এখনও সীমাহীন পরিমাণে ডেটা প্রেরণের বিকল্প রয়েছে।
হেগেন ভন ইটজেন

উত্তর:


14

সংযোগটি অনাথ হলেই কার্নেলের সময়সীমাটি প্রযোজ্য। যদি সংযোগটি এখনও সকেটের সাথে সংযুক্ত থাকে, তবে সেই সকেটের মালিকানাধীন প্রোগ্রামটি সংযোগ বন্ধের সময় নির্ধারণের জন্য দায়ী। সম্ভবত এটি কল করেছে shutdownএবং সংযোগটি পরিষ্কারভাবে বন্ধ হয়ে যাওয়ার জন্য অপেক্ষা করছে। অ্যাপ্লিকেশনটি শাটডাউনটি সম্পূর্ণ হওয়ার জন্য যতক্ষণ এটি পছন্দ করতে পারে ততক্ষণ অপেক্ষা করতে পারে।

সাধারণ পরিষ্কার শাটডাউন প্রবাহটি এরকম হয়:

  1. অ্যাপ্লিকেশনটি সংযোগটি বন্ধ করার সিদ্ধান্ত নেয় এবং সংযোগের লেখার দিকটি বন্ধ করে দেয়।

  2. অ্যাপ্লিকেশনটি অপর পক্ষের সংযোগের অর্ধেক অংশ বন্ধ করার জন্য অপেক্ষা করে।

  3. অ্যাপ্লিকেশনটি অন্য পক্ষের সংযোগটি বন্ধ করে সনাক্ত করে এবং তার সকেটটি বন্ধ করে দেয়।

অ্যাপ্লিকেশনটি যতক্ষণ পছন্দ করবে ততক্ষণ 2 ধাপে অপেক্ষা করতে পারে।

দেখে মনে হচ্ছে অ্যাপ্লিকেশনটির একটি সময়সীমা দরকার। একবার সংযোগ বন্ধ করার সিদ্ধান্ত নেওয়ার পরে, কিছুটা যুক্তিসঙ্গত সময়ের পরে অন্য পক্ষটি একটি ক্লিন শাটডাউন করার অপেক্ষায় ছেড়ে দেওয়া উচিত।


আমি এই তথ্যটি কুবারনেটস বিকাশকারীদের সাথে পরীক্ষা করে দেখব যে এই জাতীয় সময়সীমা বাস্তবায়ন হয়েছে কিনা। আমি উত্তরটি যাচাই করার পরে আমি তা গ্রহণ করব accept তবুও দ্রুত প্রতিক্রিয়া জন্য ধন্যবাদ।
অ্যাডাম রোমানেক

আমি আপনার উত্তরটি আরও বিস্তারিতভাবে বুঝতে চাই। আপনি কি দয়া করে এতিম সংযোগটি ব্যাখ্যা করতে পারেন?
অ্যাডাম রোমানেক

1
@ অ্যাডামরমনেক একটি এতিম সংযোগটি কোনও সম্পর্কিত সকেটগুলির সাথে একটি, এটি কেবল কার্নেল দ্বারা অ্যাক্সেস করতে পারে এবং কোনও প্রক্রিয়া অপারেশন করতে পারে না।
ডেভিড শোয়ার্টজ

এটি সাহায্য করবে ... " ব্লগ.ক্লাউডফ্লেয়ার.com
জন গ্রিন

2

যদি সকেটটি বন্ধ হয়ে থাকে () তবে এখনও বন্ধ হয় না) তবে সকেটটি FIN_WAIT2 অবস্থায় থাকবে। এবং যেহেতু অ্যাপ্লিকেশনটি এখনও ফাইল বর্ণনাকারীর মালিক, কার্নেলটি পরিষ্কার করতে বিরত করবে না।


এটি ইতিমধ্যে গৃহীত উত্তরে উল্লেখ করা হয়েছে।
র‌্যালফ্রেডল

আমি বিশেষভাবে যোগ করেছি যে বন্ধ () বলা হয় না।
এল। ইয়ান
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.