Varför en systemd-tjänst inte får skalets proxyinställningar

Undersök tjänsten som misslyckas i stället för att exportera ännu en variabel i terminalen. systemctl cat example.service visar dess unit och kompletterande konfigurationsfiler; leta efter en EnvironmentFile, andra åsidosättningar eller programmets egna proxyinställningar. Läs utdata som innehåller inloggningsuppgifter lokalt.

Om programmet använder miljövariabler för HTTP-proxy kan en kompletterande tjänstekonfiguration ange:

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

Ersätt dokumentationsexemplets adress och använd variabelnamn som programmet stöder. För en tjänst som får använda publika HTTP-proxyer finns möjliga adresser i listan över HTTP-proxyer. En klient med egen konfiguration kan ignorera dessa indata. Bekräfta också att detta är den avsedda systemtjänsten: En användartjänst har en annan hanterare och miljö; att ändra en system-unit med liknande namn löser inte dess problem.

Efter att ha redigerat avsedd unit eller kompletterande konfiguration laddar du om definitionerna och startar om tjänsten när dess arbete får avbrytas:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload ensamt ersätter inte miljön för en körande process. En omstart startar den nya processen; en export i skalet påverkar bara det skalet och de barnprocesser som det startar därefter.

När tjänsten får den förväntade URL:en följer du det faktiska felet. Dess konto kan sakna åtkomst till CA-filen, dess nätverksnamnrymd kanske inte når lyssnaren eller proxyn kan avvisa begäran. Det är senare kontroller, inte skäl att fortsätta redigera orelaterade skalprofiler.