Bakit Hindi Nakukuha ng systemd Service ang Proxy Settings ng Iyong Shell

Suriin ang service na pumapalya sa halip na mag-export ng isa pang variable sa terminal. Ipinapakita ng systemctl cat example.service ang unit at mga pandagdag na configuration nito; hanapin ang EnvironmentFile, ibang override, o proxy settings ng application mismo. Basahin nang lokal ang output na may credentials.

Kung gumagamit ang application ng mga environment variable para sa HTTP proxy, maaaring ibigay ng pandagdag na configuration ng service ang sumusunod:

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

Palitan ang endpoint sa halimbawang dokumentasyon at gamitin ang mga pangalan ng variable na sinusuportahan ng application. Para sa service na pinapayagang gumamit ng pampublikong HTTP proxy, may mga posibleng address sa listahan ng HTTP proxy. Maaaring balewalain ng client na may sariling configuration ang mga input na ito. Tiyakin din na ito ang nilalayong system service: Iba ang manager at environment ng user service; hindi ito maaayos sa pagbabago ng system unit na may kahawig na pangalan.

Pagkatapos i-edit ang tamang unit o pandagdag na configuration, i-reload ang mga definition at i-restart ang service na iyon kapag puwedeng maantala ang trabaho nito:

sudo systemctl daemon-reload
sudo systemctl restart example.service

Hindi napapalitan ng daemon-reload lamang ang environment ng prosesong tumatakbo. Ang restart ang nagpapasimula ng bagong proseso; ang export sa shell ay nakaaapekto lamang sa shell na iyon at sa mga child process na ilulunsad nito pagkatapos.

Kapag natanggap na ng service ang inaasahang URL, sundan ang aktuwal nitong error. Maaaring walang access ang account nito sa CA file, hindi maabot ng network namespace nito ang listener, o tanggihan ng proxy ang request. Mga susunod na pagsusuri ang mga ito, hindi dahilan para patuloy na mag-edit ng mga shell profile na walang kaugnayan.