Wêrom in systemd-tsjinst de proxyynstellingen fan dyn shell net krijt

Set de proxykonfiguraasje yn de eigentlike omjouwing fan de systemd-tsjinst; in eksport yn in terminal feroaret gjin proses dat al rint.

Undersykje de tsjinst dy't mislearret ynstee fan noch in fariabele yn dyn terminal te eksportearjen. systemctl cat example.service lit de unit en oanfoljende konfiguraasjes sjen; sykje nei in EnvironmentFile, oare oerskriuwingen of proxyynstellingen fan de tapassing sels. Lês útfier mei oanmeldgegevens lokaal.

As de tapassing HTTP-proxyomjouwingsfariabelen brûkt, kin in oanfoljende tsjinstkonfiguraasje it folgjende jaan:

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

Ferfang it dokumintaasjefoarbyldadres en brûk de fariabelenammen dy't de tapassing stipet. Foar in tsjinst dy't iepenbiere HTTP-proxy's brûke mei, steane mooglike adressen yn de HTTP-proxylist. In kliïnt mei eigen konfiguraasje kin dizze ynfier negearje. Befêstigje ek dat dit de bedoelde systeemtsjinst is: In brûkerstsjinst hat in oare behearder en omjouwing; in systeemunit mei in ferlykbere namme feroarje lost dat probleem net op.

Laad nei it bewurkjen fan de goede unit of oanfoljende konfiguraasje de definysjes opnij en start de tsjinst opnij as syn wurk ûnderbrutsen wurde mei:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload allinnich ferfangt de omjouwing fan in rinnend proses net. Opnij starten start it nije proses; in eksport yn de shell beynfloedet allinnich dy shell en de bernprosessen dy't dy dêrnei start.

Folgje de eigentlike flater sadree't de tsjinst de ferwachte URL krijt. It akkount kin gjin tagong ta it CA-bestân hawwe, de netwurknammeromte kin de lústerder miskien net berikke of de proxy kin it fersyk wegerje. Dat binne lettere kontrôles, gjin redenen om troch te gean mei it bewurkjen fan net-relatearre shellprofilen.

Relatearre artikelen