कोई चीज़ बार-बार एक 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 पुनः लोड करें, फिर परिणामी स्थिति का निरीक्षण करें। डेमन पुनः लोड चल रही टनल में नया प्रोफ़ाइल नहीं धकेलता, इसलिए दोनों जाँचें अलग हैं। रीबूट निर्धारित करें और पुष्टि करें कि इंस्टेंस अनुपस्थित रहता है जबकि इच्छित टनल अभी भी काम करती है।

पुरानी प्रोफ़ाइल तब तक रखें जब तक उसका स्वामित्व समझ न आए, फिर उसे इच्छित प्रक्रिया से सेवानिवृत्त करें। सफलता एक अनुपस्थित यूनिट और काम करने वाला एक्सेस मार्ग है, न कि एक विफल यूनिट जो एक स्क्रीन से गायब है।