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 फ़ाइल तक पहुँच न हो, उसका नेटवर्क नेमस्पेस लिसनर तक न पहुँचता हो या प्रॉक्सी अनुरोध अस्वीकार कर सकता है। ये बाद की जाँचें हैं, असंबंधित शेल प्रोफ़ाइल को संपादित करते रहने के कारण नहीं।