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

माथिका हरेक आदेशले अवस्था मात्र पढ्छ, र मेसिनले अझै जवाफ दिन सक्छ भने पहिलो दुई अर्को रिबुट अघि चलाउनुपर्छ। जहाँ जर्नल स्थायी छैन, त्यहाँ ती दुई मात्र फेरि कहिल्यै चल्नेछन्।

कुञ्जी, पासवर्ड र असम्बन्धित ट्राफिक हटाउनुहोस्, तर ट्रेस पढ्न कसैलाई चाहिने फंक्शन नाम र अफसेट राख्नुहोस्। सामग्री वितरण वा कर्नेलमा लागू हुने रिपोर्टिङ मार्गबाट पठाउनुहोस्, होस्टनाम जोडिएको सार्वजनिक पेस्टबाट होइन। त्यसपछि थप क्र्यास सङ्कलन गर्नुको सट्टा प्रश्नको प्रतीक्षा गर्नुहोस्, किनकि मिल्दो बिल्डविरुद्ध स्थानीयकृत फल्ट नै रिपोर्ट अगाडि बढाउने एकमात्र नतिजा हो। केही फर्किएन भने, विकल्प अतिरिक्त हार्डवेयरमा नियन्त्रित पुनरुत्पादन हो, अरू मानिसहरू निर्भर रहेको मेसिनमा कहिल्यै होइन।