Hvorfor en systemd-tjeneste ikke får shellens proxyindstillinger

Undersøg den tjeneste, der fejler, i stedet for at eksportere endnu en variabel i terminalen. systemctl cat example.service viser dens unit og supplerende konfigurationer; se efter en EnvironmentFile, andre tilsidesættelser eller programmets egne proxyindstillinger. Læs output med legitimationsoplysninger lokalt.

Hvis programmet bruger miljøvariabler til HTTP-proxy, kan en supplerende tjenestekonfiguration angive:

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

Udskift dokumentationseksemplets adresse, og brug de variabelnavne, programmet understøtter. For en tjeneste, der må bruge offentlige HTTP-proxyer, findes mulige adresser på listen over HTTP-proxyer. En klient med egen konfiguration kan ignorere disse input. Bekræft også, at dette er den ønskede systemtjeneste: En brugertjeneste har en anden manager og et andet miljø; ændring af en system-unit med et lignende navn løser ikke dens problem.

Efter redigering af den ønskede unit eller supplerende konfiguration skal du genindlæse definitionerne og genstarte tjenesten, når dens arbejde kan afbrydes:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload alene erstatter ikke en kørende proces' miljø. En genstart starter den nye proces; en eksport i shellen påvirker kun den shell og de underprocesser, den efterfølgende starter.

Når tjenesten modtager den forventede URL, skal du følge den faktiske fejl. Dens konto kan mangle adgang til CA-filen, dens netværksnamespace kan være ude af stand til at nå lytteren, eller proxyen kan afvise forespørgslen. Det er senere kontroller, ikke grunde til at fortsætte med at redigere uvedkommende shellprofiler.