Чому служба 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-файла, її мережевий простір імен може не діставатися слухача або проксі може відхиляти запит. Це наступні перевірки, а не підстави продовжувати редагувати сторонні профілі оболонки.