Kāpēc systemd pakalpojums nesaņem čaulas starpniekservera iestatījumus
Ievietojiet starpniekservera konfigurāciju systemd pakalpojuma faktiskajā vidē; mainīgā eksportēšana terminālī nepārkonfigurē darbojošos procesu.
Pārbaudiet pakalpojumu, kas nedarbojas, nevis eksportējiet terminālī vēl vienu mainīgo. systemctl cat example.service parāda tā vienību un papildu konfigurācijas; meklējiet EnvironmentFile, citus pārrakstījumus vai pašas lietotnes starpniekservera iestatījumus. Izvadi, kurā ir akreditācijas dati, lasiet lokāli.
Ja lietotne izmanto HTTP starpniekservera vides mainīgos, pakalpojuma papildu konfigurācija var norādīt:
[Service]
Environment="HTTP_PROXY=http://203.0.113.10:8080"
Environment="HTTPS_PROXY=http://203.0.113.10:8080"Aizstājiet dokumentācijas parauga adresi un izmantojiet lietotnes atbalstītos mainīgo nosaukumus. Pakalpojumam, kuram atļauts lietot publiskus HTTP starpniekserverus, iespējamās adreses ir HTTP starpniekserveru sarakstā. Klients ar savu konfigurāciju var šīs vērtības ignorēt. Apstipriniet arī, ka tas ir paredzētais sistēmas pakalpojums: Lietotāja pakalpojumam ir cits pārvaldnieks un vide; līdzīgi nosauktas sistēmas vienības maiņa to nesalabos.
Pēc pareizās vienības vai papildu konfigurācijas rediģēšanas pārlādējiet definīcijas un pārstartējiet šo pakalpojumu, kad tā darbu drīkst pārtraukt:
sudo systemctl daemon-reload
sudo systemctl restart example.serviceTikai daemon-reload neaizstāj darbojoša procesa vidi. Pārstartēšana palaiž jauno procesu; eksports čaulā ietekmē tikai šo čaulu un bērnprocesus, ko tā palaiž pēc tam.
Kad pakalpojums saņem paredzēto URL, sekojiet tā faktiskajai kļūdai. Tā kontam var nebūt piekļuves CA failam, tā tīkla vārdtelpa var nesasniegt klausītāju vai starpniekserveris var noraidīt pieprasījumu. Tās ir turpmākas pārbaudes, nevis iemesli turpināt rediģēt nesaistītus čaulas profilus.