Pi پر VPN کلائنٹ segfault؟ پہلے عمل کو قید کریں
شیل segmentation fault چھاپتا ہے اور کارڈ دوبارہ لکھا جاتا ہے۔ کوئی بھی ہارڈویئر بدلنے سے پہلے ایگزیکیوٹیبل، ورژن اور کریش ریکارڈ درج کریں۔
آپ کلائنٹ شروع کرتے ہیں، ٹرمینل Segmentation fault (core dumped) چھاپتا ہے، اور اگلا گھنٹہ کارڈ دوبارہ لکھنے میں جاتا ہے۔ وہ پیغام بتاتا ہے کہ ایک عمل ایک لمحے میں کیسے مرا۔ یہ نہیں کہتا کہ بورڈ خراب ہے، اور نہ ہی بجلی کی فراہمی، اسٹوریج یا امیج کو بری کرتا ہے۔
شیل کی چھاپی ہوئی لائن سے اس کے پیچھے موجود عمل کی طرف کام کریں۔ مفید حقائق یہ ہیں کہ کون سی ایگزیکیوٹیبل ناکام ہوئی، کس ماحول میں اور کنکشن کے کس مرحلے پر۔
شیل کی چھاپی ہوئی لائن سے شروع کریں
آپ کے حکم میں نام اکثر ایک ریپر یا لانچر ہوتا ہے جو دوسری بائنری شروع کرتا ہے، اس لیے تصدیق کریں کہ کرنل نے اصل میں کون سی ایگزیکیوٹیبل ختم کی۔ پورا راستہ، پیکیج اور ایپلیکیشن ورژن، آرکیٹیکچر، OS اور کرنل ریلیز، شروع کرنے والا اکاؤنٹ اور درست وقت لکھیں۔ VPN کے نام والا شیل حکم آسانی سے معاون عمل شروع کر سکتا ہے، اور ریکارڈ اسی معاون کا نام لے گا۔ پچھلے مہینے نصب کردہ پیکیج کی ورژن سٹرنگ کاپی کرنا اس بارے میں کچھ نہیں بتاتا کہ کیا چلا۔
نوٹ کریں کہ کریش سے فوراً پہلے کیا ہوا: اسٹارٹ اپ، پروفائل پارسنگ، تصدیق، یا ایسا سیشن جو پہلے ہی ٹریفک گزر رہا تھا۔ وہ چار مراحل segfault لفظ سے کہیں زیادہ تلاش کو محدود کرتے ہیں۔ اس واقعے کے ارد گرد مختصر لاگ ونڈو رکھیں، اور جب تک ریکارڈ نہ کہے کہ کون سی حالیہ تبدیلی نے یہ کیا، اندازے چھوڑ دیں۔
معلوم کریں کہ میموری امیج موجود ہے یا نہیں
core فائل کا حوالہ ڈمپ کو اختتام کے وقت لکھی گئی عمل کی میموری کی امیج بتاتا ہے، اور ان شرائط کی بھی فہرست دیتا ہے جو اس تحریر کو روکتی ہیں۔ ان شرائط میں صفر وسائل کی حد اور ایسا core پیٹرن شامل ہے جو ڈمپ کو ورکنگ ڈائریکٹری سے باہر بھیجتا ہے۔ اس لیے core نامی فائل کا نہ ہونا اس بارے میں کچھ ثابت نہیں کرتا کہ کریش ہوا یا نہیں۔ نظام نے کوئی ثبوت پیدا نہیں کیا، یہ نتیجہ اخذ کرنے سے پہلے ترتیب شدہ پیٹرن اور حد چیک کریں۔
systemd کے جمع کنندہ والے نظام میں، معاون منظر محفوظ ریکارڈ کو ایگزیکیوٹیبل اور وقت سے جوڑتا ہے۔ جرنل اندراج اور پڑھنے کے قابل میموری امیج دو مختلف نمونے ہیں: برقراری کی پالیسی اور اجازتیں ایک کو دوسرے کے بغیر چھوڑ سکتی ہیں۔ تقسیم یا ایپلیکیشن کے منتظم سے ان کے معاون تشخیصی ورک فلو کے بارے میں پوچھیں، کیونکہ کسی دوسرے بلڈ یا دوسرے لائبریری سیٹ سے بنایا گیا ٹریس عام طور پر ان کا وقت ضائع کرتا ہے۔
sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn
وہ پڑھائیاں اسی مشین پر دہرائیں جو واقعی کریش ہوئی۔ نئی تنصیب پر وہ کرنا ایسے سوال کا جواب دینا ہے جو کسی نے نہیں پوچھا۔
ڈمپ کو راز رکھنے والے مواد کے طور پر دیکھیں
عمل کی میموری میں اسناد، سیشن کیز اور پروفائل کا مواد ہو سکتا ہے، جو ڈمپ کو پاس کے متنی لاگ سے زیادہ حساس بناتا ہے۔ لاگ میں ترمیم کرنا غیر واضح میموری امیج کے لیے کچھ نہیں کرتا، اور عام issue ٹریکر سپورٹ تھریڈ کے دورانیے سے کہیں زیادہ عرصہ منسلکات رکھتے ہیں۔ فائل کو وہ نجی چینل استعمال کرتے ہوئے منتقل کریں جو وینڈر یا منتظم فراہم کرتا ہے۔ عوامی issue میں خام ڈمپ پوسٹ کرنا ہر وہ چیز بے نقاب کرتا ہے جو عمل کی موت کے وقت میموری میں تھی، اور جب تک کوئی جانچ نہ کرے آپ جان نہیں سکتے کہ وہ کیا تھا۔
اگر منتظم ٹریس مانگے تو پوچھیں کہ کس ایگزیکیوٹیبل اور کون سی لائبریریوں سے چاہیے۔ جس کے فریم رپورٹ شدہ بلڈ سے میل نہیں کھاتے، ایسا backtrace بھروسے کے قابل نہیں اور غلط پڑھنا آسان ہے۔
کچھ بدلنے سے پہلے ماخذ چیک کریں
تنصیب کے مالک کے ذریعے پیکیج کا ماخذ اور فائل کی سالمیت کی تصدیق کریں، اور کسی بھی کنٹرول شدہ مرمت سے پہلے ترتیب اور شناختی مواد محفوظ رکھیں۔ صرف یہ دیکھنے کے لیے کہ صاف تنصیب بوٹ ہوتی ہے یا نہیں، ثبوت کی واحد نقل کو نہ مٹائیں۔ نئی امیج بوٹ ہوتی ہے کا مطلب صرف یہ ہے کہ نئی امیج بوٹ ہوتی ہے۔ یہ نہیں بتاتی کہ پرانی میں خراب پیکیج، ناکام ہوتا کارڈ یا ایسی بائنری تھی جو اس آرکیٹیکچر پر ہمیشہ فالٹ کرتی۔
اگر غیر متعلقہ پروگرام بھی ناکام ہوں، یا نظام اسٹوریج، بجلی یا کرنل کی خرابی لاگ کرے، تو وہ مشاہدات پلیٹ فارم کی تحقیقات کے لیے رکھیں۔ وہ دائرہ وسیع کرتے ہیں؛ یہ ثابت نہیں کرتے کہ ہر segfault ناکام RAM یا خراب امیج سے آتا ہے۔
ھدف شدہ اصلاح کے بعد وہی مجاز لانچ اور وہی VPN کارروائی اسی ہارڈویئر پر دہرائیں۔ بتائیں کہ کون سی ناکامی کس ورژن میں رکی۔ صرف صاف بوٹ کسی ناقص جزو کی شناخت نہیں کرتا اور نہ اگلی ہارڈویئر خرابی کی پیش گوئی کرتا ہے۔