Derfor får ikke en systemd-tjeneste proxyoppsettet fra skallet ditt

Se nærmere på tjenesten som feiler, fremfor å eksportere enda en variabel i terminalen. systemctl cat example.service viser enheten og tilleggsfilene; se etter en EnvironmentFile, andre overstyringer eller proxyoppsett i selve applikasjonen. Les utdata som inneholder påloggingsinformasjon lokalt.

Hvis applikasjonen leser miljøvariabler for HTTP-proxy, kan en tilleggsfil for tjenesten inneholde:

[Service]
Environment="HTTP_PROXY=http://203.0.113.10:8080"
Environment="HTTPS_PROXY=http://203.0.113.10:8080"

Erstatt eksempeladressen fra dokumentasjonen, og bruk variabelnavn applikasjonen støtter. Dersom tjenesten har lov til å bruke offentlige HTTP-proxyer, finner du mulige adresser i HTTP-proxylisten. En klient med eget oppsett kan se bort fra disse verdiene. Kontroller også at du har riktig systemtjeneste: En brukertjeneste har sin egen tjenestebehandler og sitt eget miljø. Å endre en systemenhet med lignende navn løser ikke problemet til brukertjenesten.

Når riktig enhet eller tilleggsfil er redigert, laster du definisjonene på nytt og starter tjenesten på nytt når arbeidsbelastningen tillater et avbrudd:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload skifter ikke alene ut miljøet til en kjørende prosess. Omstarten starter en ny prosess; en eksport i skallet gjelder bare dette skallet og underprosessene det senere starter.

Etter at tjenesten får den forventede URL-en, tar du utgangspunkt i den faktiske feilen. Kontoen dens kan mangle lesetilgang til CA-filen, nettverksnavnerommet kan være ute av stand til å nå lytteren, eller proxyen kan avvise forespørselen. Dette er de neste kontrollene, ikke grunner til å fortsette å endre uvedkommende skallprofiler.