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 क्रिया दोहराएँ। बताएँ कि कौन-सी विफलता रुकी और किस संस्करण में। केवल साफ़ बूट किसी दोषपूर्ण घटक की पहचान नहीं करता और अगली हार्डवेयर खराबी की भविष्यवाणी भी नहीं करता।