Perché un servizio systemd non vede le impostazioni proxy della shell
Inserisci la configurazione proxy nell’ambiente effettivo del servizio systemd, senza aspettarti che un export nel terminale riconfiguri un processo attivo.
Esamina il servizio che non funziona invece di esportare un’altra variabile nel terminale. systemctl cat example.service mostra l’unità e i suoi file integrativi; cerca un EnvironmentFile, altre sovrascritture o impostazioni proxy gestite dall’applicazione. Leggi localmente gli output contenenti credenziali.
Se l’applicazione usa le variabili d’ambiente del proxy HTTP, un file integrativo del servizio può fornire:
[Service]
Environment="HTTP_PROXY=http://203.0.113.10:8080"
Environment="HTTPS_PROXY=http://203.0.113.10:8080"Sostituisci l’endpoint di esempio e usa i nomi di variabile supportati dall’applicazione. Per un servizio autorizzato a usare proxy HTTP pubblici, trovi indirizzi candidati nell’elenco dei proxy HTTP. Un client con una configurazione propria può ignorare questi valori. Verifica anche che sia il servizio di sistema desiderato: un servizio utente ha un gestore e un ambiente diversi; modificare un’unità di sistema dal nome simile non lo risolverà.
Dopo aver modificato l’unità o il file integrativo previsto, ricarica le definizioni e riavvia quel servizio quando il suo lavoro può essere interrotto:
sudo systemctl daemon-reload
sudo systemctl restart example.servicedaemon-reload da solo non sostituisce l’ambiente di un processo attivo. Il riavvio avvia il nuovo processo; un export nella shell influisce solo su quella shell e sui processi figli che avvierà in seguito.
Una volta che il servizio riceve l’URL previsto, segui il suo errore effettivo. Il suo account potrebbe non avere accesso al file CA, il suo namespace di rete potrebbe non raggiungere il listener oppure il proxy potrebbe rifiutare la richiesta. Sono controlli successivi, non motivi per continuare a modificare profili della shell estranei al problema.