ExecStart ही shell नाही: VPN सहाय्यक युनिट दुरुस्त करणे

चालणारी कमांड लाइन ExecStart मध्ये कॉपी करा, रीलोड करा, आणि आर्ग्युमेंटना फाइलनावे मानून युनिट अयशस्वी होते किंवा शांतपणे बाहेर पडते. systemd मध्ये काहीही तुटलेले नाही. ExecStart ही आर्ग्युमेंटची यादी आहे, shell नाही, म्हणून पाइप, रीडायरेक्शन आणि अटी तुमचे टर्मिनल सोडताच अर्थ गमावतात. shell कुठे असावे हे ठरवा, नंतर काय चालवायचे ते नेमके सांगणारे युनिट लिहा.

ExecStart मधील पाइपलाइन काहीच का करत नाही

टर्मिनलमध्ये कमांड टाइप केल्यावर shell तिचे प्रथम विश्लेषण करते. ती पाइपलाइन बांधते, रीडायरेक्शनसाठी फाइली उघडते आणि कोणताही प्रोग्राम सुरू होण्यापूर्वी चल वाढवते. systemd यापैकी काहीही करत नाही: ते स्वतःच्या नियमांनुसार ExecStart विभाजित करते आणि परिणामी प्रोग्राम त्या आर्ग्युमेंटसह चालवते. म्हणून > शब्दशः आर्ग्युमेंट म्हणून येते, आणि | दोन प्रक्रिया जोडण्याऐवजी प्रोग्रामला दिले जाते. युनिट चुकीचे वागत नाही; वाक्यरचनेचा अर्थ दुसराच होता.

हे निष्काळजीपणा नाही, जाणूनबुजून आहे, कारण आर्ग्युमेंटची अंदाजे हाताळणीच युनिटना लेखापरीक्षणयोग्य बनवते. shell आहे असे गृहीत धरणाऱ्यांनाच याचे आश्चर्य वाटते.

काय चालते ते नेमके सांगणारे युनिट लिहा

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

[Unit]
Description=Report the installed OpenVPN version

[Service]
Type=oneshot
ExecStart=/usr/sbin/openvpn --version
StandardOutput=journal
StandardError=journal

मार्ग हा प्लेसहोल्डर आहे, म्हणून प्रत्यक्षात इंस्टॉल केलेली बाइनरी ठेवा. Type=oneshot शेवटपर्यंत चालणाऱ्या कमांडसाठी योग्य आहे, आणि जर्नल सेटिंग्ज तिचे आउटपुट टर्मिनलशिवाय वाचता येईल अशा ठिकाणी ठेवतात. जाणूनबुजून इंस्टॉल विभाग नाही, म्हणून युनिट बूटवर सक्षम होण्याऐवजी हाताने बोलावले जाते. सुरू करण्यापूर्वी फाइल तपासा, कारण निर्देशाच्या नावातील टाइपो मार्गातील टाइपोपेक्षा वेगळ्या प्रकारे अयशस्वी होतो.

systemd-analyze verify /etc/systemd/system/openvpn-version.service
systemctl start openvpn-version.service

shell तर्क स्क्रिप्टमध्ये ठेवा

सहाय्यकाला खरोखर सशर्त तर्क हवा असल्यास तो तर्क स्क्रिप्टमध्ये ठेवा आणि स्पष्टपणे बोलवा. स्क्रिप्टला इंटरप्रिटर ओळ, चालवण्याची परवानगी आणि सेवा नोंदवू शकणारे एक्झिट कोड आवश्यक आहेत. /bin/sh -c अवतरण चिन्हांत असलेल्या कमांडसह चालवणे काम करते, पण ते युनिटच्या आत अवतरण नियम लपवते आणि पुनरावलोकन कठीण करते. नाव असलेली स्क्रिप्ट हाताने तपासता येते आणि नंतर युनिट न बदलता बदलता येते. इंटरअ‍ॅक्टिव्ह वापरकर्त्याच्या shell प्रोफाइलवर अवलंबून राहू नका, कारण सेवा स्वतःच्या वातावरणासह सुरू होते.

सापेक्ष मार्ग महत्त्वाचे असताना WorkingDirectory सेट करा, आणि वातावरण टर्मिनलमध्ये निर्यात करण्याऐवजी युनिटच्या समर्थित निर्देशांद्वारे पाठवा. गुपिते संरक्षित फाइलींमध्ये किंवा क्रेडेन्शियलमध्ये असतात, जर्नल नोंदवू शकणाऱ्या आर्ग्युमेंट यादीत नाहीत.

प्रत्यक्षात अस्तित्वात असलेले युनिट तपासा

drop-in फाइली तुम्ही संपादित केल्याचे आठवणारी फाइल न छुता वर्तन बदलतात. व्यवस्थापकाने काय लोड केले आणि शेवटच्या रनने काय नोंदवले ते वाचा.

systemctl cat vpn-helper.service
journalctl -u vpn-helper.service -n 20 --no-pager

युनिट डंप लोड क्रमाने drop-in फाइली समाविष्ट करतो, आणि अनपेक्षित ExecStart बहुतेक तिथूनच येतो. कोणत्याही बदलानंतर व्यवस्थापक रीलोड करा आणि नवीन व्याख्या systemctl cat प्रिंट करतो तीच आहे याची खात्री करा. जर्नल अचूक कमांड लाइन आणि एक्झिट स्थिती दाखवते, जे आर्ग्युमेंटची समस्या गहाळ बाइनरी किंवा परवानगी त्रुटीपासून वेगळी करते. नंतर सहाय्यक सध्याच्या VPN जीवनचक्राचा भाग आहे की हाताने केलेले निदान राहावे हे ठरवा, कारण दुसरी पार्श्वभूमी बोगदा प्रक्रिया स्पर्धक मालक निर्माण करते.

मागणीनुसार योग्य आउटपुट प्रिंट करणारे युनिट चांगला पहिला टप्पा आहे. तो अजून बोगदा नाही, आणि बोगदा असल्याचे नाटक करू नये.