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 जीवनचक्रको हिस्सा हो कि हातले गरिने निदान रहनुपर्ने हो निर्णय गर्नुहोस्, किनकि दोस्रो पृष्ठभूमि सुरुङ प्रक्रियाले प्रतिस्पर्धी मालिक बनाउँछ।

मागअनुसार सही आउटपुट प्रिन्ट गर्ने युनिट राम्रो पहिलो कोसेढुंगा हो। यो अझै सुरुङ होइन, र सुरुङ भएको नाटक गर्नु हुँदैन।