নিবন্ধ ডিরেক্টরি
একটি সকেট পাথের কারণে রক্তক্ষয়ী সংঘর্ষ
গল্পটা এইরকম।
আমার এক বন্ধুর সার্ভার গত মাসে আবার ক্র্যাশ করেছিল।
সে আমার কাছে এসে বলল যে, মনিট (monit) ক্রমাগত এরর দেখাচ্ছিল, বলছিল যে এটি php-fpm সকেট ফাইলটি খুঁজে পাচ্ছে না। এরপর সার্ভিসটি ঘন ঘন রিস্টার্ট হতে শুরু করে এবং লোড অনেক বেড়ে যায়। সার্ভারটি ঠিক করার জন্য তাকে ভোর ৩টায় একটি জরুরি কলে ডাকা হয়েছিল।
আমি তোমাকে আতঙ্কিত না হতে এবং আমাকে মনিটর লগগুলো দেখাতে বলেছিলাম।
যখন আমি এটা দেখলাম, আরে, এটা তো এই ধরনের ভুলত্রুটিতে ভরা ছিল:
ত্রুটি: ইউনিক্স সকেট /run/php/php8.4-fpm.sock সংযোগ ত্রুটি — এই ধরনের কোনো ফাইল বা ডিরেক্টরি নেই ত্রুটি: 'php8.4-fpm' failed protocol test [DEFAULT] at /run/php/php8.4-fpm.sock — Cannot create unix socket for /run/php/php8.4-fpm.sock
আমি তাকে জিজ্ঞেস করলাম, "তোমার সকেট ফাইলটা এখন কোথায়?"
সে বললো সে জানে না, তাই আমি ডিফল্ট সেটিংস দিয়েই ইনস্টল করে দিয়েছি।
আমি তোমাকে অপেক্ষা করতে বলেছিলাম, আমি তোমার জন্য দেখে নিচ্ছি।
তারপর আমি SSH-এর মাধ্যমে লগইন করে দেখলাম যে তার আসল সকেট ফাইলটির নাম ছিল... /run/php/php8.4-fpm-etufo.org.sock.
আমি বললাম, বন্ধু, তোমার সকেট পাথ দুটো ভিন্ন জিনিস, এটা যোগাযোগ করতে পারলে সেটা একটা অলৌকিক ঘটনাই হবে।
আজ আমি এই বিষয়টি ভেঙে বিস্তারিতভাবে ব্যাখ্যা করব এবং সমস্যাটির একটি সমাধানও দেব।
আপনি ভাবেন নজরদারি আপনাকে রক্ষা করছে, কিন্তু আসলে এটি আপনার ক্ষতি করছে।
চলুন মনিট লগ-এ সবচেয়ে সাধারণ ধরনের ত্রুটি নিয়ে আলোচনা দিয়ে শুরু করা যাক।
যখন আপনি এটি দেখবেন:
ত্রুটি: ইউনিক্স সকেট /run/php/php8.4-fpm.sock সংযোগ ত্রুটি — এই ধরনের কোনো ফাইল বা ডিরেক্টরি নেই
এর থেকে বোঝা যায় যে, মনিট এই সকেটের মাধ্যমে php-fpm সার্ভিসটি শনাক্ত করার চেষ্টা করছে, কিন্তু ফাইলটি খুঁজে পাচ্ছে না।
এরপরে যা ঘটবে তা হলো, মনিট সার্ভিসটি পুনরায় চালু করার চেষ্টা করবে এবং লগগুলিতে দেখা যাবে:
তথ্য: 'php8.4-fpm' পুনরায় চালু করার চেষ্টা করা হচ্ছে তথ্য: 'php8.4-fpm' বন্ধ: '/usr/sbin/service php8.4-fpm stop' তথ্য: 'php8.4-fpm' চালু: '/usr/sbin/service php8.4-fpm start'
দেখতে বেশ স্মার্ট, তাই না? এটা নিজে থেকেই মেরামত হয়ে যায়।
কিন্তু সমস্যাটা হলো, এই ঘন ঘন রিস্টার্ট করাই আসল বিপর্যয়।
এটা কল্পনা করুন: যখন php-fpm রিস্টার্ট হয়, তখন চলমান সমস্ত রিকোয়েস্ট বাধাগ্রস্ত হয়, সমস্ত সেশন নষ্ট হয়ে যেতে পারে এবং সমস্ত কানেকশন পুনরায় স্থাপন করার প্রয়োজন হয়। যদি এটি অল্প সময়ের মধ্যে বারবার রিস্টার্ট হয় এবং ব্যর্থ হয়, তাহলে সার্ভারের লোড তাৎক্ষণিকভাবে অনেক বেড়ে যাবে।
লগগুলো থেকে আরও তথ্য প্রকাশ পাবে, যেমন:
ত্রুটি: 'etUfo.org-এর লোডঅ্যাভারেজ (১৫ মিনিট) ৮.৮ রিসোর্স লিমিটের সাথে মিলে গেছে [লোডঅ্যাভারেজ (১৫ মিনিট) > ৮.০] ত্রুটি: 'etUfo.org-এর সিপিইউ সিস্টেম ব্যবহার ৩৩.৯% রিসোর্স সীমার সাথে মিলে যাচ্ছে [সিপিইউ সিস্টেম ব্যবহার > ৩০.০%]
সার্ভারটি ইতিমধ্যেই প্রচণ্ড চাপে ছিল, কিন্তু মনিটরিং সিস্টেমটি তারপরও বারবার সার্ভিসটি রিস্টার্ট করছিল। এতে আগুন নেভানোর বদলে আগুনে ঘি ঢালা হচ্ছিল।
সমস্যার মূল কারণ হলো: চাবি এবং তালা মিলছে না।
আরও ভালোভাবে বিশ্লেষণ করলে দেখা যায়, সমস্যাটি আসলে বেশ সহজ।
মনিট কনফিগারেশন ফাইলে নির্দিষ্ট করা সকেট পাথটি হলো:/run/php/php8.4-fpm.sock
তবে, php-fpm যে প্রকৃত সকেট পাথে চলে তা হলো:/run/php/php8.4-fpm-etufo.org.sock
যদি একটি ফাংশনের উদ্দেশ্য ফাইল A শনাক্ত করা হয়, কিন্তু অন্যটি আসলে ফাইল B হয়, তাহলে শনাক্তকরণটি স্বাভাবিকভাবেই ব্যর্থ হবে।
এটা অনেকটা কোনো একটা কিছুর মতো।
আপনার কাছে একটি চাবি আছে, যা অন্য ঘরে তালাবদ্ধ অবস্থায় রয়েছে।
আপনি প্রতিদিন আপনার চাবি দিয়ে দরজা খোলার চেষ্টা করেন, কিন্তু প্রতিবারই দেখেন দরজাটা খুলছে না, আর তখন বলেন যে তালাটা নষ্ট হয়ে গেছে।
আসলে, তালাটা ভাঙা নয়; শুধু আপনার চাবিটা তালার সাথে মিলছে না।
সমাধানমনিটরিংPHP-FPM এর সাথে অসামঞ্জস্যপূর্ণ কনফিগারেশন
বিকল্প ১: মনিট কনফিগারেশন পরিবর্তন করুন।
যদি আপনি php-fpm-এর বিদ্যমান সকেট কনফিগারেশনটি রাখতে চান, তাহলে মনিট কনফিগারেশনটি পরিবর্তন করুন।
মনিট কনফিগারেশন ফাইলটি খুঁজুন এবং নিম্নলিখিতগুলি পরিবর্তন করুন:
if failed unixsocket /run/php/php8.4-fpm.sock then restart
এটিতে পরিবর্তন করুন:
if failed unixsocket /run/php/php8.4-fpm-chenweiliang.com.sock then restart
তারপর রিলোড করুন:
sudo monit reload
এই তো।
বিকল্প ২: php-fpm কনফিগারেশন পরিবর্তন করুন।
যদি আপনি ডিফল্ট পাথ ব্যবহার করতে চান, তাহলে php-fpm-এর পুল কনফিগারেশন পরিবর্তন করুন।
编辑 /etc/php/8.4/fpm/pool.d/chenweiliang.com.conflisten কমান্ডটি পরিবর্তন করে এটি করুন:
listen = /run/php/php8.4-fpm.sock
তারপর php-fpm পুনরায় চালু করুন:
sudo systemctl restart php8.4-fpm
এই তো।
উভয় সমাধানই সমস্যাটি সমাধান করতে পারে; আপনি কোনটি বেছে নেবেন তা আপনার নির্দিষ্ট পরিস্থিতির উপর নির্ভর করে।
আপনার সার্ভারে কয়টি সাইট হোস্ট করা আছে? প্রতিটি সাইটের কি আলাদা সকেট আছে? যদি একটিমাত্র সাইট থাকে, তাহলে ডিফল্ট পাথটি আরও সহজ হবে।
আমি মন থেকে কথা বলি।
আমি আন্তরিকভাবে বিশ্বাস করি যে, রক্ষণাবেক্ষণের সময় এই ধরনের কনফিগারেশন সমস্যাগুলোই সবচেয়ে সহজে উপেক্ষিত হয়, অথচ সার্ভারের স্থিতিশীলতার উপর এগুলোর প্রভাবই সবচেয়ে বেশি।
যদি কোনো সকেট পাথ ভুলভাবে লেখা হয়, তাহলে আপাতদৃষ্টিতে পরিস্থিতি শান্ত মনে হতে পারে, কিন্তু বাস্তবে মনিটরিং সিস্টেম ক্রমাগত ভুল অ্যালার্ম দিতে থাকে, সার্ভিসটি এলোমেলোভাবে রিস্টার্ট হতে থাকে এবং লোড ব্যাখ্যাতীতভাবে বেড়ে যায়।
আপনার মনে হতে পারে সার্ভারটি অনেক পুরোনো এবং আপগ্রেড করা প্রয়োজন, কিন্তু আসল কারণ হতে পারে যে কনফিগারেশন ফাইলের পাথটি ভুল।
যেমনটি আমার এক ঊর্ধ্বতন সহকর্মী একবার বলেছিলেন, "পরিষেবার স্থিতিশীলতা নিশ্চিত করার জন্য পর্যবেক্ষণের নির্ভুলতাই হলো প্রথম প্রতিরক্ষা ব্যবস্থা।"
খুঁটিনাটি বিষয়ই সাফল্য বা ব্যর্থতা নির্ধারণ করে, এবং সার্ভার পরিবেশে এটি সম্পূর্ণ সত্য।
আজ থেকে আপনার মনিটরিং কনফিগারেশন পরীক্ষা করুন। এই আপাতদৃষ্টিতে সাধারণ সমস্যাটির কারণে যেন আপনার সার্ভার ক্র্যাশ না করে।
আমার লেখাটি পড়ার জন্য ধন্যবাদ। আবার দেখা হবে।
হোপ চেন উইলিয়াং ব্লগ ( https://www.chenweiliang.com/ এখানে শেয়ার করা "Solving the 'No such file or directory' in Monit monitoring configuration and PHP-FPM" আর্টিকেলটি আপনার জন্য সহায়ক হতে পারে।
এই নিবন্ধটির লিঙ্ক শেয়ার করতে স্বাগতম:https://www.chenweiliang.com/cwl-34000.html