systemd ସେବା ଆପଣଙ୍କ ଶେଲ୍ର ପ୍ରକ୍ସି ସେଟିଂ କାହିଁକି ପାଏ ନାହିଁ
ପ୍ରକ୍ସି ବିନ୍ୟାସ systemd ସେବାର ପ୍ରକୃତ ପରିବେଶରେ ରଖନ୍ତୁ; ଟର୍ମିନାଲ୍ରେ export କଲେ ଚାଲୁଥିବା ପ୍ରକ୍ରିୟା ପୁନଃବିନ୍ୟାସ ହୁଏ ନାହିଁ।
ଟର୍ମିନାଲ୍ରେ ଆଉ ଏକ ଚଳ ଏକ୍ସପୋର୍ଟ କରିବା ବଦଳରେ ବିଫଳ ହେଉଥିବା ସେବା ଯାଞ୍ଚ କରନ୍ତୁ। 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 ଚାଲୁଥିବା ପ୍ରକ୍ରିୟାର ପରିବେଶ ବଦଳାଏ ନାହିଁ। ପୁନଃଆରମ୍ଭ ନୂଆ ପ୍ରକ୍ରିୟା ଆରମ୍ଭ କରେ; ଶେଲ୍ରେ export ପ୍ରଭାବ ପକାଏ କେବଳ ସେହି ଶେଲ୍ ଓ ପରେ ତାହା ଆରମ୍ଭ କରୁଥିବା ଚାଇଲ୍ଡ ପ୍ରକ୍ରିୟାଗୁଡ଼ିକ ଉପରେ।
ସେବା ଆଶାକରା URL ପାଇବା ପରେ ତାହାର ପ୍ରକୃତ ତ୍ରୁଟି ଅନୁସରଣ କରନ୍ତୁ। ତାହାର ଖାତାର CA ଫାଇଲ୍ ପ୍ରବେଶାଧିକାର ନ ଥାଇପାରେ, ତାହାର ନେଟୱର୍କ ନେମସ୍ପେସ୍ ଲିସନର୍ ପାଖରେ ପହଞ୍ଚି ନ ପାରେ କିମ୍ବା ପ୍ରକ୍ସି ଅନୁରୋଧ ପ୍ରତ୍ୟାଖ୍ୟାନ କରିପାରେ। ଏଗୁଡ଼ିକ ପରବର୍ତ୍ତୀ ଯାଞ୍ଚ, ଅସମ୍ବନ୍ଧିତ ଶେଲ୍ ପ୍ରୋଫାଇଲ୍ ସମ୍ପାଦନା କରିଚାଲିବାର କାରଣ ନୁହେଁ।