systemd सेवाले तपाईंको शेलका प्रोक्सी सेटिङ किन पाउँदैन

टर्मिनलमा अर्को भेरिएबल एक्सपोर्ट गर्नुको सट्टा विफल भएको सेवा जाँच्नुहोस्। systemctl cat example.service ले यसको युनिट र पूरक कन्फिगरेसन देखाउँछ; EnvironmentFile, अर्को ओभरराइड वा एप्लिकेसनका आफ्नै प्रोक्सी सेटिङ छन् कि हेर्नुहोस्। प्रमाणिकरण विवरण भएको आउटपुट स्थानीय रूपमा पढ्नुहोस्।

एप्लिकेसनले HTTP प्रोक्सीका वातावरणीय भेरिएबल प्रयोग गर्छ भने सेवाको पूरक कन्फिगरेसनले यी दिन सक्छ:

[Service]
Environment="HTTP_PROXY=http://203.0.113.10:8080"
Environment="HTTPS_PROXY=http://203.0.113.10:8080"

कागजातको नमुना ठेगाना बदल्नुहोस् र एप्लिकेसनले समर्थन गर्ने भेरिएबलका नाम प्रयोग गर्नुहोस्। सार्वजनिक HTTP प्रोक्सी प्रयोग गर्न अनुमति भएको सेवाका लागि सम्भावित ठेगाना HTTP प्रोक्सी सूचीमा छन्। आफ्नै कन्फिगरेसन भएको क्लाइन्टले यी इनपुट बेवास्ता गर्न सक्छ। यही अपेक्षित सिस्टम सेवा हो भन्ने पनि पुष्टि गर्नुहोस्: प्रयोगकर्ता सेवाको म्यानेजर र वातावरण फरक हुन्छ; उस्तै नाम भएको सिस्टम युनिट बदल्दा त्यो ठीक हुँदैन।

सही युनिट वा पूरक कन्फिगरेसन सम्पादन गरेपछि परिभाषा पुनः लोड गर्नुहोस् र काम रोक्न मिल्ने समयमा सो सेवा पुनः सुरु गर्नुहोस्:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload मात्रैले चलिरहेको प्रक्रियाको वातावरण बदल्दैन। पुनः सुरु गर्दा नयाँ प्रक्रिया सुरु हुन्छ; शेलमा export ले त्यही शेल र त्यसले पछि सुरु गर्ने सन्तान प्रक्रियालाई मात्र असर गर्छ।

सेवाले अपेक्षित URL पाएपछि त्यसको वास्तविक त्रुटि पछ्याउनुहोस्। त्यसको खातामा CA फाइलको पहुँच नहुन सक्छ, त्यसको नेटवर्क नेमस्पेस लिसनरसम्म नपुग्न सक्छ वा प्रोक्सीले अनुरोध अस्वीकार गर्न सक्छ। यी पछिल्ला जाँच हुन्, असम्बन्धित शेल प्रोफाइल सम्पादन गरिरहने कारण होइनन्।