Pi ನಲ್ಲಿ VPN ಕ್ಲೈಂಟ್ segfault? ಮೊದಲು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ

ನೀವು ಕ್ಲೈಂಟ್ ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ, ಟರ್ಮಿನಲ್ Segmentation fault (core dumped) ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ಗಂಟೆ ಕಾರ್ಡ್ ಮತ್ತೆ ಬರೆಯುವುದರಲ್ಲಿ ಕಳೆಯುತ್ತದೆ. ಆ ಸಂದೇಶವು ಒಂದು ಪ್ರಕ್ರಿಯೆ ಒಂದು ಕ್ಷಣದಲ್ಲಿ ಹೇಗೆ ಸತ್ತಿತು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ಅದು ಬೋರ್ಡ್ ಹಾನಿಗೊಳಗಾಗಿದೆ ಎಂದು ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ವಿದ್ಯುತ್ ಸರಬರಾಜು, ಸಂಗ್ರಹಣೆ ಅಥವಾ ಇಮೇಜ್ ಅನ್ನು ಸಹ ನಿರ್ದೋಷೀಕರಿಸುವುದಿಲ್ಲ.

ಶೆಲ್ ಮುದ್ರಿಸಿದ ಸಾಲಿನಿಂದ ಅದರ ಹಿಂದಿನ ಪ್ರಕ್ರಿಯೆಯತ್ತ ಕೆಲಸ ಮಾಡಿ. ಉಪಯುಕ್ತ ಸಂಗತಿಗಳೆಂದರೆ ಯಾವ ಎಕ್ಸಿಕ್ಯೂಟೆಬಲ್ ವಿಫಲವಾಯಿತು, ಯಾವ ಪರಿಸರದಲ್ಲಿ ಮತ್ತು ಸಂಪರ್ಕದ ಯಾವ ಹಂತದಲ್ಲಿ.

ಶೆಲ್ ಮುದ್ರಿಸಿದ ಸಾಲಿನಿಂದ ಪ್ರಾರಂಭಿಸಿ

ನಿಮ್ಮ ಆದೇಶದಲ್ಲಿನ ಹೆಸರು ಹೆಚ್ಚಾಗಿ ಮತ್ತೊಂದು ಬೈನರಿಯನ್ನು ಪ್ರಾರಂಭಿಸುವ ರ್ಯಾಪರ್ ಅಥವಾ ಲಾಂಚರ್ ಆಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಕರ್ನಲ್ ನಿಜವಾಗಿ ಯಾವ ಎಕ್ಸಿಕ್ಯೂಟೆಬಲ್ ಅನ್ನು ಕೊನೆಗೊಳಿಸಿತು ಎಂದು ದೃಢೀಕರಿಸಿ. ಪೂರ್ಣ ಪಥ, ಪ್ಯಾಕೇಜ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಆವೃತ್ತಿ, ಆರ್ಕಿಟೆಕ್ಚರ್, OS ಮತ್ತು ಕರ್ನಲ್ ಬಿಡುಗಡೆ, ಅದನ್ನು ಪ್ರಾರಂಭಿಸಿದ ಖಾತೆ ಮತ್ತು ನಿಖರ ಸಮಯವನ್ನು ಬರೆಯಿರಿ. VPN ಹೆಸರಿನ ಶೆಲ್ ಆದೇಶವು ಸಹಾಯಕ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸುಲಭವಾಗಿ ಪ್ರಾರಂಭಿಸಬಹುದು, ಮತ್ತು ದಾಖಲೆಯು ಆ ಸಹಾಯಕನನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಕಳೆದ ತಿಂಗಳು ಸ್ಥಾಪಿಸಿದ ಪ್ಯಾಕೇಜ್‌ನ ಆವೃತ್ತಿ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ನಕಲಿಸುವುದು ಏನು ಚಲಿಸಿತು ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಕ್ರ್ಯಾಶ್‌ನ ಮೊದಲು ನೇರವಾಗಿ ಏನಾಯಿತು ಎಂಬುದನ್ನು ಗಮನಿಸಿ: ಪ್ರಾರಂಭ, ಪ್ರೊಫೈಲ್ ಪಾರ್ಸಿಂಗ್, ದೃಢೀಕರಣ, ಅಥವಾ ಈಗಾಗಲೇ ಸಂಚಾರವನ್ನು ಹಾದುಹೋಗುತ್ತಿದ್ದ ಸೆಷನ್. ಆ ನಾಲ್ಕು ಹಂತಗಳು segfault ಪದಕ್ಕಿಂತ ಹೆಚ್ಚು ಹುಡುಕಾಟವನ್ನು ಸಂಕುಚಿತಗೊಳಿಸುತ್ತವೆ. ಆ ಘಟನೆಯ ಸುತ್ತಲಿನ ಸಣ್ಣ ಲಾಗ್ ವಿಂಡೋವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ, ಮತ್ತು ದಾಖಲೆ ಹೇಳುವವರೆಗೆ ಯಾವ ಇತ್ತೀಚಿನ ಬದಲಾವಣೆ ಅದನ್ನು ಉಂಟುಮಾಡಿತು ಎಂಬ ಊಹೆಗಳನ್ನು ಬದಿಗಿಡಿ.

ಮೆಮೊರಿ ಇಮೇಜ್ ಇದೆಯೇ ಎಂದು ತಿಳಿಯಿರಿ

core ಫೈಲ್ ಉಲ್ಲೇಖ ಡಂಪ್ ಅನ್ನು ಅಂತ್ಯದಲ್ಲಿ ಬರೆಯಲಾದ ಪ್ರಕ್ರಿಯೆ-ಮೆಮೊರಿಯ ಇಮೇಜ್ ಎಂದು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಬರವಣಿಗೆಯನ್ನು ತಡೆಯುವ ಷರತ್ತುಗಳನ್ನೂ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ಆ ಷರತ್ತುಗಳಲ್ಲಿ ಶೂನ್ಯ ಸಂಪನ್ಮೂಲ ಮಿತಿ ಮತ್ತು ಡಂಪ್ ಅನ್ನು ಕೆಲಸದ ಡೈರೆಕ್ಟರಿಯ ಹೊರಗೆ ಕಳುಹಿಸುವ core ಮಾದರಿ ಸೇರಿವೆ. ಆದ್ದರಿಂದ core ಎಂಬ ಫೈಲ್ ಇಲ್ಲದಿರುವುದು ಕ್ರ್ಯಾಶ್ ಸಂಭವಿಸಿತೇ ಇಲ್ಲವೇ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಸಿಸ್ಟಂ ಯಾವುದೇ ಸಾಕ್ಷ್ಯವನ್ನು ಉತ್ಪಾದಿಸಲಿಲ್ಲ ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಸಂರಚಿತ ಮಾದರಿ ಮತ್ತು ಮಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ.

systemd ನ ಸಂಗ್ರಾಹಕವನ್ನು ಬಳಸುವ ಸಿಸ್ಟಂನಲ್ಲಿ, ಬೆಂಬಲಿತ ನೋಟವು ಸಂಗ್ರಹಿತ ದಾಖಲೆಯನ್ನು ಎಕ್ಸಿಕ್ಯೂಟೆಬಲ್ ಮತ್ತು ಸಮಯದೊಂದಿಗೆ ಪರಸ್ಪರ ಸಂಬಂಧಿಸುತ್ತದೆ. ಜರ್ನಲ್ ನಮೂದು ಮತ್ತು ಓದಬಹುದಾದ ಮೆಮೊರಿ ಇಮೇಜ್ ಎರಡು ವಿಭಿನ್ನ ಕಲಾಕೃತಿಗಳು: ಧಾರಣ ನೀತಿ ಮತ್ತು ಅನುಮತಿಗಳು ಒಂದನ್ನು ಇನ್ನೊಂದಿಲ್ಲದೆ ಬಿಡಬಹುದು. ವಿತರಣೆ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ವಾಹಕರನ್ನು ಅವರು ಬೆಂಬಲಿಸುವ ರೋಗನಿರ್ಣಯ ಕಾರ್ಯಪ್ರವಾಹದ ಬಗ್ಗೆ ಕೇಳಿ, ಏಕೆಂದರೆ ಬೇರೆ ಬಿಲ್ಡ್ ಅಥವಾ ಬೇರೆ ಲೈಬ್ರರಿ ಗುಂಪಿನಿಂದ ತಯಾರಿಸಿದ ಟ್ರೇಸ್ ಸಾಮಾನ್ಯವಾಗಿ ಅವರ ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.

sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn

ಆ ಓದುವಿಕೆಗಳನ್ನು ನಿಜವಾಗಿ ಕ್ರ್ಯಾಶ್ ಆದ ಯಂತ್ರದಲ್ಲಿ ಪುನರಾವರ್ತಿಸಿ. ಹೊಸ ಸ್ಥಾಪನೆಯಲ್ಲಿ ಮಾಡುವುದು ಯಾರೂ ಕೇಳದ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ.

ಡಂಪ್ ಅನ್ನು ರಹಸ್ಯಗಳನ್ನು ಹೊತ್ತ ವಸ್ತುವೆಂದು ಪರಿಗಣಿಸಿ

ಪ್ರಕ್ರಿಯೆ-ಮೆಮೊರಿಯಲ್ಲಿ ರುಜುವಾತುಗಳು, ಸೆಷನ್ ಕೀಗಳು ಮತ್ತು ಪ್ರೊಫೈಲ್ ವಿಷಯಗಳು ಇರಬಹುದು, ಇದು ಡಂಪ್ ಅನ್ನು ಪಕ್ಕದ ಪಠ್ಯ ಲಾಗ್‌ಗಿಂತ ಹೆಚ್ಚು ಸೂಕ್ಷ್ಮವಾಗಿಸುತ್ತದೆ. ಲಾಗ್ ಅನ್ನು ಸಂಪಾದಿಸುವುದು ಅಪಾರದರ್ಶಕ ಮೆಮೊರಿ ಇಮೇಜ್‌ಗೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಸಾಮಾನ್ಯ issue ಟ್ರ್ಯಾಕರ್‌ಗಳು ಬೆಂಬಲದ ಥ್ರೆಡ್ ಇರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ಲಗತ್ತುಗಳನ್ನು ಇಡುತ್ತವೆ. ಫೈಲ್ ಅನ್ನು ಮಾರಾಟಗಾರ ಅಥವಾ ನಿರ್ವಾಹಕ ಒದಗಿಸುವ ಖಾಸಗಿ ಚಾನಲ್ ಮೂಲಕ ಸರಿಸಿ. ಸಾರ್ವಜನಿಕ issue ನಲ್ಲಿ ಕಚ್ಚಾ ಡಂಪ್ ಪೋಸ್ಟ್ ಮಾಡುವುದು ಪ್ರಕ್ರಿಯೆ ಸತ್ತಾಗ ಮೆಮೊರಿಯಲ್ಲಿದ್ದ ಎಲ್ಲವನ್ನೂ ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಯಾರಾದರೂ ಪರಿಶೀಲಿಸುವವರೆಗೆ ಅದು ಏನೆಂದು ತಿಳಿಯಲು ಸಾಧ್ಯವಿಲ್ಲ.

ನಿರ್ವಾಹಕರು ಟ್ರೇಸ್ ಕೇಳಿದರೆ, ಯಾವ ಎಕ್ಸಿಕ್ಯೂಟೆಬಲ್ ಮತ್ತು ಯಾವ ಲೈಬ್ರರಿಗಳಿಂದ ಬೇಕು ಎಂದು ಕೇಳಿ. ಚೌಕಟ್ಟುಗಳು ವರದಿ ಮಾಡಿದ ಬಿಲ್ಡ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗದ backtrace ಅನ್ನು ನಂಬುವುದು ಕಷ್ಟ ಮತ್ತು ತಪ್ಪಾಗಿ ಓದುವುದು ಸುಲಭ.

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಮೂಲವನ್ನು ಪರಿಶೀಲಿಸಿ

ಸ್ಥಾಪನೆಯ ಮಾಲೀಕರ ಮೂಲಕ ಪ್ಯಾಕೇಜ್ ಮೂಲ ಮತ್ತು ಫೈಲ್ ಸಮಗ್ರತೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಯಾವುದೇ ನಿಯಂತ್ರಿತ ದುರಸ್ತಿಗೆ ಮೊದಲು ಸಂರಚನೆ ಮತ್ತು ಗುರುತಿನ ವಸ್ತುಗಳನ್ನು ಸಂರಕ್ಷಿಸಿ. ಸ್ವಚ್ಛ ಸ್ಥಾಪನೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆಯೇ ಎಂದು ನೋಡಲು ಮಾತ್ರ ಸಾಕ್ಷ್ಯದ ಏಕೈಕ ಪ್ರತಿಯನ್ನು ತಿದ್ದಬೇಡಿ. ಹೊಸ ಇಮೇಜ್ ಬೂಟ್ ಆದರೆ ಹೊಸ ಇಮೇಜ್ ಬೂಟ್ ಆಗುತ್ತದೆ ಎಂದಷ್ಟೇ ಹೇಳುತ್ತದೆ. ಹಳೆಯದರಲ್ಲಿ ಹಾಳಾದ ಪ್ಯಾಕೇಜ್, ವಿಫಲವಾಗುತ್ತಿರುವ ಕಾರ್ಡ್ ಅಥವಾ ಈ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ ಯಾವಾಗಲೂ ಫಾಲ್ಟ್ ಆಗುತ್ತಿದ್ದ ಬೈನರಿ ಇತ್ತೇ ಎಂದು ಹೇಳುವುದಿಲ್ಲ.

ಸಂಬಂಧವಿಲ್ಲದ ಪ್ರೋಗ್ರಾಮ್‌ಗಳೂ ವಿಫಲವಾದರೆ, ಅಥವಾ ಸಿಸ್ಟಂ ಸಂಗ್ರಹಣೆ, ವಿದ್ಯುತ್ ಅಥವಾ ಕರ್ನಲ್ ದೋಷಗಳನ್ನು ಲಾಗ್ ಮಾಡಿದರೆ, ಆ ವೀಕ್ಷಣೆಗಳನ್ನು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ತನಿಖೆಗಾಗಿ ಇಟ್ಟುಕೊಳ್ಳಿ. ಅವು ವ್ಯಾಪ್ತಿಯನ್ನು ವಿಸ್ತರಿಸುತ್ತವೆ; ಪ್ರತಿ segfault ವಿಫಲ RAM ಅಥವಾ ಹಾಳಾದ ಇಮೇಜ್‌ನಿಂದ ಬರುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ಗುರಿಪಡಿಸಿದ ಸರಿಪಡಿಸುವಿಕೆಯ ನಂತರ ಅದೇ ಅಧಿಕೃತ ಲಾಂಚ್ ಮತ್ತು ಅದೇ VPN ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಅದೇ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಪುನರಾವರ್ತಿಸಿ. ಯಾವ ವೈಫಲ್ಯ ನಿಂತಿತು ಮತ್ತು ಯಾವ ಆವೃತ್ತಿಯಲ್ಲಿ ಎಂದು ಹೇಳಿ. ಕೇವಲ ಸ್ವಚ್ಛ ಬೂಟ್ ಯಾವುದೇ ದೋಷಯುಕ್ತ ಘಟಕವನ್ನು ಗುರುತಿಸುವುದಿಲ್ಲ ಮತ್ತು ಮುಂದಿನ ಹಾರ್ಡ್‌ವೇರ್ ವೈಫಲ್ಯವನ್ನು ಊಹಿಸುವುದಿಲ್ಲ.