Waarom een systemd-service de proxyinstellingen van je shell niet meekrijgt

Onderzoek de service die faalt in plaats van nog een variabele in je terminal te exporteren. systemctl cat example.service toont de unit en de aanvullende configuratiebestanden; zoek naar een EnvironmentFile, andere overschrijvingen of proxyinstellingen van de toepassing zelf. Lees uitvoer met aanmeldgegevens lokaal.

Als de toepassing HTTP-proxyomgevingsvariabelen gebruikt, kan een aanvullend configuratiebestand voor de service het volgende leveren:

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

Vervang het documentatie-eindpunt en gebruik de variabelenamen die de toepassing ondersteunt. Voor een service die openbare HTTP-proxy's mag gebruiken, staan mogelijke adressen in de HTTP-proxylijst. Een client met eigen configuratie kan deze invoer negeren. Controleer ook of dit de bedoelde systeemservice is: een gebruikersservice heeft een andere manager en omgeving; een gelijknamige of vergelijkbaar genoemde systeemunit wijzigen verhelpt dat probleem niet.

Laad na het bewerken van de bedoelde unit of aanvullende configuratie de definities opnieuw en herstart die service zodra het werk onderbroken mag worden:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload alleen vervangt de omgeving van een actief proces niet. Een herstart start het nieuwe proces; een shell-export beïnvloedt alleen die shell en de kindprocessen die deze daarna start.

Volg de werkelijke fout zodra de service de verwachte URL krijgt. Het account heeft mogelijk geen toegang tot het CA-bestand, de netwerknamespace kan de listener niet bereiken of de proxy weigert het verzoek. Dat zijn vervolgstappen, geen redenen om ongerelateerde shellprofielen te blijven bewerken.