რატომ ვერ იღებს 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 ფაილზე წვდომა არ ჰქონდეს, მისმა ქსელურმა სახელთა სივრცემ შეიძლება მსმენელამდე ვერ მიაღწიოს ან პროქსიმ მოთხოვნა უარყოს. ეს შემდგომი შემოწმებებია და არა მიზეზები, რომ შეუსაბამო გარსის პროფილების რედაქტირება გააგრძელოთ.