Эмне үчүн 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 файлына кирүү укугу жок болушу мүмкүн, тармактык аттар мейкиндиги угуучуга жетпеши же прокси суроону четке кагышы мүмкүн. Булар кийинки текшерүүлөр, тиешеси жок кабык профилдерин өзгөртө берүүгө себеп эмес.