जेव्हा 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 होस्टवर, किंवा व्यवस्थापक नसलेल्या ठिकाणी क्लायंट अग्रभागी चालवून. अग्रभागी चालवणे हे प्रोफाइल स्वतः कार्य करते याची खात्री करण्याचा सर्वात वेगवान मार्गही आहे.

तुमच्या टिपांमध्ये दोन्ही पर्यावरणे वेगळी ठेवा: बोगदा चालवणारे होस्ट, आणि तुम्ही आदेश टाइप करता ते ठिकाण.

संबंधित लेख