Dlaczego usługa systemd nie otrzymuje ustawień proxy z powłoki

Umieść konfigurację proxy w rzeczywistym środowisku usługi systemd; eksport zmiennej w terminalu nie przekonfiguruje działającego procesu.

Zbadaj usługę, która zawodzi, zamiast eksportować kolejną zmienną w terminalu. systemctl cat example.service pokazuje jej jednostkę i pliki uzupełniające; sprawdź, czy jest EnvironmentFile, inne nadpisanie albo ustawienia proxy samej aplikacji. Wynik zawierający dane uwierzytelniające czytaj lokalnie.

Jeśli aplikacja korzysta ze zmiennych środowiskowych proxy HTTP, plik uzupełniający usługi może podać:

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

Zastąp adres z przykładu dokumentacyjnego i użyj nazw zmiennych obsługiwanych przez aplikację. Dla usługi, która może używać publicznych proxy HTTP, możliwe adresy są na liście proxy HTTP. Klient z własną konfiguracją może ignorować te dane. Potwierdź też, że to właściwa usługa systemowa: usługa użytkownika ma innego menedżera i środowisko; zmiana jednostki systemowej o podobnej nazwie jej nie naprawi.

Po edycji właściwej jednostki lub pliku uzupełniającego wczytaj definicje ponownie i uruchom tę usługę ponownie, gdy jej pracę można przerwać:

sudo systemctl daemon-reload
sudo systemctl restart example.service

Samo daemon-reload nie zastępuje środowiska działającego procesu. Restart uruchamia nowy proces; eksport w powłoce wpływa tylko na tę powłokę i procesy potomne, które uruchomi ona później.

Gdy usługa otrzyma oczekiwany URL, zajmij się jej rzeczywistym błędem. Jej konto może nie mieć dostępu do pliku CA, jej sieciowa przestrzeń nazw może nie docierać do nasłuchu albo proxy może odrzucać żądanie. To kolejne kontrole, a nie powody do dalszego edytowania niezwiązanych profili powłoki.

Powiązane artykuły