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