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