Warum ein systemd-Dienst die Proxy-Einstellungen Ihrer Shell nicht übernimmt

Untersuchen Sie den fehlschlagenden Dienst, statt im Terminal eine weitere Variable zu exportieren. systemctl cat example.service zeigt seine Unit und Drop-ins; prüfen Sie auf eine EnvironmentFile, andere Überschreibungen oder anwendungseigene Proxy-Einstellungen. Lesen Sie Ausgaben mit Zugangsdaten nur lokal.

Wenn die Anwendung HTTP-Proxy-Umgebungsvariablen auswertet, kann ein Drop-in für den Dienst Folgendes bereitstellen:

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

Ersetzen Sie den Dokumentationsendpunkt und verwenden Sie die von der Anwendung unterstützten Variablennamen. Für einen Dienst, der öffentliche HTTP-Proxys nutzen darf, finden sich mögliche Adressen in der HTTP-Proxy-Liste. Ein Client mit eigener Konfiguration kann diese Eingaben ignorieren. Prüfen Sie außerdem, ob dies der beabsichtigte Systemdienst ist: Ein Benutzerdienst hat einen anderen Manager und eine andere Umgebung; Änderungen an einer ähnlich benannten System-Unit beheben dessen Problem nicht.

Laden Sie nach dem Bearbeiten der gewünschten Unit oder des Drop-ins die Definitionen neu und starten Sie den Dienst neu, sobald seine Arbeit unterbrochen werden darf:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload allein ersetzt nicht die Umgebung eines laufenden Prozesses. Der Neustart startet den neuen Prozess; ein Shell-Export wirkt sich nur auf diese Shell und die danach von ihr gestarteten Kindprozesse aus.

Sobald der Dienst die erwartete URL erhält, gehen Sie seinem tatsächlichen Fehler nach. Sein Konto hat möglicherweise keinen Zugriff auf die CA-Datei, sein Netzwerk-Namespace erreicht den Listener nicht oder der Proxy lehnt die Anfrage ab. Das sind nachgelagerte Prüfungen und kein Grund, weiterhin unbeteiligte Shell-Profile zu bearbeiten.