Zakaj storitev systemd ne dobi nastavitev proxyja iz vaše lupine

Preglejte storitev, ki odpoveduje, namesto da v terminalu izvozite še eno spremenljivko. systemctl cat example.service pokaže njeno enoto in dopolnilne konfiguracije; poiščite EnvironmentFile, druge preglasitve ali lastne nastavitve proxyja v aplikaciji. Izhod s prijavnimi podatki berite lokalno.

Če aplikacija uporablja okoljske spremenljivke za HTTP proxy, lahko dopolnilna konfiguracija storitve poda:

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

Zamenjajte naslov iz dokumentacijskega primera in uporabite imena spremenljivk, ki jih aplikacija podpira. Za storitev, ki sme uporabljati javne HTTP proxyje, so možni naslovi na seznamu HTTP proxyjev. Odjemalec z lastno konfiguracijo lahko te vrednosti prezre. Potrdite tudi, da gre za pravo sistemsko storitev: Uporabniška storitev ima drugega upravljavca in okolje; sprememba podobno poimenovane sistemske enote je ne bo popravila.

Po urejanju prave enote ali dopolnilne konfiguracije znova naložite definicije in ponovno zaženite storitev, ko je njeno delo dovoljeno prekiniti:

sudo systemctl daemon-reload
sudo systemctl restart example.service

Sam daemon-reload ne nadomesti okolja delujočega procesa. Ponovni zagon zažene nov proces; izvoz v lupini vpliva le na to lupino in podrejene procese, ki jih zažene pozneje.

Ko storitev dobi pričakovani URL, sledite njeni dejanski napaki. Njen račun morda nima dostopa do datoteke CA, njen omrežni imenski prostor morda ne doseže poslušalca ali pa proxy zavrne zahtevo. To so nadaljnja preverjanja, ne razlogi za nadaljnje urejanje nepovezanih profilov lupine.