Чаму служба systemd не атрымлівае налады проксі з вашай абалонкі

Даследуйце службу, якая дае збой, замест экспарту чарговай зменнай у тэрмінале. systemctl cat example.service паказвае яе юніт і дадатковыя файлы налад; праверце наяўнасць EnvironmentFile, іншых перавызначэнняў або ўласных налад проксі праграмы. Вывад з уліковымі данымі праглядайце лакальна.

Калі праграма выкарыстоўвае зменныя асяроддзя HTTP-проксі, дадатковы файл налад службы можа задаць:

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

Замяніце адрас з дакументацыйнага прыкладу і выкарыстоўвайце назвы зменных, якія падтрымлівае праграма. Для службы, якой дазволена карыстацца агульнадаступнымі HTTP-проксі, магчымыя адрасы ёсць у спісе HTTP-проксі. Кліент з уласнай канфігурацыяй можа ігнараваць гэтыя значэнні. Таксама пераканайцеся, што гэта патрэбная сістэмная служба: у карыстальніцкай службы іншы менеджар і асяроддзе; змена сістэмнага юніта з падобнай назвай яе не выправіць.

Пасля рэдагавання патрэбнага юніта або дадатковага файла перачытайце азначэнні і перазапусціце службу, калі яе працу можна перапыніць:

sudo systemctl daemon-reload
sudo systemctl restart example.service

Адзін толькі daemon-reload не замяняе асяроддзе працэсу, які працуе. Перазапуск запускае новы працэс; экспарт у абалонцы ўплывае толькі на гэтую абалонку і даччыныя працэсы, якія яна запусціць пасля гэтага.

Калі служба атрымае чаканы URL, разбірайце яе сапраўдную памылку. Яе ўліковы запіс можа не мець доступу да CA-файла, яе сеткавая прастора імёнаў можа не дасягаць слухача або проксі можа адхіляць запыт. Гэта наступныя праверкі, а не прычына далей рэдагаваць не звязаныя з гэтым профілі абалонкі.