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 ഫയലിലേക്കുള്ള പ്രവേശനം ഇല്ലായിരിക്കാം, നെറ്റ്‌വർക്ക് നെയിംസ്പേസിൽനിന്ന് ലിസനറിലെത്താൻ കഴിയാതിരിക്കാം, അല്ലെങ്കിൽ പ്രോക്സി അഭ്യർത്ഥന നിരസിക്കാം. ഇവ പിന്നീടുള്ള പരിശോധനകളാണ്; ബന്ധമില്ലാത്ത ഷെൽ പ്രൊഫൈലുകൾ തിരുത്തിക്കൊണ്ടിരിക്കാനുള്ള കാരണങ്ങളല്ല.