VPN ಕ್ಲೈಂಟ್ ಪ್ರಾರಂಭಿಸುವುದು ಅನುಕೂಲಕರ ಸಮಯ ಚಿಹ್ನೆ, ಕಾರಣವಲ್ಲ, ಮತ್ತು ಆ ವ್ಯತ್ಯಾಸವೇ ಮುಂದೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಆ ಕ್ಷಣದ ಸಮೀಪದಲ್ಲಿ ಕರ್ನಲ್ Oops ಸಂಭವಿಸಿದಾಗ, ಆಯ್ಕೆ ಉಪಯುಕ್ತ ಫಾಲ್ಟ್ ವರದಿಯನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಮತ್ತು ಉತ್ಪಾದನಾ ಯಂತ್ರದಲ್ಲಿ ಅದೇ ಕ್ರ್ಯಾಶ್ ಅನ್ನು ಇನ್ನೂ ಐದು ಬಾರಿ ಪ್ರಚೋದಿಸುವುದರ ನಡುವೆ ಇರುತ್ತದೆ. ರೀಬೂಟ್ ಮಾಡುವ ಮೊದಲು ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ಉಳಿಸಿ: ನಿಖರವಾದ ಕರ್ನಲ್ ಬಿಲ್ಡ್, ಮೊದಲ ಫಾಲ್ಟ್ ಟ್ರೇಸ್, taint ಸ್ಥಿತಿ ಮತ್ತು ಅದೇ ನಿಮಿಷದಲ್ಲಿ ಬದಲಾದ ಉಳಿದ ಎಲ್ಲದರ ಸಂಕ್ಷಿಪ್ತ ವಿವರಣೆ. ಉಳಿದದ್ದು ವ್ಯಾಖ್ಯಾನ, ಮತ್ತು ಸಾಕ್ಷ್ಯ ಸುರಕ್ಷಿತ ಸ್ಥಳದಲ್ಲಿರುವವರೆಗೆ ವ್ಯಾಖ್ಯಾನ ಕಾಯಬಹುದು.

ಕೊನೆಯ ಸಾಲಲ್ಲ, ಮೊದಲ ಫಾಲ್ಟ್ ಹಿಡಿಯಿರಿ

ಲಾಗ್‌ನಲ್ಲಿ ಮೊದಲ Oops ಮುಖ್ಯ, ಏಕೆಂದರೆ ನಂತರದ ಪ್ರತಿ ಫಾಲ್ಟ್ ಈಗಾಗಲೇ ಅನಾರೋಗ್ಯಕರ ಕರ್ನಲ್‌ನ ಪಾರ್ಶ್ವ ಹಾನಿಯಾಗಿರಬಹುದು. ಕರೆ ಟ್ರೇಸ್ ಜೊತೆಗೆ ಹೆಡರ್ ನಕಲಿಸಿ, ಏಕೆಂದರೆ ಹೆಡರ್ ಫಾಲ್ಟ್ ಉಂಟುಮಾಡಿದ ಸೂಚನೆ ಮತ್ತು ಕೋಡ್ ಮಾರ್ಗವನ್ನು ಗುರುತಿಸುವ ರಿಜಿಸ್ಟರ್ ಸ್ಥಿತಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಕೊನೆಯ ಸಾಲಿನಿಂದ ಪ್ರಾರಂಭವಾಗುವ ವರದಿ ಒಂದು ವಾರದ ನಂತರ ಓದುವವರಿಗೆ ತುಂಬಾ ಕಡಿಮೆ ಮೌಲ್ಯದ್ದು.

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

ಯಾವುದೇ ಚಿಹ್ನೆ ಓದುವ ಮೊದಲು ಬಿಲ್ಡ್ ನಿಗದಿಪಡಿಸಿ

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

ಮರದ ಹೊರಗಿನ ಮಾಡ್ಯೂಲ್‌ಗಳು ದಾಖಲೆಯಲ್ಲಿ ತಮ್ಮದೇ ಸಾಲಿಗೆ ಅರ್ಹವಾಗಿವೆ, ಏಕೆಂದರೆ taint ಮಾಡಿದ ಕರ್ನಲ್ ನಿರ್ವಾಹಕರು ಯಾವ ತೀರ್ಮಾನಕ್ಕೆ ಬರಬಹುದೆಂಬುದನ್ನು ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ. ಮಾಡ್ಯೂಲ್ ಪಟ್ಟಿಯಿಂದ ಊಹಿಸುವ ಬದಲು taint ಮೌಲ್ಯವನ್ನು ಓದಿ.

ಸೊನ್ನೆಯಲ್ಲದ taint ಆರೋಪವಲ್ಲ ಮತ್ತು ವರದಿಯನ್ನು ನಿರುಪಯುಕ್ತಗೊಳಿಸುವುದಿಲ್ಲ. ಅದು ಫಾಲ್ಟ್ ಸಮಯದಲ್ಲಿ ಯಾವ ಘಟಕಗಳು ಲೋಡ್ ಆಗಿದ್ದವು ಎಂದು ಓದುಗರಿಗೆ ಹೇಳುತ್ತದೆ, ಮತ್ತು ಕೆಲವು ಧ್ವಜಗಳು ವರದಿಯನ್ನು ತೀರ್ಪಿನಿಂದಲ್ಲ, ನೀತಿಯಿಂದ ಕಡಿಮೆ ಆದ್ಯತೆಗೆ ತರುತ್ತವೆ. ಮೌಲ್ಯ, ಮಾಡ್ಯೂಲ್ ಹೆಸರುಗಳು ಮತ್ತು ಅದೇ ಹಾರ್ಡ್‌ವೇರ್ ಹಾಗೂ ಹೊರೆ ಅವುಗಳಿಲ್ಲದೆ ಕರ್ನಲ್ ಚಲಾಯಿಸಿದೆಯೇ ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ. ಆ ಕೊನೆಯ ಹೋಲಿಕೆಯೇ ಹೊಸ ರಿಗ್ರೆಷನ್ ಅನ್ನು ಹಳೆಯ ದೋಷದಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ.

ಟ್ರಿಗರ್ ಅನ್ನು ದೋಷದಿಂದ ಬೇರ್ಪಡಿಸಿ

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

ಕೆಲಸ ಮಾಡಿದ ಹಿಂದಿನ ಇಮೇಜ್ ಸಾಕ್ಷ್ಯ, ಸಾಬೀತಲ್ಲ. ಹೋಲಿಸುವಾಗ ಪ್ರತಿ ಬೂಟ್‌ಗೆ ಒಂದು ಘಟಕ ಬದಲಿಸಿ, ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಯಂತ್ರದ ನಂತರವೂ ಉಳಿಯುವ ಸ್ಥಳದಲ್ಲಿ ಇಡಿ.

ನಿರ್ವಾಹಕರು ನಿಜವಾಗಿ ಏನನ್ನು ಬಳಸಬಹುದೆಂದು ಪರಿಶೀಲಿಸಿ

ಕಳುಹಿಸುವ ಮೊದಲು ವರದಿಯನ್ನು ಅಪರಿಚಿತರು ಓದುವಂತೆ ಓದಿ. ಸಂರಚನೆ, ನಿಖರ ಅನುಕ್ರಮ ಮತ್ತು ಬಿಲ್ಡ್ ಗುರುತು ಇದ್ದರೆ, ಮತ್ತು ರುಜುವಾತುಗಳು ತೆಗೆದುಹಾಕಲ್ಪಟ್ಟಿದ್ದರೆ, ವರದಿ ಉಪಯುಕ್ತವಾಗಿದೆ. ಅದು ಸ್ಟಾಕ್ ಟ್ರೇಸ್‌ನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ಆಗಿದ್ದರೆ, ಅದೇ ಮಾಹಿತಿಗಾಗಿ ವಿನಂತಿಯೊಂದಿಗೆ ಹಿಂತಿರುಗುತ್ತದೆ. ಕರ್ನಲ್ ಬಗ್-ಹಂಟಿಂಗ್ ಮಾರ್ಗದರ್ಶಿ ಉಪಯುಕ್ತ ಟ್ರೇಸ್ ಮತ್ತು ಹೊಂದುವ ಸಿಂಬಲ್‌ಗಳು ಹೇಗಿರುತ್ತವೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.

uname -r
cat /proc/sys/kernel/tainted
journalctl -k -b -1 --no-pager | sed -n '/BUG:/,/Call Trace/p'
dmesg -T | grep -A 40 'RIP:'

ಮೇಲಿನ ಪ್ರತಿ ಆಜ್ಞೆಯೂ ಸ್ಥಿತಿಯನ್ನು ಮಾತ್ರ ಓದುತ್ತದೆ, ಮತ್ತು ಯಂತ್ರವು ಇನ್ನೂ ಉತ್ತರಿಸಬಲ್ಲದಿದ್ದರೆ ಮೊದಲೆರಡನ್ನು ಮುಂದಿನ ರೀಬೂಟ್‌ಗಿಂತ ಮೊದಲು ಚಲಾಯಿಸಬೇಕು. ಜರ್ನಲ್ ಶಾಶ್ವತವಲ್ಲದಲ್ಲಿ, ಆ ಎರಡು ಮಾತ್ರ ಮತ್ತೆ ಎಂದಿಗೂ ಕೆಲಸ ಮಾಡುತ್ತವೆ.

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

ಸಂಬಂಧಿತ ಲೇಖನಗಳು