VPN شروع ہوتے وقت کرنل Oops: محفوظ رکھنے کے قابل ثبوت

VPN کلائنٹ شروع کرنا ایک سہولت بخش وقت کی مہر ہے، سبب نہیں، اور یہی فرق طے کرتا ہے کہ آگے کیا ہوگا۔ جب اسی لمحے کے قریب کرنل Oops آتا ہے، تو انتخاب قابل استعمال فالس رپورٹ جمع کرنے اور پیداواری مشین پر وہی کریش مزید پانچ بار پیدا کرنے کے درمیان ہوتا ہے۔ ری بوٹ سے پہلے چار چیزیں محفوظ کریں: درست کرنل بلڈ، پہلا فالس ٹریس، taint کی حالت اور اسی منٹ میں بدلی ہوئی باقی ہر چیز کی مختصر وضاحت۔ باقی تشریح ہے، اور ثبوت محفوظ جگہ پر پہنچنے تک تشریح انتظار کر سکتی ہے۔

آخری سطر نہیں، پہلا فالس پکڑیں

لاگ میں پہلا Oops ہی اہم ہے، کیونکہ ہر بعد والا فالس پہلے ہی غیر صحت مند کرنل کا ضمنی نقصان ہو سکتا ہے۔ کال ٹریس کے ساتھ ہیڈر کاپی کریں، کیونکہ ہیڈر میں فالس پیدا کرنے والی ہدایت اور کوڈ راستہ پہچاننے والی رجسٹر حالت ہوتی ہے۔ آخری سطر سے شروع ہونے والی رپورٹ ایک ہفتے بعد پڑھنے والے کے لیے بہت کم قیمت کی ہوتی ہے۔

اگر مشین پہلے ہی ری بوٹ ہو چکی ہے، تو پچھلے بوٹ کا کرنل بفر اکثر اب بھی جرنل میں رہتا ہے، بشرطیکہ اس وقت مستقل اسٹوریج فعال ہو۔ کام کا بوجھ دوبارہ بنانے کے بجائے اسے محفوظ فائل سے پڑھیں، کیونکہ دوسری تولید آپ کی مطلوبہ چیز کو مٹا سکتی ہے۔ جہاں مشین ری بوٹ کے درمیان جرنل نہیں رکھ سکتی، وہاں سیریل کنسول یا netconsole ہی فالس کے کبھی نظر آنے کا واحد طریقہ ہے۔

کسی بھی علامت کو پڑھنے سے پہلے بلڈ طے کریں

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

درخت سے باہر کے ماڈیولز ریکارڈ میں اپنی الگ سطر کے حقدار ہیں، کیونکہ taint شدہ کرنل محدود کرتا ہے کہ دیکھ بھال کرنے والا کیا نتیجہ نکال سکتا ہے۔ ماڈیول فہرست سے اندازہ لگانے کے بجائے taint کی قدر پڑھیں۔

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

ٹرگر کو نقص سے الگ کریں

سرنگ شروع کرنا عام طور پر پہلے سے موجود راستہ استعمال کرتا ہے: نیٹ ورک ڈرائیور، قطار کا نظم، offload خصوصیت یا پاور حالت۔ ٹرگر بتاتا ہے کہ فالس کب ظاہر ہوتا ہے، یہ نہیں کہ کون سا کوڈ غلط ہے، اور ٹرگر کو سبب سمجھنے سے ایسی ترتیب بدلاؤں کی قطار بنتی ہے جو کچھ بھی درست نہیں کرتی۔

پہلے کی کام کرنے والی امیج ثبوت ہے، ثبوتِ کامل نہیں۔ موازنہ کرتے ہوئے ہر بوٹ پر ایک جزو بدلیں، اور نتائج ایسی جگہ رکھیں جو مشین کے بعد بھی بچے۔

جانچیں کہ دیکھ بھال کرنے والا واقعی کیا استعمال کر سکتا ہے

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

uname -r
cat /proc/sys/kernel/tainted
journalctl -k -b -1 --no-pager | sed -n '/BUG:/,/Call Trace/p'
dmesg -T | grep -A 40 'RIP:'

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

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