HestiaCP کے ساتھ Apache2 کے بار بار کریش؟ خودکار مانیٹرنگ اور ٹربل شوٹنگ گائیڈ کی نگرانی کریں (مکمل ترتیب کے ساتھ)

HestiaCP ماحول میں بار بار Apache2 کریشز یا خود کار طریقے سے دوبارہ شروع ہونے کی ناکامیوں پر نظر رکھیں؟ یہ مضمون مونٹ کے ساتھ Apache2 کی نگرانی کرتے وقت عام خرابیوں سے بچنے کے لیے ایک عملی گائیڈ فراہم کرتا ہے، عام مسائل کا گہرائی سے تجزیہ کرتا ہے جیسے کہ PID پاتھ کی غلط ترتیب اور اجازت بلاک کرنا، اور پروڈکشن گریڈ مانٹ آٹومیشن کنفیگریشن فائلوں کی پیشکش۔ اعلی دستیابی سرور کی دیکھ بھال کی تکنیکوں میں مہارت حاصل کریں اور ناکامیوں سے دوسرے درجے کی خودکار بحالی حاصل کریں!

Apache2 کی نگرانی کے لیے Monit کا استعمال کرتے ہوئے مجھے جن خرابیوں کا سامنا کرنا پڑا

پچھلے جمعہ کو، سرور نے مجھے رات کے وسط میں ایک مانیٹ الرٹ دیا۔

میں نے چونک کر پینل کی طرف دیکھا، اور apache2 اسٹیٹس کالم میں، ایک سرخ ٹائم آؤٹ تھا۔

میں نے اس کے بارے میں تھوڑی دیر سوچا۔ میں نے صرف دن کے وقت سرور میں Monit مانیٹرنگ شامل کی، اور میں نے ایک آن لائن ٹیوٹوریل سے کنفیگریشن کو کاپی اور پیسٹ کیا۔ کوئی مسئلہ نہیں ہونا چاہئے، ٹھیک ہے؟

اگلی صبح، اس کا دوبارہ وقت ختم ہوگیا۔ تیسری بار کے بعد، مانیٹر نے بس چھوڑ دیا، اور پینل نے "مانیٹر نہیں کیا" دکھایا۔

میں...

میں تسلیم کرتا ہوں، میں نے پہلے اسے سنجیدگی سے نہیں لیا۔ Apache2 نگرانی؟ آپ بہت ساری ٹیمپلیٹ کنفیگریشنز آن لائن تلاش کر سکتے ہیں، بس کاپی اور پیسٹ کریں۔ لیکن چسپاں کرنے کے اس عمل نے مجھے واقعی غصے میں ڈال دیا۔

HestiaCP کے پہلے سے طے شدہ فن تعمیر اور Monit بندرگاہوں کے درمیان تنازعہ کی بنیادی وجہ

آئیے پہلے میں آپ کو وہ کنفیگریشن دکھاتا ہوں جس کی وجہ سے مجھے بہت پریشانی ہوئی، تاکہ آپ دیکھ سکیں کہ آیا یہ بالکل ویسا ہی ہے جیسا کہ آپ نے دیکھا ہے۔

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/usr/sbin/service apache2 start"
    stop program  = "/usr/sbin/service apache2 stop"
    if failed host 127.0.0.1 port 80 protocol http then restart
    if 5 restarts within 5 cycles then timeout

یہ ٹھیک لگتا ہے، ٹھیک ہے؟ یہ پورٹ 80 کو چیک کرتا ہے، اور اگر یہ کریش ہو جاتا ہے، تو یہ دوبارہ شروع ہو جاتا ہے۔ اگر یہ 5 دوبارہ شروع ہونے کے بعد بھی کریش ہو جاتا ہے تو اس کا وقت ختم ہو جاتا ہے۔

مسئلہ یہ ہے کہ آپ کا Apache2 پورٹ 80 پر بھی نہیں چل رہا ہے۔

یہ HestiaCP کا ایک نقصان ہے، اور بہت سے لوگوں کے اس میں گرنے کی بنیادی وجہ ہے۔ HestiaCP کا ڈیفالٹ فن تعمیر Nginx + Apache2 کا ایک ریورس پراکسی ہے، جس کے سامنے Nginx پورٹ 80 اور 443 پر قابض ہے، اور Apache2 مقامی پورٹ 8081 پر پیچھے چل رہا ہے۔

اگر آپ Monit سے پورٹ 80 پر Apache2 کی زندگی کی تحقیقات کرنے کو کہتے ہیں، تو یہ KFC تلاش کرنے کے لیے میکڈونلڈز جانے جیسا ہے۔ سرور آپ کو خالی نظروں سے دیکھتا ہے، اور آپ دونوں ایک دوسرے کو گھور رہے ہیں۔ آخر میں، مانیٹ اس بات کا تعین کرتا ہے کہ آپ نیچے ہیں اور پاگل پن سے دوبارہ شروع کرنا شروع کر دیتے ہیں۔

دوبارہ شروع کرنے کے بعد، پورٹ اب بھی 8081 ہے۔ Monit پھر پورٹ 80 کی تحقیقات کرنے کی کوشش کرتا ہے، جو بھی ناکام ہو جاتا ہے، لہذا یہ دوبارہ شروع ہو جاتا ہے۔ یہ سائیکل اس وقت تک دہرایا جاتا ہے جب تک کہ مانیٹ یہ فیصلہ نہیں کرتا کہ یہ مرمت اور وقت ختم ہونے سے باہر ہے۔

جب میں نے پہلی بار اس کا سامنا کیا تو میں واقعی دنگ رہ گیا۔ دس میں سے نو ٹیوٹوریلز مجھے آن لائن استعمال شدہ پورٹ 80 ملے۔ اگر آپ ان پر عمل کرتے ہیں تو مسئلہ آپ کے ساتھ نہیں تھا بلکہ خود معلومات کے ماخذ کا تھا۔

خراب شدہ Apache2 PID فائل کی وجہ سے Monit نے غلطی سے اس عمل کو غیر موجود کے طور پر شناخت کیا۔

بندرگاہ کو 80 سے 8081 تک تبدیل کرنے کے بعد، مانیٹ کو نظریاتی طور پر اس کا پتہ لگانے کے قابل ہونا چاہیے، ٹھیک ہے؟

تاہم، حقیقت میں، یہ اب بھی کبھی کبھار "پھانسی ناکام " کی اطلاع دیتا ہے۔

ایک طویل عرصے تک جدوجہد کرنے کے بعد، میں نے آخر کار دریافت کیا کہ اس کی وجہ بہت سادہ تھی: PID فائل خراب ہو گئی تھی۔

اس کے بارے میں سوچیں، مونیٹ بے دلی سے اپاچی 2 کو دوبارہ شروع کر رہا تھا، ہر بار اسے زبردستی مار کر دوبارہ شروع کر رہا تھا، کئی بار آگے پیچھے جا رہا تھا۔ اس عمل کے دوران، فائل /var/run/apache2/apache2.pid 0 بائٹس بن سکتی ہے۔

دوسرے الفاظ میں، فائل اب بھی موجود ہے، لیکن یہ خالی ہے۔

جب مونیٹ اس فائل کو پڑھتا ہے تو اسے کچھ نہیں ملتا۔ یہ آپ کے Apache2 کو نہیں پہچانتا، چاہے آپ کا Apache2 پس منظر میں بالکل ٹھیک چل رہا ہو۔ مانیٹ کے خیال میں عمل موجود نہیں ہے۔

یہ دیکھ کر میں ایک لمحے کے لیے بے آواز ہو گیا۔

یہ تعطل ہے۔ Monit Apache 2 مثال کا پتہ لگانے میں ناکام ہوجاتا ہے، Apache2 کو دوبارہ شروع کرتا ہے، دوبارہ شروع کرنے کے عمل کے دوران PID فائل کو خراب کرتا ہے، اگلی شناخت میں ناکام ہوجاتا ہے، اور دوبارہ شروع ہوجاتا ہے۔ وقت ختم ہونے تک یہ سلسلہ جاری رہتا ہے۔

HestiaCP ماحول میں Apache2 مانیٹرنگ کے لیے خرابیوں کا سراغ لگانا اور مرمت کے اقدامات

سچ پوچھیں تو، تفتیش کا عمل پیچیدہ نہیں ہے، لیکن آپ کو یہ جاننے کی ضرورت ہے کہ تفتیش کس سمت کی جائے۔

پہلا قدم یہ طے کرنا ہے کہ آپ کا Apache2 کس پورٹ پر سن رہا ہے۔ ٹرمینل میں بس ایک کمانڈ ٹائپ کریں۔

netstat -tulpn | grep apache2

متبادل طور پر، آپ `ss` کمانڈ استعمال کر سکتے ہیں۔ اثر ایک ہی ہے.

ss -tulpn | grep apache2

آپ کو اس سے ملتا جلتا آؤٹ پٹ نظر آئے گا۔

tcp  0  0 127.0.0.1:8081       0.0.0.0:*  LISTEN  2942372/apache2

اس کے 8081 ہونے کی تصدیق ہوئی ہے، 80 نہیں۔ یہی مسئلہ کی جڑ ہے۔

دوسرا مرحلہ خراب شدہ PID فائل کو ٹھیک کرنا ہے۔ یہ آسان ہے۔

monit unmonitor apache2
systemctl restart apache2
cat /var/run/apache2/apache2.pid

سب سے پہلے، مانیٹ مانیٹرنگ کو موقوف کریں تاکہ آپ چیزوں کو ٹھیک کرتے وقت اسے مداخلت کرنے سے روکیں۔ پھر، Apache2 کو دوبارہ شروع کریں تاکہ اسے صاف پی آئی ڈی کو دوبارہ لکھنے کی اجازت دی جائے۔ آخر میں، فائل کا مواد چیک کرنے کے لیے `بلی` کا استعمال کریں۔ اس میں نمبروں کی سٹرنگ ہونی چاہیے، خالی سٹرنگ نہیں۔

ایک بار جب یہ مرحلہ مکمل ہوجاتا ہے، تو مسئلہ بنیادی طور پر حل ہوجاتا ہے۔

مانیٹ روایتی انکولی اور جارحانہ حفاظتی ترتیب کا تقابلی تجزیہ

Apache2 کو Monit کے ساتھ ترتیب دینے کے آن لائن سبق عام طور پر دو زمروں میں آتے ہیں۔

ایک قسم "روایتی موافقت کی قسم" ہے جو بہت زیادہ پیچیدہ پابندیوں کو شامل کیے بغیر خدمات کو منظم کرنے اور مقامی بندرگاہوں کو چیک کرنے کے لیے `service` کمانڈ استعمال کرتی ہے۔ اس کنفیگریشن کو HestiaCP پر صرف پورٹ کو تبدیل کر کے استعمال کیا جا سکتا ہے، اور یہ نسبتاً مستحکم ہے۔

ایک اور نقطہ نظر "جارحانہ تحفظ" کا طریقہ ہے، جو خدمات کو منظم کرنے کے لیے systemctl کا استعمال کرتا ہے، بچوں کے عمل کی پابندیوں کو شامل کرتا ہے، اور پتہ لگانے کی سخت منطق کو استعمال کرتا ہے۔ یہ بہت اچھا لگتا ہے، لیکن اس میں ایک مہلک خامی ہے: سٹاپ کمانڈ کا استعمال کیا گیا ہے `killall-9`۔

'قتل -9' کا کیا مطلب ہے؟ اس کا مطلب ہے آلہ کو زبردستی مار ڈالنا چاہے وہ کچھ بھی کر رہا ہو۔ یہ بریٹ فورس آپریشن آسانی سے خراب PID فائلوں کو پیچھے چھوڑ سکتا ہے، جس کا میں نے ابھی ذکر کیا ہے۔

میرا ذاتی تجربہ یہ ہے کہ ایک جارحانہ ترتیب میں بچوں کے عمل کی تعداد کو محدود کرنا واقعی مفید ہے۔ جب آپ کا Apache2 CC حملے سے مغلوب ہو جاتا ہے، تو چائلڈ پروسیس کی تعداد کو محدود کرنا سرور کو میموری ختم ہونے سے روک سکتا ہے۔ تاہم، 'killall -9' نقطہ نظر واقعی ناقابل استعمال ہے۔

تو آخر میں میں نے سمجھوتہ کیا اور دونوں کنفیگریشنز کے فوائد کو یکجا کیا۔

HestiaCP Apache2 مانیٹ بہترین پریکٹس کنفیگریشن

درج ذیل مواد کے ساتھ فائل /etc/monit/conf.d/apache2 میں ترمیم کریں۔

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/bin/systemctl start apache2"
    stop program  = "/bin/systemctl stop apache2"
    if children > 120 for 2 cycles then restart
    if failed host 127.0.0.1 port 8081 protocol http for 2 cycles then restart
    if 5 restarts within 10 cycles then timeout

میں ان چند سطروں کی ترتیب کے پیچھے کی منطق کو مختصراً بیان کرتا ہوں۔

HestiaCP کے ریورس پراکسی فن تعمیر سے قطعی طور پر مماثل ہونے کے لیے پورٹ 8081 لکھیں۔ بے وقوفانہ طور پر پورٹ 80 لکھنا بند کریں۔

PID فائل کو روکنے کے لیے 'killall-9' کے بجائے 'systemctl stop' کمانڈ استعمال کریں، تاکہ اسے خراب نہ کریں۔

چائلڈ پروسیس کی ایک حد شامل کی گئی ہے: اگر بچوں کی تعداد 120 سے تجاوز کر جاتی ہے، تو یہ عمل CC حملوں کو روکنے کے لیے لگاتار دو چکروں کے بعد دوبارہ شروع ہو جائے گا، لیکن یہ زیادہ جارحانہ نہیں ہے۔

ناکامیوں کا پتہ لگانے کے لیے منطق کو "2 سائیکلوں کے لیے" کے نقطہ نظر کو استعمال کرنے کے لیے تبدیل کیا گیا ہے، یعنی دوبارہ شروع کرنا صرف دو مسلسل ناکامیوں کے بعد شروع ہوتا ہے، جس سے غلط مثبت کو کم کیا جاتا ہے۔ پچھلی ترتیب، جو صرف ایک پتہ لگانے کے بعد دوبارہ شروع ہوئی، واضح طور پر قدرے زیادہ حساس تھی۔

فائنل ٹائم آؤٹ تھریشولڈ کو 10 سائیکلوں کے اندر 5 دوبارہ شروع کرنے کے لیے نرم کر دیا گیا ہے، جس سے کافی فالٹ ٹولرنس باقی رہ جاتی ہے۔

ہیسٹیا سی پی نگرانی کی نگرانیکنفیگریشن ٹربل شوٹنگ کا خلاصہ اور تجربہ شیئرنگ

ترتیب میں تبدیلیاں کرنے کے بعد، میں نے apache2 کی نگرانی کی، اور پینل نے آخر کار سبز "OK" اشارے دکھایا۔

اس وقت اپنے جذبات کو کیسے بیان کروں؟ یہ ایسا ہی تھا جیسے دو دن بگ کے ساتھ جدوجہد کرتے ہوئے گزارے، صرف اس کی وجہ معلوم کرنے کے لیے کنفیگریشن کی ایک لائن تھی جو غلط تھی۔ یہ مایوس کن اور ہنسنے والا دونوں تھا۔

Monit اپنے آپ میں ایک اچھی چیز ہے، اور ڈیمن کی نگرانی کرنا ہر سرور کو کرنا چاہیے۔ لیکن مسئلہ یہ ہے کہ بہت سے آن لائن ٹیوٹوریلز اس مفروضے پر مبنی ہیں کہ "Apache2 خصوصی طور پر پورٹ 80 استعمال کرتا ہے،" جبکہ HestiaCP ایک ریورس پراکسی استعمال کرتا ہے، جس کا مطلب ہے کہ یہ مفروضہ درست نہیں ہے۔

اگر آپ ہدایات پر عمل کرتے ہیں، تو مسئلہ آپ کا نہیں ہے۔ یہ ہے کہ ٹیوٹوریل آپ کے مقابلے میں ایک مختلف منظر نامے پر لاگو ہوتا ہے۔

اس لیے اگر آپ HestiaCP بھی استعمال کر رہے ہیں اور Apache2 کی نگرانی کے لیے Monit کے ساتھ گڑبڑ کر رہے ہیں، تو صرف دو چیزیں یاد رکھیں: پورٹ کو 8081 میں تبدیل کریں، اور اسے روکنے کے لیے 'systemctl' کمانڈ استعمال کریں، نہ کہ 'killall-9'۔ اگر آپ یہ دو چیزیں کرتے ہیں، تو آپ کو مزید پریشانیوں سے بچنے کے قابل ہونا چاہئے۔

چونکہ آپ نے ابھی تک یہ پڑھا ہے، اگر آپ کو یہ مفید لگا، تو براہ کرم اسے لائک اور شیئر کریں۔ اگر آپ پہلے اپ ڈیٹس حاصل کرنا چاہتے ہیں، تو آپ مجھے بھی فالو کر سکتے ہیں!

میرا مضمون پڑھنے کے لیے آپ کا شکریہ۔ اگلی بار ملتے ہیں۔