Ինչու 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 ֆայլը, ցանցային անվանատարածքը կարող է չհասնել լսող կետին, կամ պրոքսին կարող է մերժել հարցումը։ Սրանք հաջորդ ստուգումներն են, ոչ թե անկապ հրամանային պրոֆիլները շարունակաբար խմբագրելու պատճառներ։