status=200/CHDIR: systemd ने OpenVPN कभी शुरू नहीं किया

सेवा विफल होती है, लॉग में spawn और एक निर्देशिका का ज़िक्र होता है, और पहली प्रवृत्ति VPN कॉन्फ़िगरेशन जाँचने की होती है। उस फ़ाइल से अभी कुछ भी नहीं पढ़ा गया है। systemd प्रक्रिया तैयार करते समय, निष्पादन योग्य फ़ाइल चलने से पहले ही विफल हो गया, इसलिए न कोई parser, न कोई प्रमाणपत्र और न कोई दूरस्थ होस्ट सलाह लिया गया। स्थिति कोड को OpenVPN के बजाय systemd के बारे में कथन के रूप में पढ़ना ही इसे छोटी जाँच में बदलता है।

एप्लिकेशन से पहले स्थिति कोड पढ़ें

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

यह अंतर महत्वपूर्ण है क्योंकि सुधार अलग-अलग फ़ाइलों में हैं। CHDIR विफलता पथ और सेवा के उसे देखने के तरीके से संबंधित है। Exec विफलता बाइनरी, उसके इंटरप्रेटर या किसी असंबद्ध mount से संबंधित है। VPN का दूरस्थ बिंदु, सिफ़र सूची या प्रमाणपत्र का पथ बदलना इनमें से किसी को भी ठीक नहीं करेगा।

पुष्टि करें कि विफलता शुरुआत में है, सफल संचालन के बाद नहीं। यदि सेवा कल चल रही थी और अब उसी चरण पर विफल होती है, तो निर्देशिका, उसकी अनुमतियों या स्वयं unit में कुछ बदला है, और वही परिवर्तन वह प्रमाण है जिसे खोजना है।

unit से पूछें कि वह कहाँ होना चाहता है

प्रभावी unit पढ़ें, न कि वह फ़ाइल जिसे आप स्थापित मानते हैं, क्योंकि drop-in फ़ाइलें मुख्य unit को कभी बदले बिना कार्य निर्देशिका को ओवरराइड कर सकती हैं। show का आउटपुट प्रश्न का सीधा उत्तर देता है:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

upstream सर्वर टेम्पलेट के लिए कार्य निर्देशिका सर्वर कॉन्फ़िगरेशन निर्देशिका है और इंस्टेंस का नाम उसके भीतर प्रोफ़ाइल चुनता है। इसलिए branch नाम का इंस्टेंस उसी निर्देशिका में अपनी फ़ाइल की अपेक्षा करता है, और कहीं और रखी प्रोफ़ाइल कार्य निर्देशिका की शर्त बिल्कुल पूरी नहीं करती।

unit जो माँगता है उसकी तुलना उससे करें जो मौजूद है। पहले मौजूद रहा पथ, अब कहीं और इशारा करने वाला सिंबॉलिक लिंक, या ऐसा इंस्टेंस नाम जो अब किसी निर्देशिका से मेल नहीं खाता—सब सामान्य परिवर्तन हैं जो ठीक यही विफलता उत्पन्न करते हैं।

पथ को वैसे जाँचें जैसे सेवा देखती है

आपका shell और सेवा फ़ाइल सिस्टम का एक ही दृश्य साझा नहीं करते। कॉन्फ़िगर की गई रूट निर्देशिका या root image unit के भीतर निरपेक्ष पथ का अर्थ बदल देती है, और होस्ट पर स्पष्ट रूप से मौजूद पथ उस नाम स्थान में अनुपस्थित हो सकता है। मैनुअल परीक्षण पर भरोसा करने से पहले unit की सेटिंग्स पढ़ें।

अनुमतियाँ समस्या को बढ़ाती हैं। सेवा एक विशिष्ट उपयोगकर्ता के रूप में चलती है, और उस उपयोगकर्ता को लक्ष्य तक पहुँचने के लिए हर जनक निर्देशिका से गुज़रना संभव होना चाहिए, न कि केवल लक्ष्य को पढ़ना। root के लिए पठनीय पर सेवा उपयोगकर्ता के लिए अगम्य निर्देशिका ऐसी विफलता उत्पन्न करती है जो अनुपस्थित पथ जैसी लगती है।

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

सख़्ती की सेटिंग्स भी इस चित्र का हिस्सा हैं। जो unit होम निर्देशिकाएँ छिपाता है या फ़ाइल सिस्टम के किसी भाग को केवल-पढ़ने योग्य बनाता है, वह ठीक वही करता है जिसके लिए उसे कॉन्फ़िगर किया गया, और कार्य निर्देशिका वहाँ होनी चाहिए जहाँ sandbox अब भी उसे उजागर करता है।

स्वामी ठीक करें, फिर दूसरी त्रुटि की प्रतीक्षा करें

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

कॉन्फ़िगरेशन ट्री पर अनुमतियाँ बढ़ाने या sandbox हटाने के शॉर्टकट का विरोध करें। दोनों लक्षण मिटा देते हैं और साथ ही वे सुरक्षाएँ हटा देते हैं जो जानबूझकर वहाँ रखी गई थीं, और अगली विफलता की व्याख्या कठिन होगी।

इंस्टेंस पुनः आरंभ करें और सफलता मान लेने के बजाय अगली घटना पढ़ें। संभावित अगली त्रुटि यह है कि OpenVPN अपनी कॉन्फ़िगरेशन फ़ाइल नहीं खोल सकता, जो प्रगति है: कार्य निर्देशिका में प्रवेश हो गया और parser अब चल रहा है। वहाँ से unit की वास्तविक फ़ाइल मैपिंग का पालन करें, नेटवर्क समस्या-समाधान की ओर न लौटें।

systemd का निष्पादन संदर्भ परिभाषित करता है कि कार्य निर्देशिका को रूट निर्देशिकाओं और sandbox के साथ कैसे समझा जाता है। याद रखने योग्य पैटर्न सरल है: हर स्थिति कोड भिन्न चरण का नाम बताता है, और केवल एप्लिकेशन की अपनी त्रुटियाँ ही एप्लिकेशन का वर्णन करती हैं।