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