systemd ဝန်ဆောင်မှုက သင့် shell ၏ proxy ဆက်တင်များကို ဘာကြောင့် မရသနည်း

Terminal တွင် variable တစ်ခု ထပ် export လုပ်မည့်အစား မအောင်မြင်သော ဝန်ဆောင်မှုကို စစ်ပါ။ systemctl cat example.service သည် ၎င်း၏ unit နှင့် ဖြည့်စွက်ပြင်ဆင်ချက်များကို ပြသည်။ EnvironmentFile၊ အခြား override သို့မဟုတ် application ၏ ကိုယ်ပိုင် proxy ဆက်တင် ရှိမရှိ စစ်ပါ။ အကောင့်ဝင်အချက်အလက် ပါသော output ကို စက်ထဲတွင်သာ ဖတ်ပါ။

Application က HTTP proxy environment variable များကို သုံးလျှင် ဝန်ဆောင်မှု၏ ဖြည့်စွက်ပြင်ဆင်ချက်တွင် အောက်ပါတို့ကို ပေးနိုင်သည်။

[Service]
Environment="HTTP_PROXY=http://203.0.113.10:8080"
Environment="HTTPS_PROXY=http://203.0.113.10:8080"

စာရွက်စာတမ်းထဲက နမူနာလိပ်စာကို အစားထိုးပြီး application က ပံ့ပိုးသော variable အမည်များကို သုံးပါ။ အများသုံး HTTP proxy များကို သုံးခွင့်ရှိသည့် ဝန်ဆောင်မှုအတွက် ရွေးချယ်နိုင်သော လိပ်စာများကို HTTP proxy စာရင်းတွင် တွေ့နိုင်သည်။ ကိုယ်ပိုင်ပြင်ဆင်ချက်ရှိသော client သည် ဤ input များကို လျစ်လျူရှုနိုင်သည်။ ရည်ရွယ်ထားသော system service ဖြစ်ကြောင်းလည်း အတည်ပြုပါ။ User service တွင် manager နှင့် environment မတူသောကြောင့် အမည်ဆင်တူ system unit ကို ပြင်ခြင်းက ၎င်းကို မပြုပြင်နိုင်ပါ။

မှန်ကန်သော unit သို့မဟုတ် ဖြည့်စွက်ပြင်ဆင်ချက်ကို ပြင်ပြီးလျှင် definition များကို ပြန်တင်ကာ အလုပ်ဝန်ကို ခေတ္တရပ်နိုင်ချိန်၌ ထိုဝန်ဆောင်မှုကို ပြန်စပါ။

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload တစ်ခုတည်းက လည်ပတ်နေသော process ၏ environment ကို မအစားထိုးပါ။ ပြန်စခြင်းမှ process အသစ်ကို စတင်ပေးသည်။ Shell ထဲက export သည် ထို shell နှင့် နောက်မှ ၎င်းစတင်ပေးသော child process များကိုသာ သက်ရောက်သည်။

ဝန်ဆောင်မှုက မျှော်လင့်ထားသော URL ကို ရသည်နှင့် ၎င်း၏ တကယ့်အမှားကို လိုက်စစ်ပါ။ ၎င်း၏ account သည် CA ဖိုင်ကို ဖတ်ခွင့်မရှိနိုင်၊ network namespace သည် listener သို့ မရောက်နိုင် သို့မဟုတ် proxy က request ကို ငြင်းပယ်နိုင်သည်။ ယင်းတို့သည် နောက်တစ်ဆင့် စစ်ဆေးစရာများဖြစ်ပြီး မဆိုင်သော shell profile များကို ဆက်ပြင်ရန် အကြောင်းရင်းများ မဟုတ်ပါ။