Pourquoi un service systemd ne reprend pas les réglages proxy du shell

Examinez le service en échec plutôt que d’exporter une variable de plus dans votre terminal. systemctl cat example.service affiche son unité et ses fichiers de surcharge ; recherchez un EnvironmentFile, une autre surcharge ou des réglages proxy propres à l’application. Consultez localement les sorties contenant des identifiants.

Si l’application exploite les variables d’environnement du proxy HTTP, un fichier de surcharge du service peut fournir :

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

Remplacez l’adresse de l’exemple et utilisez les noms de variables pris en charge par l’application. Pour un service autorisé à utiliser des proxys HTTP publics, des adresses candidates figurent dans la liste de proxys HTTP. Un client disposant de sa propre configuration peut ignorer ces entrées. Vérifiez aussi qu’il s’agit bien du service système voulu : un service utilisateur a un gestionnaire et un environnement différents ; modifier une unité système portant un nom similaire ne le réparera pas.

Après avoir modifié l’unité ou la surcharge voulue, rechargez les définitions puis redémarrez ce service lorsque son activité peut être interrompue :

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload ne remplace pas à lui seul l’environnement d’un processus en cours. Le redémarrage lance le nouveau processus ; un export dans le shell affecte uniquement ce shell et les processus enfants qu’il lance ensuite.

Une fois que le service reçoit l’URL attendue, suivez son erreur réelle. Son compte peut ne pas avoir accès au fichier CA, son espace de noms réseau peut ne pas atteindre le service d’écoute, ou le proxy peut rejeter la requête. Ce sont des vérifications ultérieures, pas des raisons de continuer à modifier des profils de shell sans rapport.