Зошто услуга на 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-датотеката, нејзиниот мрежен именски простор може да не стигнува до слушачот или проксито може да го одбива барањето. Тоа се следни проверки, а не причини да продолжите со уредување неповрзани профили на школката.