VPN ಸೇವೆ EXEC ನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ: unit, ಬೈನರಿ ಮತ್ತು sudoers ಹೋಲಿಸಿ
EXEC ಹಂತದಲ್ಲಿ ವಿಫಲತೆ ಎಂದರೆ systemd ಬೈನರಿಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು unit ನ ಮಾರ್ಗ, ಸ್ಥಾಪಿತ ಮಾರ್ಗ ಮತ್ತು sudoers ಅನುಮತಿಯನ್ನು ಹೋಲಿಸಿ.
ನಿನ್ನೆ ಟನಲ್ ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು, ಇಂದು ಬೆಳಿಗ್ಗೆ unit ಸತ್ತಿದೆ, ಜರ್ನಲ್‌ನಲ್ಲಿ Failed at step EXEC spawning /usr/local/bin/vpnclient ಇದೆ. ರುಜುವಾತುಗಳು, ಮಾರ್ಗಗಳು ಮತ್ತು ಖಾತೆ ಆ ವಾಕ್ಯಕ್ಕೆ ಎಂದಿಗೂ ಬರುವುದಿಲ್ಲ. systemd ExecStart ಅನ್ನು ಮಾರ್ಗವಾಗಿ ಪರಿಹರಿಸಿತು, ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕರ್ನಲ್‌ಗೆ ಕೇಳಿತು, ಮತ್ತು ಕರ್ನಲ್ ನಿರಾಕರಿಸಿತು, ಹೆಚ್ಚಾಗಿ ಆ ಮಾರ್ಗದಲ್ಲಿ ಏನೂ ಇಲ್ಲದಿರುವುದರಿಂದ ಅಥವಾ ಫೈಲ್ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಯೋಗ್ಯವಲ್ಲದಿರುವುದರಿಂದ. ವಿಶ್ಲೇಷಿಸಿದ ಆಜ್ಞೆ ವಿರುದ್ಧವಾಗಿ ಸಾಬೀತುಪಡಿಸುವವರೆಗೆ ದೋಷವನ್ನು ಫೈಲ್ ಮತ್ತು argv ಸಮಸ್ಯೆ ಎಂದು ಪರಿಗಣಿಸಿ.
ಪ್ರಮಾಣೀಕರಣ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲೇ EXEC ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ
systemd ExecStart ಅನ್ನು ಶೆಲ್ ಮೂಲಕ ಚಲಾಯಿಸುವುದಿಲ್ಲ. ಅದು fork ಮಾಡುತ್ತದೆ, ಸಾಲಿನಿಂದ ಆರ್ಗ್ಯುಮೆಂಟ್ ವೆಕ್ಟರ್ ನಿರ್ಮಿಸುತ್ತದೆ ಮತ್ತು ಮೊದಲ ಅಂಶದ ಮೇಲೆ execve ಕರೆಯುತ್ತದೆ. ಆ ಕರೆ ವಿಫಲವಾದರೆ, ಸೇವೆ ಎಂದಿಗೂ VPN ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ಕೋಡ್ ತಲುಪುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರೊಫೈಲ್ ಸಂಪಾದನೆ ಅಥವಾ ರುಜುವಾತು ಪರಿಶೀಲನೆ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ.
ಸ್ಥಿತಿ ಕೋಡ್ ಈ ಕುಟುಂಬವನ್ನು ಸಾಮಾನ್ಯ ಕ್ರ್ಯಾಶ್‌ಗಳಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. status=203/EXEC ಜೊತೆ ನಿರ್ಗಮಿಸಿದ unit ಎಂದಿಗೂ ಪ್ರಕ್ರಿಯೆ ಪ್ರಾರಂಭಿಸಿಲ್ಲ; ಪ್ರಾರಂಭವಾಗಿ ನಂತರ status=1 ಜೊತೆ ನಿರ್ಗಮಿಸಿದ unit ಪ್ರಮಾಣೀಕರಣ, DNS ಅಥವಾ ಮಾರ್ಗನಿರ್ದೇಶನದಲ್ಲಿ ವಿಫಲವಾಗಿರಬಹುದು. ಕ್ಲೈಂಟ್ ಲಾಗ್ ಓದುವ ಮೊದಲು ಕೋಡ್ ಓದಿ, ಏಕೆಂದರೆ ಮೊದಲ ಸಂದರ್ಭದಲ್ಲಿ ಕ್ಲೈಂಟ್ ಲಾಗ್ ಖಾಲಿ ಇರುತ್ತದೆ.
ಜರ್ನಲ್‌ನಲ್ಲಿರುವ ಮಾರ್ಗ systemd ಬಳಸಿದ ಮಾರ್ಗ, ನೀವು ಸಂಪಾದಿಸಿದ ಮಾರ್ಗವಲ್ಲ. Drop-in ಫೈಲ್‌ಗಳು ಮತ್ತು ಜನರೇಟರ್ ಔಟ್‌ಪುಟ್ ವೆಂಡರ್ ಫೈಲ್ ಅನ್ನು ಮೀರಿಸಬಹುದು, ಮತ್ತು ಹಳೆಯ daemon-reload ಹಳೆಯ ಸಾಲನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಬಿಡುತ್ತದೆ. ಆದ್ದರಿಂದ ಮೊದಲ ನಿರ್ಣಯ ಎಂದರೆ ನೀವು ಬದಲಿಸಿದ್ದನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳುವ ಫೈಲ್ ತೆರೆಯುವುದಲ್ಲ, systemd ಯಾವ ಆಜ್ಞೆ ಎಂದು ಭಾವಿಸುತ್ತದೆ ಎಂದು ಕೇಳುವುದು.
ಬೈನರಿಯ ಮಾರ್ಗ ಬರೆಯಲಾದ ಮೂರು ಸ್ಥಳಗಳು
ವಿತರಣಾ ಪ್ಯಾಕೇಜ್, ವೆಂಡರ್ ಸ್ಕ್ರಿಪ್ಟ್ ಮತ್ತು ಬಿಡುಗಡೆ tarball ನಿಂದ ಸ್ಥಾಪಿಸಿದ VPN ಕ್ಲೈಂಟ್ ಮೂರು ವಿಭಿನ್ನ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳಲ್ಲಿ ಬಂದು ಸೇರಬಹುದು. unit, ಸವಲತ್ತು ನಿಯಮ ಮತ್ತು ಸ್ಥಾಪಕರು ಇವುಗಳಲ್ಲಿ ಒಂದೊಂದು ಪ್ರಿಫಿಕ್ಸ್ ದಾಖಲಿಸಿದ್ದಾರೆ, ಮತ್ತು ಮೂರರಲ್ಲಿ ಎರಡು ಹೊಂದಿಕೆಯಾಗದಿದ್ದಾಗ ವಿಫಲತೆ ಕಾಣಿಸುತ್ತದೆ.
| Record | Common value | How to read it |
|---|---|---|
| Unit or drop-in | /usr/local/bin/vpnclient | systemctl cat vpnclient.service |
| Installed binary | /usr/bin/vpnclient | command -v vpnclient, then ls -l the result |
| Sudoers grant | /opt/vpnclient/bin/vpnclient | sudo grep -r vpnclient /etc/sudoers.d/ |
ನಿರ್ದಿಷ್ಟ ಅಸಾಂಗತ್ಯ ಹೀಗೆ ಕಾಣುತ್ತದೆ: ವೆಂಡರ್ ಸ್ಕ್ರಿಪ್ಟ್ /usr/local/bin ಗೆ ಸ್ಥಾಪಿಸುತ್ತದೆ, tarball /opt ಅಡಿಯಲ್ಲಿ ತೆರೆಯಲಾಗಿದೆ, ಮತ್ತು unit ಇನ್ನೂ ಹಿಂದಿನ ಪ್ಯಾಕೇಜ್‌ನ ಹಳೆಯ /usr/bin ಮಾರ್ಗವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಆ ಫೈಲ್‌ಗಳಲ್ಲಿ ಒಂದೇ ಇದೆ, ಮತ್ತು ಅದು ಅಪರೂಪವಾಗಿ ExecStart ನಲ್ಲಿರುವ ಫೈಲ್.
ಯಾವುದೇ ಫೈಲ್ ಬದಲಿಸುವ ಮೊದಲು ಯಾವ ಮಾರ್ಗ ಪ್ರಮಾಣಿತ ಎಂದು ನಿರ್ಧರಿಸಿ. ಬೈನರಿ ವಿತರಣಾ ಪ್ಯಾಕೇಜ್‌ಗೆ ಸೇರಿದ್ದರೆ, ಪ್ಯಾಕೇಜ್ ಮಾರ್ಗ ಪ್ರಮಾಣಿತ ಮತ್ತು unit ಅದನ್ನು ಅನುಸರಿಸಬೇಕು. ವೆಂಡರ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗೆ ಸೇರಿದ್ದರೆ, ಅದೇ ನಿಯಮ ವೆಂಡರ್ ಪ್ರಿಫಿಕ್ಸ್‌ಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಪ್ರಿಫಿಕ್ಸ್‌ಗಳ ನಡುವೆ ಬೈನರಿ ನಕಲಿಸುವುದು ಮುಂದಿನ ಅಪ್‌ಗ್ರೇಡ್‌ನಲ್ಲಿ ಬೇರೆಯಾಗುವ ಎರಡು ನಕಲುಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
ಉದ್ಧರಣ ಚಿಹ್ನೆಯಲ್ಲಿರುವ ಆಜ್ಞೆ ಫೈಲ್ ಹೆಸರಾದಾಗ
ಎರಡನೇ ವಿಫಲತೆಯ ಮಾದರಿ ಅದೇ ಜರ್ನಲ್ ಸಾಲಿನ ಹಿಂದೆ ಅಡಗಿದೆ. ಯಾರೋ ಇದನ್ನು unit ಗೆ ಬರೆಯುತ್ತಾರೆ ಮತ್ತು ಬೂಟ್ ಸಮಯದಲ್ಲಿ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸುತ್ತಾರೆ:
ExecStart=/usr/bin/"vpnclient connect office"systemd ಮೌಲ್ಯವನ್ನು ಪದಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೊದಲ ಪದ /usr/bin/vpnclient connect office ಆಗುತ್ತದೆ, ಮತ್ತು ಉದ್ಧರಣ ಚಿಹ್ನೆಗಳು ಗುಂಪು ಮಾಡುವ ವಾಕ್ಯರಚನೆಯಾಗಿ ತೆಗೆದುಹಾಕಲ್ಪಡುತ್ತವೆ. ನಂತರ ಕರ್ನಲ್ ಹೆಸರಿನಲ್ಲಿ ಜಾಗಗಳಿರುವ ಫೈಲ್ ಹುಡುಕುತ್ತದೆ, ಅಂತಹ ಫೈಲ್ ಇಲ್ಲ. ಬೈನರಿ ಸ್ಥಾಪಿತವಾಗಿದ್ದರೂ ದೋಷ ಕಾಣೆಯಾದ ಬೈನರಿಯಂತೆಯೇ ಇದೆ.
ಬೆಂಬಲಿತ ರೂಪ ಎಂದರೆ ನಿಜವಾದ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಫೈಲ್, ನಂತರ ಪ್ರತ್ಯೇಕ ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳು, ಉದಾಹರಣೆಗೆ ExecStart=/usr/bin/vpnclient connect office. ಕೆಲಸದ ಹರಿವಿಗೆ ನಿಜವಾಗಿಯೂ ಪೈಪ್‌ಲೈನ್ ಅಥವಾ ಸರಪಳಿ ಬೇಕಿದ್ದರೆ, ಅದನ್ನು ಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್ ಕರೆಯಿರಿ, ಏಕೆಂದರೆ ExecStart ನಲ್ಲಿ && ಇಲ್ಲ, ಪೈಪ್‌ಗಳಿಲ್ಲ ಮತ್ತು glob ವಿಸ್ತರಣೆ ಇಲ್ಲ.
ಫೈಲ್‌ಸಿಸ್ಟಮ್ ಅಲ್ಲ, unit ಸರಿಪಡಿಸಿ
ಪ್ರಲೋಭನೆಯ ಪರಿಹಾರ ಎಂದರೆ ನಿರೀಕ್ಷಿತ ಮಾರ್ಗದಿಂದ ನಿಜವಾದ ಬೈನರಿಗೆ ಸಾಂಕೇತಿಕ ಕೊಂಡಿ. ಪ್ಯಾಕೇಜ್ ನವೀಕರಣಗೊಂಡು ಕೊಂಡಿ ತೆಗೆದುಹಾಕಿದ ಫೈಲ್‌ಗೆ ತೋರಿಸುವವರೆಗೆ, ಅಥವಾ SELinux ಲೇಬಲ್ ಗುರಿಗೆ ಹೊಂದಿಕೆಯಾಗದವರೆಗೆ ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ. unit ಅನ್ನು drop-in ಮೂಲಕ ಸಂಪಾದಿಸುವುದು ಉತ್ತಮ, ಆಗ ವೆಂಡರ್ ಫೈಲ್ ಮುಟ್ಟದೆ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಅಪ್‌ಗ್ರೇಡ್‌ಗಳು ಊಹಿಸಬಹುದಾದವಾಗಿರುತ್ತವೆ.
ಸವಲತ್ತು ನಿಯಮ ಅದೇ ಮಾರ್ಗ ಮತ್ತು ಅದೇ ಉಪ-ಆಜ್ಞೆಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು. /usr/local/bin/vpnclient ಗಾಗಿ sudoers ನಮೂದು /usr/bin/vpnclient ಅನ್ನು ಅಧಿಕೃತಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಪ್ರತಿ ಆರ್ಗ್ಯುಮೆಂಟ್ ಅನ್ನು ಅನುಮತಿಸುವ ನಮೂದು ಯಾವುದೇ ಸ್ಥಳೀಯ ಪ್ರಕ್ರಿಯೆಗೆ ಟನಲ್ ಅನ್ನು ಮರುಸಂರಚಿಸಲು ಅಥವಾ ನಿಲ್ಲಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ. unit ಗೆ ಅಗತ್ಯವಿರುವ ಎರಡು ಕ್ರಿಯೆಗಳನ್ನು ನೀಡಿ ಮತ್ತು ಸೇವೆ ನಿಲ್ಲಿಸುವುದರಿಂದ ಇಂಟರ್ಫೇಸ್ ಈಗಾಗಲೇ ಮುಚ್ಚುತ್ತಿದ್ದರೆ ವಿಸರ್ಜನೆಯನ್ನು ಅದರ ಹೊರಗೆ ಇರಿಸಿ.
ಇಲ್ಲಿ ಹೋಲಿಕೆ ಫಲ ನೀಡುತ್ತದೆ: unit, ಪ್ಯಾಕೇಜ್ ಡೇಟಾಬೇಸ್ ಮತ್ತು sudoers ಎಲ್ಲವೂ ಒಂದೇ ಮಾರ್ಗವನ್ನು ಹೆಸರಿಸಬೇಕು. ಹಾಗಾದಾಗ, ಮರುಬೂಟ್ ಇಲ್ಲದೆ ಮತ್ತು ಮೂರನೇ ಸ್ಥಳದಲ್ಲಿ ಬೈನರಿಯ ನಕಲು ಇಲ್ಲದೆ EXEC ದೋಷ ಮಾಯವಾಗುತ್ತದೆ.
ಮರುಬೂಟ್‌ಗೆ ಮೊದಲು ವಿಶ್ಲೇಷಿಸಿದ ಆಜ್ಞೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಿ
sudo systemctl daemon-reload
sudo systemctl cat vpnclient.service
systemctl show -p ExecStart vpnclient.service
systemd-analyze verify /etc/systemd/system/vpnclient.service
sudo systemctl restart vpnclient.service
systemctl status vpnclient.service --no-pagersystemctl show ನಿರ್ಣಾಯಕ ಔಟ್‌ಪುಟ್, ಏಕೆಂದರೆ systemd ನಿಜವಾಗಿ ವಿಶ್ಲೇಷಿಸಿದ argv ಅನ್ನು, ಯಾವುದೇ drop-in ಸಹಿತ ಮುದ್ರಿಸುತ್ತದೆ. systemd-analyze verify ನೀವು ಮರುಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಕಾಣೆಯಾದ ಅಥವಾ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗದ ಮಾರ್ಗವನ್ನು ಹಿಡಿಯುತ್ತದೆ, ಮತ್ತು ಮರುಪ್ರಾರಂಭದ ನಂತರದ status ಆಜ್ಞೆ ಪ್ರಕ್ರಿಯೆ ಈಗ ಇದೆಯೇ ಎಂದು ತಿಳಿಸುತ್ತದೆ.
unit ಪ್ರಾರಂಭವಾಗಿ ನಂತರ ವಿಫಲವಾದರೆ, ನೀವು EXEC ಕುಟುಂಬ ಬಿಟ್ಟು ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ದೋಷ ನಿರ್ವಹಣೆಗೆ ಪ್ರವೇಶಿಸಿದ್ದೀರಿ. ಜರ್ನಲ್‌ನಲ್ಲಿ ಕ್ಲೈಂಟ್‌ನ ಸಂದೇಶವನ್ನು ಹುಡುಕಿ, ಇನ್ನೊಂದು execve ವಿಫಲತೆಯನ್ನಲ್ಲ. unit diff ಮತ್ತು sudoers diff ಅನ್ನು ಬದಲಾವಣೆ ದಾಖಲೆಯಲ್ಲಿ ಒಟ್ಟಿಗೆ ಇರಿಸಿ, ಮುಂದಿನ ಅಪ್‌ಗ್ರೇಡ್ ವಿಭಜಿತ ಮಾರ್ಗವನ್ನು ಮೌನವಾಗಿ ಮರಳಿ ತರದಂತೆ.