systemctl कहता है कि systemd PID 1 नहीं है: तो अब क्या?

जब systemctl start openvpn-client@office चलाया जाता है और यह संदेश मिलता है कि सिस्टम systemd के साथ बूट नहीं हुआ, तो यह सेवा विफलता जैसा लगता है। यह सेवा विफलता बिलकुल नहीं है: आपने जिस systemctl को पुकारा, उसे बात करने के लिए कोई चालू प्रबंधक नहीं मिलता, इसलिए OpenVPN के बारे में कुछ भी जाँचा नहीं गया। sudo प्रबंधक नहीं बनाता, और unit फ़ाइल स्थापित करने से भी वह नहीं बनता। आदेश और मशीन दो अलग दुनियाओं से आते हैं, और त्रुटि ही एकमात्र जगह है जहाँ यह दिखा।

पहले यह पूछें कि जहाँ आदेश चलता है वहाँ PID 1 किस प्रक्रिया के पास है, क्योंकि यही उत्तर तय करता है कि unit हैं भी या नहीं।

त्रुटि OpenVPN नहीं, परिवेश का नाम लेती है

systemctl एक क्लाइंट है, प्रबंधक नहीं। यह socket के ज़रिए सिस्टम प्रबंधक से जुड़ता है, और जब दूसरे सिरे पर कोई प्रबंधक न हो तो वही संदेश छापता है जिसे लोग फ़ोरम में चिपकाते हैं। ps -p 1 -o pid=,comm= दिखाता है कि वास्तव में PID 1 के रूप में क्या चल रहा है, और उत्तर अक्सर shell, init आवरण या कंटेनर का अपना प्रवेश-बिंदु होता है। ऐसी स्थिति में unit फ़ाइल पूरी तरह वैध हो सकती है और फिर भी कभी पढ़ी न जाए। आदेश को root के रूप में दोहराने से केवल क्लाइंट के क्रेडेंशियल बदलते हैं।

पहली पंक्ति से पहले पूरा संदेश पढ़ें। प्रबंधक की ओर से आने वाली त्रुटि, जैसे गायब unit या विफल शर्त, का अर्थ है कि आप उस तक पहुँचे; इस त्रुटि का अर्थ है कि नहीं पहुँचे।

WSL: systemd सक्षम करना एक कॉन्फ़िग बदलाव है

WSL को बाद के संस्करणों में systemd का समर्थन मिला, लेकिन यह सुविधा प्रत्येक वितरण के लिए अलग से सक्षम होती है और केवल वहीं जहाँ स्थापित WSL संस्करण इसका समर्थन करता है। wsl --version Windows की ओर दिखाता है कि आपके पास क्या है, और वितरण की /etc/wsl.conf फ़ाइल में [boot] अनुभाग है जिसमें systemd=true है। पहले से मौजूद अनुभागों को हटाए बिना उस फ़ाइल को संपादित करें, फिर बदलाव लागू होने के लिए WSL इंस्टेंस को फिर से शुरू करें। wsl --shutdown चल रहे हर वितरण को रोक देता है, इसलिए पहले अपना काम सहेजें।

फिर से खोलने के बाद, OpenVPN unit को छूने से पहले प्रबंधक की पुष्टि करें: ps -p 1 -o comm= को दिखाना चाहिए systemd। systemd सक्षम करने से कोई प्रोफ़ाइल, कोई क्रेडेंशियल और कोई इंस्टेंस नाम नहीं मिलता, इसलिए अगली त्रुटि PID 1 के बजाय इनमें से किसी एक के बारे में होगी।

कंटेनर अपना प्रवेश-बिंदु चलाते हैं, unit नहीं

सामान्य कंटेनर वही शुरू करता है जो उसका प्रवेश-बिंदु या आदेश निर्धारित करता है, और आप जो भी पैकेज स्थापित करें, वह systemd से बूट हुई मशीन नहीं है। इमेज में systemctl जोड़ने से आपको ऐसा क्लाइंट मिलता है जिसके पास जुड़ने के लिए कुछ नहीं है। Community OpenVPN के लिए समर्थित पैटर्न आमतौर पर अग्रभूमि में चलने वाली प्रक्रिया है, openvpn --config /path/to/client.conf, जिसे प्रवेश-बिंदु शुरू करता है और बाहर से निगरानी की जाती है। वही स्वामी शुरुआत, सिग्नल और बंद करने का काम संभालता है, और टनल को प्रबंधित करने वाली उसे ही एकमात्र चीज़ होनी चाहिए।

जो प्रवेश-बिंदु पहले से उस टनल को प्रबंधित करता है, उसके बगल में कभी इंटरैक्टिव प्रति न चलाएँ, क्योंकि दो प्रक्रियाएँ डिवाइस और रूट के लिए लड़ेंगी. कंटेनर के अंदर न्यूनतम init प्रक्रिया बच्चों को इकट्ठा करती है और सिग्नल आगे भेजती है; वह इमेज को unit वाला होस्ट नहीं बनाती।

अगर किसी परिनियोजन को कंटेनर के अंदर वास्तव में systemd चाहिए, तो उसे इसके लिए जानबूझकर डिज़ाइन की गई इमेज चाहिए, systemctl शिकायत करना बंद कर दे तब तक जोड़े जाने वाले अतिरिक्त विशेषाधिकार नहीं।

प्रबंधक मौजूद होने पर अगली त्रुटि पढ़ें

जैसे ही असली प्रबंधक सेवा शुरू करता है, उपयोगी त्रुटियाँ शुरू होती हैं। डिवाइस अनुमति की विफलता, कॉन्फ़िग पार्सिंग की त्रुटि, गायब क्रेडेंशियल और पहुँच से बाहर साथी — ये चार अलग समस्याएँ हैं जिन्हें PID 1 के संदेश ने कभी नहीं जाँचा। उन्हें उसी क्रम में पढ़ें जिसमें unit ने उन्हें पैदा किया, journalctl -u openvpn-client@office -n 50 का उपयोग करके systemd होस्ट पर, या जहाँ प्रबंधक नहीं है वहाँ क्लाइंट को अग्रभूमि में चलाकर। अग्रभूमि में चलाना यह पुष्टि करने का सबसे तेज़ तरीका भी है कि प्रोफ़ाइल स्वयं काम करता है।

अपने नोट्स में दोनों परिवेश अलग रखें: टनल चलाने वाला होस्ट, और वह जगह जहाँ आप आदेश टाइप करते हैं।