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 ఫైల్ ప్రవేశం లేకపోవచ్చు, దాని నెట్‌వర్క్ నేమ్‌స్పేస్ లిసనర్‌ను చేరుకోలేకపోవచ్చు లేదా ప్రాక్సీ అభ్యర్థనను తిరస్కరించవచ్చు. ఇవి తదుపరి తనిఖీలు, సంబంధం లేని షెల్ ప్రొఫైల్‌లను సవరిస్తూ ఉండటానికి కారణాలు కావు.