Por que un servizo systemd non recibe a configuración proxy do shell

Inspeccione o servizo que falla en vez de exportar outra variable no terminal. systemctl cat example.service mostra a súa unidade e configuracións complementarias; busque un EnvironmentFile, outras sobrescrituras ou configuracións proxy propias da aplicación. Lea localmente a saída que conteña credenciais.

Se a aplicación utiliza variables de contorno de proxy HTTP, unha configuración complementaria do servizo pode fornecer:

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

Substitúa o enderezo do exemplo e use os nomes de variable admitidos pola aplicación. Para un servizo autorizado a usar proxies HTTP públicos, hai enderezos candidatos na lista de proxies HTTP. Un cliente con configuración propia pode ignorar estes valores. Confirme tamén que é o servizo de sistema previsto: un servizo de usuario ten outro xestor e contorno; cambiar unha unidade de sistema cun nome semellante non o reparará.

Despois de editar a unidade ou configuración complementaria correcta, volva cargar as definicións e reinicie ese servizo cando se poida interromper o seu traballo:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload por si só non substitúe o contorno dun proceso en execución. O reinicio inicia o proceso novo; exportar unha variable no shell afecta só ese shell e os procesos fillos que inicie despois.

Cando o servizo reciba o URL esperado, siga o seu erro real. A súa conta pode non ter acceso ao ficheiro CA, o seu espazo de nomes de rede pode non alcanzar o punto de escoita ou o proxy pode rexeitar a petición. Son comprobacións posteriores, non motivos para seguir editando perfís de shell alleos ao problema.