PID फ़ाइल मौजूद है, सुरंग नहीं: क्या OpenVPN कभी चला था?

जब लॉन्चर OpenVPN शुरू करने से मना करता है क्योंकि PID फ़ाइल पहले से मौजूद है, तो स्वाभाविक पठन यह है कि कहीं सुरंग चल रही है। यह पठन अक्सर इतना गलत होता है कि कुछ भी हटाने से पहले उसे जाँचना उचित है। रनटाइम निर्देशिका में रखी फ़ाइल लेखा-जोखा है, और लेखा-जोखा उन क्रैश, रीबूट और अधूरे शटडाउन से बच जाता है जिन्होंने कोई प्रक्रिया पीछे नहीं छोड़ी। दो प्रश्न मामला तय करते हैं: क्या कोई जीवित प्रक्रिया है, और क्या वह प्रक्रिया इस इंस्टेंस की है।

फ़ाइल से नहीं, सेवा से शुरू करें

मना करना आमतौर पर OpenVPN से नहीं, किसी लॉन्चर से आता है। वह एक पथ पढ़ता है, वहाँ कुछ पाता है और कॉन्फ़िगरेशन पढ़ने से पहले रुक जाता है। इसलिए पहला प्रश्न लॉन्चर के अनुबंध के बारे में है, सुरंग के बारे में नहीं।

संदेश छापने वाली यूनिट या स्क्रिप्ट पढ़ें और तीन बातें नोट करें: वह कौन-सा पथ जाँचती है, कौन-सा सेवा प्रकार घोषित करती है, और क्या वह फ़ाइल लिखने के लिए ज़िम्मेदार है। आधुनिक यूनिट सरल या नोटिफ़ाई पर्यवेक्षण इस्तेमाल कर सकती है और PID फ़ाइल को कभी नहीं छूती, जबकि पुरानी init स्क्रिप्ट खुद एक बना सकती है। एक मॉडल की जाँच दूसरे में नक़ल करने से ठीक इसी तरह का इनकार पैदा होता है। कुछ भी व्याख्या करने से पहले पता करें कि कौन-सा मॉडल इस्तेमाल हो रहा है।

तभी प्रश्न यह बनता है कि क्या कोई इंस्टेंस वास्तव में चल रहा है।

जाँचें कि क्या वह पहचानकर्ता आपके इंस्टेंस का है

फ़ाइल में लिखी संख्या यह सिद्ध करती है कि कोई संख्या लिखी गई थी। यह सिद्ध नहीं करती कि उस पहचानकर्ता वाली प्रक्रिया अब मौजूद है, और निश्चित रूप से यह भी नहीं कि प्रक्रिया आपकी है, क्योंकि रीबूट के बाद पहचानकर्ता दोबारा इस्तेमाल होते हैं।

प्रक्रिया के आरंभ समय की तुलना फ़ाइल की टाइमस्टैम्प से, निष्पादन योग्य फ़ाइल की यूनिट के आदेश से, और सेवा-सदस्यता की यूनिट के नाम से करें। तीनों में से किसी एक में असंगति का अर्थ है कि आप सुरंग नहीं, लेखा-जोखा देख रहे हैं।

कंटेनर या कई नेमस्पेस चलाने वाले होस्ट पर पहचानकर्ता एक दृश्य में अर्थपूर्ण और दूसरे में अनुपस्थित हो सकता है। प्रक्रिया न दिखना भी उसके न होने का प्रमाण नहीं है, यदि आपका खाता उसे जाँच नहीं सकता। निष्कर्ष निकालने से पहले उसी संदर्भ से जाँचें जो लॉन्चर इस्तेमाल करता है।

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

लॉन्चर ने फ़ाइल के साथ क्या करने का वादा किया था

PIDFile= सेवा प्रबंधक को बताता है कि मुख्य प्रक्रिया का पहचानकर्ता कहाँ से पढ़ना है। प्रबंधक वह फ़ाइल नहीं लिखता, लेकिन शटडाउन के बाद बची फ़ाइल हटा देता है, और इसीलिए अधूरा निकास फ़ाइल छोड़ सकता है।

जिम्मेदारी का यह विभाजन उन दो लक्षणों की व्याख्या करता है जिन्हें लोग बग बताते हैं। जो फ़ाइल कभी दिखाई नहीं देती, उसका अर्थ है कि डेमन या उसकी स्क्रिप्ट उसे लिख नहीं सकी, यह नहीं कि पर्यवेक्षण गलत कॉन्फ़िगर है। जो फ़ाइल स्टॉप के बाद बची रहती है, उसका अर्थ है कि शटडाउन का रास्ता कभी पूरा नहीं हुआ।

यह यह भी बताता है कि मौजूदा दिशानिर्देश उस सम्मेलन से बचने की सलाह क्यों देते हैं जब पर्यवेक्षण मुख्य प्रक्रिया को सीधे ट्रैक कर सकता है। वे दिशानिर्देश पैकेज्ड यूनिट का प्रकार बदलने की अनुमति नहीं हैं, क्योंकि डेमन का फ़ोरग्राउंड, फ़ोर्किंग या सूचना व्यवहार वही होना चाहिए जो यूनिट घोषित करती है। डेमन बदले बिना प्रकार बदलें और आपको ऐसी यूनिट मिलेगी जो सुरंग चलते समय विफलता बताती है, या इसका उल्टा। जोड़ी मिलाएँ, या दोनों को छोड़ दें। systemd सेवा संदर्भ स्वामित्व के इस विभाजन का वर्णन करता है।

स्वच्छ शटडाउन बनाम अधूरा निकास

स्वच्छ स्टॉप डेमन से बाहर निकलने को कहता है, उसकी प्रतीक्षा करता है और प्रबंधक को अपना लेखा-जोखा ठीक करने देता है। अधूरा निकास, मारी गई प्रक्रिया या शटडाउन के बीच रीबूट उस क्रम के कुछ हिस्से छोड़ देते हैं, और जो बचता है वह फ़ाइल है। क्रैश के बाद उसे पाना बताता है कि शटडाउन पूरा नहीं हुआ, यह नहीं कि कुछ सुन रहा है।

फ़ाइल की टाइमस्टैम्प की तुलना अंतिम बूट और यूनिट के अंतिम स्टॉप से करें।

फिर जीवित प्रमाण सीधे जाँचें। VPN पोर्ट से बँधा सॉकेट और पता वाला सुरंग इंटरफ़ेस इस बात का प्रमाण हैं कि कुछ चल रहा है, उस तरह से जो रनटाइम निर्देशिका की टेक्स्ट फ़ाइल कभी नहीं होती। यदि दोनों अनुपस्थित हैं, तो कुछ नहीं चल रहा, फ़ाइल चाहे जो भी दावा करे।

फ़ाइल को आदत के तौर पर हटाना बंद करें

किसी इंस्टेंस का उस पर अधिकार नहीं है और लॉन्चर इस व्यवहार का दस्तावेज़ीकरण करता है, यह स्थापित करने के बाद उसे हटाना वैध पुनर्प्राप्ति कदम है।

शुरू करने से पहले की स्थायी आदत के रूप में यह उसी जाँच को बेकार कर देता है जिसे आप बचा रहे हैं। यदि हर स्वच्छ स्टॉप के बाद पुरानी फ़ाइलें लौट आती हैं, तो लिखने वाला और शटडाउन जीवनचक्र इस पर सहमत नहीं हैं कि पथ का स्वामी कौन है, और यही असहमति सुधारने योग्य बग है।

होस्ट में प्रवेश का एक स्वतंत्र रास्ता रखें, उसके सामान्य प्रबंधक से एक इंस्टेंस शुरू करें और पहला परिणाम पढ़ें। अगले व्यक्ति को ऐसी यूनिट मिलती है जो या तो काम करती है या खुद को समझाती है।