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 फाइलचा प्रवेश नसू शकतो, तिच्या नेटवर्क नेमस्पेसमधून लिसनर गाठता येत नसेल किंवा प्रॉक्सी विनंती नाकारू शकतो. या पुढील तपासण्या आहेत, असंबंधित शेल प्रोफाइल संपादित करत राहण्याची कारणे नाहीत.