VPN यूनिट नेटवर्क से पहले क्यों शुरू होती है और फिर मर जाती है

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

लक्ष्य मिलन-स्थल है, प्रबंधक नहीं

network-online.target को पता ही नहीं कि नेटवर्क क्या है। यह एक समन्वय बिंदु है जो उस सेवा को इकट्ठा करता है जिसे लिंक उपयोगी होने तक शुरुआत में देरी करनी चाहिए, और यह परिभाषा उस नेटवर्क मैनेजर को सौंप देता है जो मशीन का मालिक है। अधिकांश डेस्कटॉप और सर्वर पर इसका मतलब NetworkManager या systemd-networkd द्वारा दी जाने वाली प्रतीक्षा-सेवा है। दोनों में से कोई सक्रिय न करें तो लक्ष्य के पास प्रतीक्षा करने को कुछ नहीं रहता, इसलिए जिस क्षण कोई चीज़ उसे खींच लेती है वह उसी क्षण पूरा हो जाता है, और यह DHCP के जवाब देने से बहुत पहले हो सकता है। आपकी यूनिट की क्रम-पंक्ति ईमानदार थी और फिर भी बेकार।

इसलिए पहला सवाल यह नहीं है कि आपकी यूनिट क्या घोषित करती है। सवाल यह है कि क्या इस मशीन पर वास्तव में कुछ प्रतीक्षा कर रहा है।

यूनिट फ़ाइल के बजाय अंतिम बूट पढ़ें

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

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

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

प्रतीक्षा जोड़ें, फिर पुनःप्रयास

पैकेज किए गए यूनिट को संपादित करने के बजाय drop-in का उपयोग करें, ताकि पैकेज अपडेट बदलाव को चुपचाप न फेंके। दो निर्देश मायने रखते हैं: यूनिट को लक्ष्य के बाद क्रमित होना चाहिए, और उसे लक्ष्य को उसी लेनदेन में खींचना चाहिए। केवल क्रम लक्ष्य को नहीं बुलाता; इच्छा वह करती है।

OpenVPN क्लाइंट की पैकेज की गई यूनिट पहले से दोनों रखती है। हाथ से लिखी यूनिटें आम तौर पर एक या कोई नहीं रखतीं, जिसे कुछ भी जोड़ने से पहले जाँचना उचित है।

[Service]
Restart=on-failure
RestartSec=15

तय नींद एक जाल क्यों है

ExecStartPre में नींद क्रम-सुधार जैसी लगती है और अतिरिक्त कदमों वाली देरी जैसी व्यवहार करती है। यह हर बूट को धीमा करती है, उन सहित जो स्वस्थ थे, और जब लिंक आपके चुने नंबर से अधिक समय लेता है तब भी हार जाती है।

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

जब क्रम सही हो और नाम तब भी विफल हों

टनल मार्ग वाली सक्रिय यूनिट का अर्थ है कि क्रम ने अपना काम किया और बची हुई गड़बड़ी एक परत ऊपर है। सामान्य रूप वह रिज़ॉल्वर सेटिंग है जिसे टनल की up स्क्रिप्ट लिंक या रिज़ॉल्वर के उसे थामने के लिए तैयार होने से पहले लागू करती है। विफलता के दौरान रिज़ॉल्वर की स्थिति की तुलना टनल यूनिट के पुनःआरंभ के बाद की स्थिति से करें।

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