Per què un servei systemd no rep la configuració de servidor intermediari del shell

Inspeccioneu el servei que falla en lloc d'exportar una altra variable al terminal. systemctl cat example.service mostra la unitat i les configuracions complementàries; cerqueu un EnvironmentFile, altres sobreescriptures o configuracions de servidor intermediari pròpies de l'aplicació. Llegiu localment les sortides que continguin credencials.

Si l'aplicació utilitza variables d'entorn de servidor intermediari HTTP, una configuració complementària del servei pot proporcionar:

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

Substituïu l'adreça d'exemple i feu servir els noms de variable que admet l'aplicació. Per a un servei autoritzat a utilitzar servidors intermediaris HTTP públics, hi ha adreces candidates a la llista de servidors intermediaris HTTP. Un client amb configuració pròpia pot ignorar aquests valors. Confirmeu també que és el servei de sistema previst: un servei d'usuari té un gestor i un entorn diferents; modificar una unitat de sistema amb un nom semblant no el repararà.

Després d'editar la unitat o la configuració complementària adequada, torneu a carregar les definicions i reinicieu el servei quan se'n pugui interrompre la feina:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload per si sol no substitueix l'entorn d'un procés en execució. El reinici inicia el procés nou; exportar una variable al shell afecta només aquell shell i els processos fills que iniciï posteriorment.

Quan el servei rebi l'URL esperat, seguiu l'error real. El seu compte pot no tenir accés al fitxer CA, el seu espai de noms de xarxa pot no arribar al punt d'escolta o el servidor intermediari pot rebutjar la petició. Són comprovacions posteriors, no motius per continuar editant perfils de shell aliens al problema.