Изучите службу, которая выдаёт ошибку, вместо экспорта очередной переменной в терминале. 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-файлу, её сетевое пространство имён может не достигать слушателя либо прокси может отклонить запрос. Это следующие проверки, а не повод продолжать редактировать посторонние профили оболочки.

Похожие статьи