systemd સેવાને તમારા શેલની પ્રૉક્સી સેટિંગ કેમ મળતી નથી
પ્રૉક્સી ગોઠવણી systemd સેવાના વાસ્તવિક વાતાવરણમાં મૂકો; ટર્મિનલમાં export કરવાથી ચાલતી પ્રક્રિયા ફરી ગોઠવાતી નથી.
ટર્મિનલમાં બીજું ચલ એક્સપોર્ટ કરવાને બદલે નિષ્ફળ થતી સેવા તપાસો. 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 ફાઇલની ઍક્સેસ ન હોઈ શકે, તેના નેટવર્ક નેમસ્પેસમાંથી લિસનર સુધી પહોંચી ન શકાતું હોય અથવા પ્રૉક્સી વિનંતી નકારી શકે. આ આગળની તપાસ છે, અસંબંધિત શેલ પ્રોફાઇલ સંપાદિત કરતા રહેવાનાં કારણો નથી.