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

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