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

ऊपर का हर कमांड केवल स्थिति पढ़ता है, और अगर मशीन अभी भी जवाब दे सकती है तो पहले दो अगले रीबूट से पहले चलाए जाने चाहिए। जहाँ जर्नल स्थायी नहीं है, वहाँ केवल वही दो फिर कभी काम करेंगे।

कुंजियाँ, पासवर्ड और असंबंधित ट्रैफ़िक हटाएँ, लेकिन ट्रेस पढ़ने के लिए किसी को ज़रूरी फ़ंक्शन नाम और ऑफ़सेट रखें। सामग्री को उस रिपोर्टिंग मार्ग से भेजें जो डिस्ट्रिब्यूशन या कर्नेल पर लागू हो, होस्टनाम जुड़े सार्वजनिक पेस्ट से नहीं। फिर और क्रैश बटोरने के बजाय प्रश्न की प्रतीक्षा करें, क्योंकि मिलते-जुलते बिल्ड के सामने स्थानित फ़ॉल्ट ही एकमात्र परिणाम है जो रिपोर्ट को आगे बढ़ाता है। अगर कुछ वापस न आए, तो विकल्प अतिरिक्त हार्डवेयर पर नियंत्रित पुनरुत्पादन है, कभी उस मशीन पर नहीं जिस पर दूसरे लोग निर्भर हैं।