Pi वर VPN क्लायंट segfault? आधी प्रक्रिया कॅप्चर करा

तुम्ही क्लायंट सुरू करता, टर्मिनल 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 क्रिया पुन्हा करा. कोणती अयशस्वीता कोणत्या आवृत्तीत थांबली ते सांगा. केवळ स्वच्छ बूट कोणताही दोषी घटक ओळखत नाही आणि पुढील हार्डवेअर बिघाडाचा अंदाजही देत नाही.