De ce un serviciu systemd nu primește setările proxy din shell

Examinați serviciul care eșuează în loc să exportați încă o variabilă în terminal. systemctl cat example.service arată unitatea și configurațiile sale suplimentare; verificați dacă există un EnvironmentFile, alte suprascrieri sau setări proxy proprii aplicației. Citiți local ieșirea care conține date de autentificare.

Dacă aplicația folosește variabile de mediu pentru proxy HTTP, o configurație suplimentară a serviciului poate furniza:

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

Înlocuiți adresa din exemplul de documentație și folosiți numele de variabile acceptate de aplicație. Pentru un serviciu care are voie să utilizeze proxy-uri HTTP publice, găsiți adrese candidate în lista de proxy-uri HTTP. Un client cu configurație proprie poate ignora aceste valori. Confirmați și că acesta este serviciul de sistem dorit: Un serviciu de utilizator are alt manager și alt mediu; modificarea unei unități de sistem cu nume asemănător nu îl va repara.

După editarea unității sau configurației suplimentare corecte, reîncărcați definițiile și reporniți acel serviciu când activitatea lui poate fi întreruptă:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload singur nu înlocuiește mediul unui proces aflat în execuție. Repornirea pornește noul proces; un export în shell afectează doar acel shell și procesele copil pe care le lansează ulterior.

Odată ce serviciul primește URL-ul așteptat, urmăriți eroarea reală. Contul lui poate să nu aibă acces la fișierul CA, spațiul lui de nume de rețea poate să nu ajungă la listener sau proxy-ul poate respinge cererea. Acestea sunt verificări ulterioare, nu motive să continuați editarea profilurilor shell fără legătură cu problema.