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 ಮಾತ್ರ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಯ ಪರಿಸರವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಮರುಪ್ರಾರಂಭ ಹೊಸ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಆರಂಭಿಸುತ್ತದೆ; ಶೆಲ್‌ನ export ಪರಿಣಾಮ ಬೀರುವುದು ಆ ಶೆಲ್ ಮತ್ತು ಅದು ನಂತರ ಆರಂಭಿಸುವ ಮಕ್ಕಳ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಮಾತ್ರ.

ಸೇವೆಗೆ ನಿರೀಕ್ಷಿತ URL ಸಿಕ್ಕ ಬಳಿಕ ಅದರ ನಿಜವಾದ ದೋಷವನ್ನು ಅನುಸರಿಸಿ. ಅದರ ಖಾತೆಗೆ CA ಫೈಲ್‌ಗೆ ಪ್ರವೇಶ ಇಲ್ಲದಿರಬಹುದು, ಅದರ ನೆಟ್‌ವರ್ಕ್ ನೇಮ್‌ಸ್ಪೇಸ್ ಲಿಸನರ್ ತಲುಪದಿರಬಹುದು ಅಥವಾ ಪ್ರಾಕ್ಸಿ ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸಬಹುದು. ಇವು ಮುಂದಿನ ಪರಿಶೀಲನೆಗಳು, ಸಂಬಂಧವಿಲ್ಲದ ಶೆಲ್ ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ಸಂಪಾದಿಸುತ್ತಿರಲು ಕಾರಣಗಳಲ್ಲ.