Kvifor ei systemd-teneste ikkje får proxyinnstillingane frå skalet

Undersøk tenesta som feilar i staden for å eksportera endå ein variabel i terminalen. systemctl cat example.service viser eininga og tilleggsfilene; sjå etter ei EnvironmentFile, andre overstyringar eller proxyinnstillingar i sjølve programmet. Les utdata med påloggingsopplysningar lokalt.

Dersom programmet nyttar miljøvariablar for HTTP-proxy, kan ei tilleggsfil for tenesta gje:

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

Byt ut endepunktet frå dokumentasjonseksempelet og bruk variabelnamna programmet støttar. For ei teneste som har lov til å nytta offentlege HTTP-proxyar, finst moglege adresser i lista over HTTP-proxyar. Ein klient med eige oppsett kan ignorera desse verdiane. Stadfest òg at dette er den rette systemtenesta: Ei brukarteneste har ein annan tenestehandsamar og eit anna miljø; endring av ei systemeining med liknande namn løyser ikkje problemet hennar.

Etter å ha redigert rett eining eller tilleggsfil lastar du definisjonane på nytt og startar tenesta på nytt når arbeidet kan avbrytast:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload åleine byter ikkje ut miljøet til ein prosess som køyrer. Omstarten startar den nye prosessen; ein eksport i skalet påverkar berre dette skalet og barneprosessane det startar etterpå.

Når tenesta får den venta URL-en, følgjer du den faktiske feilen. Kontoen hennar kan mangla tilgang til CA-fila, nettverksnamnerommet når kanskje ikkje lyttaren, eller proxyen kan avvisa førespurnaden. Dette er seinare kontrollar, ikkje grunnar til å halda fram med å redigera uvedkomande skalprofilar.