Zergatik systemd zerbitzu batek ez dituen zure shellaren proxy-ezarpenak jasotzen

Aztertu huts egiten duen zerbitzua terminalean beste aldagai bat esportatu beharrean. systemctl cat example.service komandoak haren unitatea eta konfigurazio osagarriak erakusten ditu; begiratu ea EnvironmentFile bat, beste gainidazketa bat edo aplikazioaren beraren proxy-ezarpenak dauden. Kredentzialak dituzten irteerak lokalean irakurri.

Aplikazioak HTTP proxyaren ingurune-aldagaiak erabiltzen baditu, zerbitzuaren konfigurazio osagarri batek hauek eman ditzake:

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

Ordeztu dokumentazioko adibide-helbidea eta erabili aplikazioak onartzen dituen aldagai-izenak. HTTP proxy publikoak erabiltzeko baimena duen zerbitzu baterako, helbide hautagaiak HTTP proxyen zerrendan daude. Konfigurazio propioa duen bezero batek sarrera horiek bazter ditzake. Ziurtatu, halaber, nahi duzun sistema-zerbitzua dela: erabiltzaile-zerbitzu batek beste kudeatzaile eta ingurune bat ditu; antzeko izena duen sistema-unitate bat aldatzeak ez du hura konponduko.

Dagokion unitatea edo konfigurazio osagarria editatu ondoren, kargatu berriz definizioak eta berrabiarazi zerbitzu hori haren lana eten daitekeenean:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload komandoak bakarrik ez du martxan dagoen prozesuaren ingurunea ordezten. Berrabiarazteak prozesu berria abiatzen du; shell batean esportatzeak shell horri eta ondoren hark abiarazten dituen prozesu umeei soilik eragiten die.

Zerbitzuak espero den URLa jasotzen duenean, jarraitu haren benetako erroreari. Haren kontuak CA fitxategirako sarbiderik ez izatea gerta daiteke, haren sare-izen eremuak entzulearengana ez iristea edo proxyak eskaera ukatzea. Horiek ondorengo egiaztapenak dira, ez loturarik gabeko shell-profilak editatzen jarraitzeko arrazoiak.