Hvorfor en systemd-tjeneste ikke får skallets proxyinnstillinger

Undersøk tjenesten som feiler i stedet for å eksportere enda en variabel i terminalen. systemctl cat example.service viser enheten og de supplerende konfigurasjonsfilene; se etter en EnvironmentFile, andre overstyringer eller programmets egne proxyinnstillinger. Les utdata med påloggingsopplysninger lokalt.

Hvis programmet bruker miljøvariabler for HTTP-proxy, kan en supplerende tjenestekonfigurasjon angi:

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

Bytt ut dokumentasjonseksemplets endepunkt og bruk variabelnavn som programmet støtter. For en tjeneste som har tillatelse til å bruke offentlige HTTP-proxyer, finnes mulige adresser i listen over HTTP-proxyer. En klient med egen konfigurasjon kan ignorere disse verdiene. Bekreft også at dette er den tiltenkte systemtjenesten: En brukertjeneste har en annen tjenestebehandler og et annet miljø; endring av en systemenhet med et lignende navn løser ikke dens problem.

Etter å ha redigert riktig enhet eller supplerende konfigurasjon laster du definisjonene på nytt og starter tjenesten på nytt når arbeidet kan avbrytes:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload alene erstatter ikke miljøet til en kjørende prosess. En omstart starter den nye prosessen; en eksport i skallet påvirker bare det skallet og barneprosessene det starter etterpå.

Når tjenesten mottar den forventede URL-en, følger du den faktiske feilen. Kontoen kan mangle tilgang til CA-filen, nettverksnavnerommet når kanskje ikke lytteren, eller proxyen kan avvise forespørselen. Det er senere kontroller, ikke grunner til å fortsette å redigere uvedkommende skallprofiler.