আমি একটি ছোট প্রোগ্রাম লিখেছি যা একটি নির্দিষ্ট পোর্টের একটি সার্ভারের সাথে যোগাযোগ করে। প্রোগ্রামটি দুর্দান্ত কাজ করে তবে:
প্রোগ্রামটি অপ্রত্যাশিতভাবে শেষ হয়ে গেলে এবং সেই থেকে সকেট সংযোগটি CLOSE_WAITরাজ্যে দেখানো হয় । যদি আমি কোনও প্রোগ্রাম চালানোর চেষ্টা করি তবে এটি স্তব্ধ হয়ে যায় এবং আমাকে এটিকে বাধ্য করতে হয়, যা আরও বেশি CLOSE_WAIT সকেট সংযোগ জমে ।
এই সংযোগগুলি ফ্লাশ করার কোনও উপায় আছে?
উত্তর:
CLOSE_WAITমানে আপনার প্রোগ্রামটি এখনও চলছে, এবং সকেটটি বন্ধ করেনি (এবং কার্নেল এটি করার জন্য অপেক্ষা করছে)। যোগ -pকরার জন্য netstatPID পেতে, এবং তারপর এটি হত্যা আরও জোর (সঙ্গে SIGKILLপ্রয়োজন হলে)। এটি আপনার CLOSE_WAITসকেট পরিত্রাণ পেতে হবে । আপনি ব্যবহার করতে পারেনps পিডটি সন্ধান করতে ।
SO_REUSEADDRসার্ভার এবং TIME_WAITসকেটের জন্য তাই এখানে প্রয়োগ করা হয় না।
যেমনটি ক্রিস্ট ক্লার্ক বর্ণনা করেছেন ।
CLOSE_WAIT এর অর্থ হল যে সংযোগের স্থানীয় প্রান্তটি অন্য প্রান্ত থেকে একটি এফআইএন পেয়েছে, তবে ওএস স্থানীয় প্রান্তে প্রোগ্রামটির জন্য অপেক্ষা করছে যে এটি সংযোগটি বন্ধ করে দেবে।
সমস্যাটি হ'ল লোকাল মেশিনে আপনার প্রোগ্রামটি সকেটটি বন্ধ করছে না। এটি কোনও টিসিপি টিউনিংয়ের সমস্যা নয়। প্রোগ্রামটি সংযোগটি উন্মুক্ত রাখার সময় একটি সংযোগ (এবং বেশ সঠিকভাবে) চিরতরে CLOSE_WAIT এ থাকতে পারে।
একবার স্থানীয় প্রোগ্রাম সকেটটি বন্ধ করে দিলে, ওএস FIN প্রেরণ করতে পারে রিমোট প্রান্তে যা আপনাকে LAST_ACK এ রূপান্তর করে যখন আপনি FIN এর ACK এর জন্য অপেক্ষা করেন। এটি পাওয়ার পরে, সংযোগটি শেষ হয়ে যায় এবং সংযোগ টেবিল থেকে নেমে আসে (যদি আপনার শেষটি CLOSE_WAIT হয় তবে আপনি TIME_WAIT অবস্থায় শেষ করবেন না )।
close()বা closesocket()ব্যবহার করুন।
আমি খুব সাম্প্রতিক টমক্যাট সার্ভার (7.0.40) এর সাথেও একই সমস্যাটি পেয়েছি। এটি কয়েক দিনের জন্য একবার অ-প্রতিক্রিয়াশীল হয়ে যায়।
উন্মুক্ত সংযোগগুলি দেখতে, আপনি ব্যবহার করতে পারেন:
sudo netstat -tonp | grep jsvc | grep --regexp="127.0.0.1:443" --regexp="127.0.0.1:80" | grep CLOSE_WAIT
এই পোস্টে উল্লিখিত হিসাবে , আপনি /proc/sys/net/ipv4/tcp_keepalive_timeমান দেখতে ব্যবহার করতে পারেন । মানটি সেকেন্ডে বলে মনে হচ্ছে এবং এটি ডিফল্ট 72২০০ (অর্থাত্ ২ ঘন্টা)।
এগুলি পরিবর্তন করতে, আপনাকে সম্পাদনা করতে হবে /etc/sysctl.conf।
Open/create `/etc/sysctl.conf`
Add `net.ipv4.tcp_keepalive_time = 120` and save the file
Invoke `sysctl -p /etc/sysctl.conf`
Verify using `cat /proc/sys/net/ipv4/tcp_keepalive_time`
যদিও খুব বেশি CLOSE_WAIT সংযোগগুলির অর্থ প্রথমটিতে আপনার কোডে কিছু ভুল আছে এবং এটি ভাল অনুশীলন হিসাবে গ্রহণযোগ্য নয়।
আপনি চেক আউট করতে পারেন: https://github.com/rghose/kill-close-wait- সংযোগগুলি
এই স্ক্রিপ্টটি যা করে তা হ'ল এসিকে পাঠানো যা সংযোগটির জন্য অপেক্ষা করছিল।
এটিই আমার পক্ষে কাজ করেছিল।
এটি উল্লেখ করা উচিত যে Socketক্লায়েন্ট এবং সার্ভার উভয় ক্ষেত্রে উদাহরণটি স্পষ্টভাবে প্রার্থনা করা প্রয়োজন close()। close()এরপরে যদি কেবলমাত্র একটিরও অনুরোধ থাকে তবে সকেটটি CLOSE_WAIT অবস্থায় থাকবে।
আপনি জোর করে ssকমান্ড দিয়ে সকেট বন্ধ করতে পারেন ; দ্যssকমান্ড netstat কমান্ড থেকে সকেট পরিসংখ্যান এবং তথ্য প্রদর্শন অনুরূপ ফ্যাশন (সহজ যদিও এবং দ্রুত) ডাম্প করার জন্য ব্যবহৃত একটি টুল।
CLOSE_WAIT রাজ্যে যে কোনও সকেট মারতে, এটি চালান (মূল হিসাবে)
$ ss --tcp state CLOSE-WAIT --kill
এটিও লক্ষণীয় যে আপনার প্রোগ্রামটি যদি একটি নতুন প্রক্রিয়া তৈরি করে তবে সেই প্রক্রিয়াটি আপনার সমস্ত খোলার হ্যান্ডেলগুলির উত্তরাধিকারী হতে পারে। এমনকি আপনার নিজের প্রোগ্রাম বন্ধ হয়ে যাওয়ার পরেও, উত্তরাধিকারসূত্রে প্রাপ্ত হ্যান্ডলগুলি এখনও এতিম শিশু প্রক্রিয়াটির মাধ্যমে জীবিত থাকতে পারে। এবং তারা অগত্যা নেটস্ট্যাট মধ্যে একই একই প্রদর্শিত হবে না। তবে সর্বোপরি, এই শিশু প্রক্রিয়াটি জীবিত থাকাকালীন সকেটটি CLOSE_WAIT- এ ঝুলবে।
আমার একটি মামলা ছিল যেখানে আমি এডিবি চালাচ্ছিলাম। এডিবি নিজেই একটি সার্ভার প্রক্রিয়া তৈরি করে যদি এটি ইতিমধ্যে চালু না থাকে। এটি প্রাথমিকভাবে আমার সমস্ত হ্যান্ডলগুলি উত্তরাধিকার সূত্রে পেয়েছে, তবে আমি তদন্ত করার সময় এগুলির কোনওটির মালিক হিসাবে দেখানো হয়নি (লিনাক্স সম্পর্কে নিশ্চিত নয়) ম্যাকোস এবং উইন্ডোজ উভয়ের ক্ষেত্রে একই ছিল)।