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:'

वरच्या प्रत्येक आज्ञेत फक्त स्थिती वाचली जाते, आणि मशीन अजून उत्तर देऊ शकत असेल तर पहिल्या दोन पुढच्या रीबूटपूर्वी चालवायला हव्यात। जिथे जर्नल टिकत नाही, तिथे फक्त त्या दोनच पुन्हा कधीही चालतील।

की, पासवर्ड आणि असंबंधित रहदारी काढा, पण ट्रेस वाचण्यासाठी कोणाला हवी असलेली फंक्शन नावे आणि ऑफसेट ठेवा। सामग्री वितरण किंवा कर्नेलला लागू असलेल्या अहवाल मार्गाने पाठवा, होस्टनाव जोडलेल्या सार्वजनिक पेस्टने नाही। मग अधिक क्रॅश गोळा करण्याऐवजी प्रश्नाची वाट पाहा, कारण जुळणाऱ्या बिल्डविरुद्ध स्थानिकीकृत फॉल्ट हाच अहवाल पुढे नेणारा एकमेव निकाल। काहीही परत आले नाही तर पर्याय म्हणजे जादा हार्डवेअरवर नियंत्रित पुनरुत्पादन, इतर लोक अवलंबून असलेल्या मशीनवर कधीही नाही।