केही कुराले बारम्बार OpenVPN युनिट सुरु गरिरहेको छ: स्रोत खोज्नुहोस्

OpenVPN इन्स्ट्यान्स बुटको समयमा तपाईं नचिन्ने नाममा आउँछ, र यसलाई रोक्नु अर्को रिबुटसम्म काम गर्छ। यो ढाँचाले तपाईंले प्रक्रिया हटाउनुभयो तर सक्रियता होइन भन्ने देखाउँछ। यी दुई फरक वस्तु हुन्, र स्टेटस स्क्रिनमा तीमध्ये एउटा मात्र देखिन्छ। सक्रियता खोज्न चार पढ्ने-मात्र आदेश र एउटा निर्णय चाहिन्छ।

पहिले सही युनिटको नाम दिनुहोस्

प्रोफाइल फाइलको नामको सट्टा journalमा युनिटको नामबाट सुरु गर्नुहोस्। इन्स्ट्यान्सको नाम openvpn@, openvpn-client@, openvpn-server@ वा वितरण-विशेष केही हुन सक्छ, र नाम अनुमान गर्नु तपाईंलाई गलत टेम्प्लेटमा पुर्‍याउँछ। स्टेटस आउटपुटले त्यो युनिटको नाम दिन्छ जो वास्तवमा चल्यो, र यहाँ त्यही नाम मात्र महत्त्वपूर्ण छ। यसलाई ठ्याक्कै त्यस्तै प्रतिलिपि गर्नुहोस्, कुनै पनि प्रत्ययसहित।

तलका आदेशले केही नबदली त्यो युनिटको वर्णन गर्छन्। systemctl show फ्र्यागमेन्ट पथ, स्रोत पथ, युनिट फाइलको अवस्था, कुनै पनि drop-in र यसलाई केले सक्रिय गर्‍यो भन्ने जानकारी दिन्छ। list-dependencies --reverse कुन लोड गरिएका युनिटहरू यसतर्फ संकेत गर्छन् देखाउँछ। दुवै पढ्ने-मात्र हुन्, त्यसैले सिद्धान्त बनाउनु अघि तिनीहरू चलाउनुहोस्।

देखिएको नाम सबैतिर बदल्नुहोस्। प्रतिलिपि गरिएको उदाहरण नाम गलत सेवा अन्वेषण गर्ने सबैभन्दा सामान्य तरिका हो, र यसले कहिल्यै नचलेको युनिटबारे आत्मविश्वासी उत्तर दिन्छ।

फाइलको नाम जान्न टेम्प्लेट पढ्नुहोस्

इन्स्ट्यान्स युनिट टेम्प्लेटको विस्तार हो, र टेम्प्लेटले तय गर्छ कुन कन्फिगरेसन फाइल पढिन्छ। इन्स्ट्यान्स-विशेष प्लेसहोल्डरमा अन्त्य हुने आदेश लाइन इन्स्ट्यान्स नाम र प्रत्ययमा परिणत हुन्छ। यदि प्रत्यय .conf छ र इन्स्ट्यान्सको नाम old छ, फाइल old.conf हो। यदि इन्स्ट्यान्सको नाम old.conf राख्नुभयो, त्यही टेम्प्लेटले old.conf.conf माग्छ।

यो विवरणले डुप्लिकेटको एक वर्ग व्याख्या गर्छ। कसैले गलत नाममा दोस्रो इन्स्ट्यान्स थप्छ, पहिलो चलिरहन्छ, र होस्ट दुई टनेल र एउटा भ्रमित लगसहित रहन्छ।

तपाईंले सम्पादन गरेको सम्झिएको फाइलको सट्टा प्रभावकारी टेम्प्लेट पढ्नुहोस्। Drop-in ले आदेश लाइन बदल्न सक्छ, र बुटमा त्यही प्रतिस्थापन चल्छ।

यो बुट ट्रान्ज्याक्सनमा कसरी प्रवेश गर्छ ट्रेस गर्नुहोस्

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

/run/systemd/generator मुनि उत्पन्न आउटपुट उत्पादन हो, स्रोत होइन। यसलाई सम्पादन गर्नु अर्को जेनेरेसनसम्म मात्र टिक्छ, त्यसैले त्यहाँ लागू गरिएको सुधार सफल देखिन्छ र त्यसपछि फर्किन्छ।

जेनेरेटर कहाँबाट पढ्छ भनी मान्नु अघि प्याकेजको दस्तावेजीकृत इनपुट जाँच्नुहोस्। कुनै डाइरेक्टरीको अदस्तावेजीकृत स्क्यानिङ नै सामान्य कारण हो जसले युनिट सक्रियता लिङ्कबिना देखिन्छ।

सक्रियता हटाउनुहोस्, प्रक्रिया मात्र होइन

यदि इन्स्ट्यान्स सिधै सक्रिय छ र साँच्चै पुरानो छ, systemctl disable --now ले यसलाई रोक्छ र एकै चरणमा बुट लिङ्क हटाउँछ। पहिले जाँच्नुहोस् कि यो टनेल होस्टसम्मको तपाईंको एकमात्र प्रशासनिक बाटो होइन। आदेश जीवनचक्रको उदाहरण हो, मेसिनमा हरेक VPN रोक्ने सुझाव होइन। जाँच आदेश अघि गर्नुहोस्, पछि होइन।

दुई आधा भाग छुट्याउन सकिन्छ र प्रायः भ्रमित हुन्छन्। असक्षम गर्नु चलिरहेको सेवा रोक्दैन, र रोक्नु सक्रियता हटाउँदैन, त्यसैले आंशिक आदेशले बुटमा फर्कने समस्या व्याख्या गर्छ।

असक्षम युनिट अझै अर्को युनिट वा स्पष्ट अनुरोधले सुरु गर्न सकिन्छ। जब सक्रियता जेनेरेटरसँग हुन्छ, त्यसको आउटपुट असक्षम गर्नुको सट्टा इनपुट सुधार्नुहोस्। मास्किङले बढी बाटो रोक्छ तर निर्भरता तोड्न सक्छ, त्यसैले यो बुझाइको विकल्प होइन।

स्टेटस स्क्रिनले होइन, रिबुटले प्रमाणित गर्नुहोस्

यदि युनिट परिभाषा वा जेनेरेटर इनपुट बदलिएका छन् भने systemd पुनः लोड गर्नुहोस्, त्यसपछि नतिजा अवस्था जाँच्नुहोस्। डेमन पुनः लोडले चलिरहेको टनेलमा नयाँ प्रोफाइल धकेल्दैन, त्यसैले दुई जाँच फरक छन्। रिबुट तालिका बनाउनुहोस् र पुष्टि गर्नुहोस् कि इन्स्ट्यान्स अनुपस्थित रहन्छ जबकि इच्छित टनेल अझै काम गर्छ।

पुरानो प्रोफाइल त्यसको स्वामित्व बुझिन्जेल राख्नुहोस्, त्यसपछि इच्छित प्रक्रियामार्फत अवकाश दिनुहोस्। सफलता अनुपस्थित युनिट र काम गर्ने पहुँच बाटो हो, एक स्क्रिनबाट हराएको असफल युनिट होइन।