ನನ್ನ ದಿನದ ಕೆಲಸವು ಹೆಚ್ಚಾಗಿ ಸಾಫ್ಟ್‌ವೇರ್ ನಿಯೋಜನೆಯಾಗಿದೆ, ಅಂದರೆ ನಾನು ಈ ರೀತಿಯ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಲು ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಕಳೆಯುತ್ತೇನೆ:
- ಈ ಸಾಫ್ಟ್‌ವೇರ್ ಡೆವಲಪರ್‌ಗಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ನನಗೆ ಅಲ್ಲ. ಏಕೆ?
- ನಿನ್ನೆ ಈ ಸಾಫ್ಟ್‌ವೇರ್ ನನಗೆ ಕೆಲಸ ಮಾಡಿದೆ, ಆದರೆ ಇಂದು ಅದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಏಕೆ?
ಇದು ಸಾಮಾನ್ಯ ಸಾಫ್ಟ್‌ವೇರ್ ಡೀಬಗ್ ಮಾಡುವಿಕೆಗಿಂತ ಸ್ವಲ್ಪ ಭಿನ್ನವಾಗಿರುವ ಒಂದು ರೀತಿಯ ಡೀಬಗ್ ಆಗಿದೆ. ನಿಯಮಿತ ಡೀಬಗ್ ಮಾಡುವುದು ಕೋಡ್‌ನ ತರ್ಕಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ, ಆದರೆ ನಿಯೋಜನೆ ಡೀಬಗ್ ಮಾಡುವುದು ಕೋಡ್ ಮತ್ತು ಪರಿಸರದ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಬಗ್ಗೆ. ಸಮಸ್ಯೆಯ ಮೂಲವು ತಾರ್ಕಿಕ ದೋಷವಾಗಿದ್ದರೂ ಸಹ, ಎಲ್ಲವೂ ಒಂದು ಯಂತ್ರದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದು ಯಂತ್ರದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಎಂದರೆ ಸಮಸ್ಯೆಯು ಪರಿಸರದಲ್ಲಿ ಹೇಗಾದರೂ ಇದೆ ಎಂದು ಅರ್ಥ.
ಆದ್ದರಿಂದ ಸಾಮಾನ್ಯ ಡೀಬಗ್ ಮಾಡುವ ಸಾಧನಗಳ ಬದಲಿಗೆ ಜಿಡಿಬಿ ಡೀಬಗ್ ಮಾಡುವ ನಿಯೋಜನೆಗಾಗಿ ನನ್ನ ಬಳಿ ಬೇರೆ ಬೇರೆ ಉಪಕರಣಗಳಿವೆ. ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ನಿಭಾಯಿಸಲು ನನ್ನ ಮೆಚ್ಚಿನ ಸಾಧನ "ಈ ಸಾಫ್ಟ್‌ವೇರ್ ನನಗೆ ಏಕೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ?" ಎಂದು ಕರೆದರು ಸ್ಟ್ರೇಸ್.
ಸ್ಟ್ರೇಸ್ ಎಂದರೇನು?
"ಸಿಸ್ಟಮ್ ಕಾಲ್ ಟ್ರೇಸಿಂಗ್" ಗಾಗಿ ಒಂದು ಸಾಧನವಾಗಿದೆ. ಇದನ್ನು ಮೂಲತಃ ಲಿನಕ್ಸ್‌ಗಾಗಿ ರಚಿಸಲಾಗಿದೆ, ಆದರೆ ಅದೇ ಡೀಬಗ್ ಮಾಡುವ ತಂತ್ರಗಳನ್ನು ಇತರ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಉಪಕರಣಗಳೊಂದಿಗೆ ಮಾಡಬಹುದು ( ಅಥವಾ ).
ಮೂಲ ಅಪ್ಲಿಕೇಶನ್ ತುಂಬಾ ಸರಳವಾಗಿದೆ. ನೀವು ಯಾವುದೇ ಆಜ್ಞೆಯೊಂದಿಗೆ ಸ್ಟ್ರೇಸ್ ಅನ್ನು ಚಲಾಯಿಸಬೇಕು ಮತ್ತು ಅದು ಎಲ್ಲಾ ಸಿಸ್ಟಮ್ ಕರೆಗಳನ್ನು ಡಂಪ್ ಮಾಡುತ್ತದೆ (ಆದರೂ ಮೊದಲು ನೀವು ಅದನ್ನು ನೀವೇ ಸ್ಥಾಪಿಸಬೇಕಾಗುತ್ತದೆ ಸ್ಟ್ರೇಸ್):
$ strace echo Hello
...Snip lots of stuff...
write(1, "Hellon", 6) = 6
close(1) = 0
close(2) = 0
exit_group(0) = ?
+++ exited with 0 +++ಈ ಸಿಸ್ಟಮ್ ಕರೆಗಳು ಯಾವುವು? ಇದು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಕರ್ನಲ್‌ಗಾಗಿ API ಯಂತಿದೆ. ಒಂದಾನೊಂದು ಕಾಲದಲ್ಲಿ, ಸಾಫ್ಟ್‌ವೇರ್ ಅದು ಚಾಲನೆಯಲ್ಲಿರುವ ಹಾರ್ಡ್‌ವೇರ್‌ಗೆ ನೇರ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿತ್ತು. ಉದಾಹರಣೆಗೆ, ಇದು ಪರದೆಯ ಮೇಲೆ ಏನನ್ನಾದರೂ ಪ್ರದರ್ಶಿಸಲು ಅಗತ್ಯವಿದ್ದರೆ, ಅದು ವೀಡಿಯೊ ಸಾಧನಗಳಿಗಾಗಿ ಪೋರ್ಟ್‌ಗಳು ಅಥವಾ ಮೆಮೊರಿ-ಮ್ಯಾಪ್ ಮಾಡಿದ ರೆಜಿಸ್ಟರ್‌ಗಳೊಂದಿಗೆ ಪ್ಲೇ ಆಗುತ್ತದೆ. ಬಹುಕಾರ್ಯಕ ಕಂಪ್ಯೂಟರ್ ವ್ಯವಸ್ಥೆಗಳು ಜನಪ್ರಿಯವಾದಾಗ, ಯಂತ್ರಾಂಶದ ಮೇಲೆ ವಿವಿಧ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಹೋರಾಡುತ್ತಿದ್ದಂತೆ ಅವ್ಯವಸ್ಥೆ ಆಳ್ವಿಕೆ ನಡೆಸಿತು. ಒಂದು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿನ ದೋಷಗಳು ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್ ಅಲ್ಲದಿದ್ದರೂ ಇತರರನ್ನು ಕೆಳಗಿಳಿಸಬಹುದು. ನಂತರ ಸವಲತ್ತು ವಿಧಾನಗಳು (ಅಥವಾ "ರಿಂಗ್ ರಕ್ಷಣೆ") CPU ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡವು. ಕರ್ನಲ್ ಅತ್ಯಂತ ಸವಲತ್ತು ಪಡೆದಿದೆ: ಇದು ಹಾರ್ಡ್‌ವೇರ್‌ಗೆ ಸಂಪೂರ್ಣ ಪ್ರವೇಶವನ್ನು ಪಡೆದುಕೊಂಡಿತು, ಸಿಸ್ಟಮ್ ಕರೆಗಳ ಮೂಲಕ ಹಾರ್ಡ್‌ವೇರ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಈಗಾಗಲೇ ಕರ್ನಲ್‌ನಿಂದ ಪ್ರವೇಶವನ್ನು ವಿನಂತಿಸಬೇಕಾದ ಕಡಿಮೆ ಸವಲತ್ತು ಹೊಂದಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹುಟ್ಟುಹಾಕಿತು.
ಬೈನರಿ ಮಟ್ಟದಲ್ಲಿ, ಸಿಸ್ಟಮ್ ಕರೆಯು ಸರಳ ಕಾರ್ಯದ ಕರೆಗಿಂತ ಸ್ವಲ್ಪ ಭಿನ್ನವಾಗಿರುತ್ತದೆ, ಆದರೆ ಹೆಚ್ಚಿನ ಪ್ರೋಗ್ರಾಂಗಳು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಲೈಬ್ರರಿಯಲ್ಲಿ ಹೊದಿಕೆಯನ್ನು ಬಳಸುತ್ತವೆ. ಆ. POSIX C ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಲೈಬ್ರರಿಯು ಫಂಕ್ಷನ್ ಕರೆಯನ್ನು ಹೊಂದಿದೆ ಬರೆಯಿರಿ (), ಇದು ಸಿಸ್ಟಮ್ ಕರೆಗಾಗಿ ಎಲ್ಲಾ ಆರ್ಕಿಟೆಕ್ಚರ್-ನಿರ್ದಿಷ್ಟ ಕೋಡ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ ಬರೆಯಲು.
ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಅದರ ಪರಿಸರ (ಕಂಪ್ಯೂಟರ್ ವ್ಯವಸ್ಥೆಗಳು) ನಡುವಿನ ಯಾವುದೇ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಸಿಸ್ಟಮ್ ಕರೆಗಳ ಮೂಲಕ ನಡೆಸಲಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, ಸಾಫ್ಟ್‌ವೇರ್ ಒಂದು ಗಣಕದಲ್ಲಿ ಆದರೆ ಇನ್ನೊಂದರಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸದಿದ್ದಾಗ, ಸಿಸ್ಟಮ್ ಕರೆ ಟ್ರೇಸಿಂಗ್ ಫಲಿತಾಂಶಗಳನ್ನು ನೋಡುವುದು ಒಳ್ಳೆಯದು. ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾಗಿ, ಸಿಸ್ಟಮ್ ಕರೆ ಟ್ರೇಸ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ವಿಶ್ಲೇಷಿಸಬಹುದಾದ ವಿಶಿಷ್ಟ ಕ್ಷಣಗಳ ಪಟ್ಟಿ ಇಲ್ಲಿದೆ:
- ಕನ್ಸೋಲ್ I/O
- ನೆಟ್‌ವರ್ಕ್ I/O
- ಫೈಲ್ ಸಿಸ್ಟಮ್ ಪ್ರವೇಶ ಮತ್ತು ಫೈಲ್ I/O
- ಪ್ರಕ್ರಿಯೆಯ ಥ್ರೆಡ್‌ನ ಜೀವಿತಾವಧಿಯನ್ನು ನಿರ್ವಹಿಸುವುದು
- ಕಡಿಮೆ ಮಟ್ಟದ ಮೆಮೊರಿ ನಿರ್ವಹಣೆ
- ನಿರ್ದಿಷ್ಟ ಸಾಧನ ಡ್ರೈವರ್‌ಗಳಿಗೆ ಪ್ರವೇಶ
ಸ್ಟ್ರೇಸ್ ಅನ್ನು ಯಾವಾಗ ಬಳಸಬೇಕು?
ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಸ್ಟ್ರೇಸ್ ಬಳಕೆದಾರ ಜಾಗದಲ್ಲಿ ಯಾವುದೇ ಪ್ರೋಗ್ರಾಂನೊಂದಿಗೆ ಬಳಸಲಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಬಳಕೆದಾರರ ಜಾಗದಲ್ಲಿ ಯಾವುದೇ ಪ್ರೋಗ್ರಾಂ ಸಿಸ್ಟಮ್ ಕರೆಗಳನ್ನು ಮಾಡಬೇಕು. ಇದು ಕಂಪೈಲ್ ಮಾಡಿದ, ಕಡಿಮೆ-ಹಂತದ ಪ್ರೋಗ್ರಾಂಗಳೊಂದಿಗೆ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ನೀವು ರನ್ಟೈಮ್ ಮತ್ತು ಇಂಟರ್ಪ್ರಿಟರ್ನಿಂದ ಹೆಚ್ಚುವರಿ ಶಬ್ದವನ್ನು ಕಡಿತಗೊಳಿಸಬಹುದಾದರೆ ಪೈಥಾನ್ ನಂತಹ ಉನ್ನತ ಮಟ್ಟದ ಭಾಷೆಗಳೊಂದಿಗೆ ಸಹ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಅದರ ಎಲ್ಲಾ ವೈಭವದಲ್ಲಿ ಸ್ಟ್ರೇಸ್ ಒಂದು ಗಣಕದಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸಾಫ್ಟ್‌ವೇರ್‌ನ ಡೀಬಗ್ ಮಾಡುವ ಸಮಯದಲ್ಲಿ ಸ್ವತಃ ಸ್ಪಷ್ಟವಾಗಿ ಗೋಚರಿಸುತ್ತದೆ, ಆದರೆ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಇನ್ನೊಂದರಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಫೈಲ್‌ಗಳು, ಅನುಮತಿಗಳು ಅಥವಾ ಕೆಲವು ಆಜ್ಞೆಗಳನ್ನು ಅಥವಾ ಯಾವುದನ್ನಾದರೂ ಕಾರ್ಯಗತಗೊಳಿಸಲು ವಿಫಲ ಪ್ರಯತ್ನಗಳ ಬಗ್ಗೆ ಅಸ್ಪಷ್ಟ ಸಂದೇಶಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ... ಇದು ವಿಷಾದದ ಸಂಗತಿ, ಆದರೆ ಹಾಗೆ ಮಾಡುವುದಿಲ್ಲ ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆ ದೋಷಗಳಂತಹ ಉನ್ನತ ಮಟ್ಟದ ಸಮಸ್ಯೆಗಳೊಂದಿಗೆ ಚೆನ್ನಾಗಿ ಸಂಯೋಜಿಸಿ. ಸಾಮಾನ್ಯವಾಗಿ ಇದಕ್ಕೆ ಸಂಯೋಜನೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ ಸ್ಟ್ರೇಸ್ಕೆಲವೊಮ್ಮೆ ಮತ್ತು ಉನ್ನತ ಮಟ್ಟದ ಉಪಕರಣಗಳು (ಆಜ್ಞಾ ಸಾಲಿನ ಉಪಕರಣದಂತೆ openssl ಪ್ರಮಾಣಪತ್ರವನ್ನು ಡೀಬಗ್ ಮಾಡಲು).
ನಾವು ಸ್ವತಂತ್ರ ಸರ್ವರ್ ಅನ್ನು ಉದಾಹರಣೆಯಾಗಿ ಬಳಸುತ್ತೇವೆ, ಆದರೆ ಸಿಸ್ಟಮ್ ಕರೆ ಟ್ರೇಸಿಂಗ್ ಅನ್ನು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ನಿಯೋಜನೆ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ ಹೆಚ್ಚಾಗಿ ಮಾಡಬಹುದು. ನೀವು ಸರಿಯಾದ ಪರಿಕರಗಳನ್ನು ಆರಿಸಬೇಕಾಗುತ್ತದೆ.
ಸರಳ ಡೀಬಗ್ ಉದಾಹರಣೆ
ನೀವು ಅದ್ಭುತವಾದ ಸರ್ವರ್ ಅಪ್ಲಿಕೇಶನ್ ಫೂ ಅನ್ನು ಚಲಾಯಿಸಲು ಬಯಸುತ್ತೀರಿ ಎಂದು ಹೇಳೋಣ ಮತ್ತು ನೀವು ಇದರೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತೀರಿ:
$ foo
Error opening configuration file: No such file or directoryನೀವು ಬರೆದ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಅದು ಕಂಡುಹಿಡಿಯಲಾಗಲಿಲ್ಲ. ಇದು ಸಂಭವಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಕೆಲವೊಮ್ಮೆ ಪ್ಯಾಕೇಜ್ ನಿರ್ವಾಹಕರು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಂಪೈಲ್ ಮಾಡಿದಾಗ, ಅವರು ನಿರೀಕ್ಷಿತ ಫೈಲ್ ಸ್ಥಳಗಳನ್ನು ಅತಿಕ್ರಮಿಸುತ್ತಾರೆ. ಮತ್ತು ನೀವು ಒಂದು ವಿತರಣೆಗಾಗಿ ಅನುಸ್ಥಾಪನ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಅನುಸರಿಸಿದರೆ, ಇನ್ನೊಂದರಲ್ಲಿ ನೀವು ನಿರೀಕ್ಷಿಸಿದ ಸ್ಥಳಕ್ಕಿಂತ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾದ ಫೈಲ್‌ಗಳನ್ನು ನೀವು ಕಾಣಬಹುದು. ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಎಲ್ಲಿ ನೋಡಬೇಕೆಂದು ದೋಷ ಸಂದೇಶವು ಹೇಳಿದರೆ ಸಮಸ್ಯೆಯನ್ನು ಒಂದೆರಡು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಪರಿಹರಿಸಬಹುದು, ಆದರೆ ಅದು ಆಗುವುದಿಲ್ಲ. ಹಾಗಾದರೆ ಎಲ್ಲಿ ನೋಡಬೇಕು?
ನೀವು ಮೂಲ ಕೋಡ್‌ಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಓದಬಹುದು ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಕಂಡುಹಿಡಿಯಬಹುದು. ಉತ್ತಮ ಬ್ಯಾಕಪ್ ಯೋಜನೆ, ಆದರೆ ವೇಗವಾದ ಪರಿಹಾರವಲ್ಲ. ನೀವು ಹಂತ-ಹಂತದ ಡೀಬಗರ್ ಅನ್ನು ಆಶ್ರಯಿಸಬಹುದು ಜಿಡಿಬಿ ಮತ್ತು ಪ್ರೋಗ್ರಾಂ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಿ, ಆದರೆ ಪರಿಸರದೊಂದಿಗೆ ಸಂವಹನವನ್ನು ತೋರಿಸಲು ನಿರ್ದಿಷ್ಟವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಸಾಧನವನ್ನು ಬಳಸುವುದು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ: ಸ್ಟ್ರೇಸ್.
ತೀರ್ಮಾನಕ್ಕೆ ಸ್ಟ್ರೇಸ್ ಅನಗತ್ಯವಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೆ ಒಳ್ಳೆಯ ಸುದ್ದಿ ಎಂದರೆ ಅದರಲ್ಲಿ ಹೆಚ್ಚಿನವುಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ನಿರ್ಲಕ್ಷಿಸಬಹುದು. ಟ್ರೇಸ್ ಫಲಿತಾಂಶಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಫೈಲ್‌ಗೆ ಉಳಿಸಲು -o ಆಪರೇಟರ್ ಅನ್ನು ಬಳಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಉಪಯುಕ್ತವಾಗಿದೆ:
$ strace -o /tmp/trace foo
Error opening configuration file: No such file or directory
$ cat /tmp/trace
execve("foo", ["foo"], 0x7ffce98dc010 /* 16 vars */) = 0
brk(NULL) = 0x56363b3fb000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=25186, ...}) = 0
mmap(NULL, 25186, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f2f12cf1000
close(3) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "177ELF2113 3 > 1 260A2 "..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1824496, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2f12cef000
mmap(NULL, 1837056, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2f12b2e000
mprotect(0x7f2f12b50000, 1658880, PROT_NONE) = 0
mmap(0x7f2f12b50000, 1343488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f2f12b50000
mmap(0x7f2f12c98000, 311296, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16a000) = 0x7f2f12c98000
mmap(0x7f2f12ce5000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b6000) = 0x7f2f12ce5000
mmap(0x7f2f12ceb000, 14336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2f12ceb000
close(3) = 0
arch_prctl(ARCH_SET_FS, 0x7f2f12cf0500) = 0
mprotect(0x7f2f12ce5000, 16384, PROT_READ) = 0
mprotect(0x56363b08b000, 4096, PROT_READ) = 0
mprotect(0x7f2f12d1f000, 4096, PROT_READ) = 0
munmap(0x7f2f12cf1000, 25186) = 0
openat(AT_FDCWD, "/etc/foo/config.json", O_RDONLY) = -1 ENOENT (No such file or directory)
dup(2) = 3
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
brk(NULL) = 0x56363b3fb000
brk(0x56363b41c000) = 0x56363b41c000
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x8), ...}) = 0
write(3, "Error opening configuration file"..., 60) = 60
close(3) = 0
exit_group(1) = ?
+++ exited with 1 +++ಔಟ್‌ಪುಟ್‌ನ ಸರಿಸುಮಾರು ಸಂಪೂರ್ಣ ಮೊದಲ ಪುಟ ಸ್ಟ್ರೇಸ್ - ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಉಡಾವಣೆಗೆ ಕಡಿಮೆ ಮಟ್ಟದ ತಯಾರಿಯಾಗಿದೆ. (ಸಾಕಷ್ಟು ಕರೆಗಳು mp, ರಕ್ಷಿಸಿ, ಕ್ವಿಲ್ ಕಡಿಮೆ ಮಟ್ಟದ ಮೆಮೊರಿಯನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು ಮತ್ತು ಡೈನಾಮಿಕ್ ಲೈಬ್ರರಿಗಳನ್ನು ಪ್ರದರ್ಶಿಸುವುದು.) ವಾಸ್ತವವಾಗಿ, ಔಟ್ಪುಟ್ ಅನ್ನು ಡೀಬಗ್ ಮಾಡುವಾಗ ಸ್ಟ್ರೇಸ್ ಕೊನೆಯಿಂದ ಓದುವುದು ಉತ್ತಮ. ಕೆಳಗೆ ಒಂದು ಸವಾಲು ಇರುತ್ತದೆ ಬರೆಯಲು, ಇದು ದೋಷ ಸಂದೇಶವನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ. ನಾವು ಮೇಲೆ ನೋಡುತ್ತೇವೆ ಮತ್ತು ಮೊದಲ ತಪ್ಪಾದ ಸಿಸ್ಟಮ್ ಕರೆಯನ್ನು ನೋಡುತ್ತೇವೆ - ಕರೆ openat, ಇದು ದೋಷವನ್ನು ಎಸೆಯುತ್ತದೆ ENOENT ("ಫೈಲ್ ಅಥವಾ ಡೈರೆಕ್ಟರಿ ಕಂಡುಬಂದಿಲ್ಲ") ತೆರೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದೆ /etc/foo/config.json. ಇಲ್ಲಿಯೇ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಇರಬೇಕು.
ಇದು ಕೇವಲ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ, ಆದರೆ ನಾನು ಬಳಸುವ 90% ಸಮಯವನ್ನು ನಾನು ಹೇಳುತ್ತೇನೆ ಸ್ಟ್ರೇಸ್, ಇದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಷ್ಟ ಏನೂ ಇಲ್ಲ. ಕೆಳಗೆ ಸಂಪೂರ್ಣ ಹಂತ-ಹಂತದ ಡೀಬಗ್ ಮಾಡುವ ಮಾರ್ಗದರ್ಶಿಯಾಗಿದೆ:
- ಪ್ರೋಗ್ರಾಂನಿಂದ ಸಿಸ್ಟಮ್-ವೈ ದೋಷದ ಬಗ್ಗೆ ಅಸ್ಪಷ್ಟ ಸಂದೇಶದಿಂದಾಗಿ ಅಸಮಾಧಾನಗೊಳ್ಳಿರಿ
- ಇದರೊಂದಿಗೆ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ ಸ್ಟ್ರೇಸ್
- ಟ್ರೇಸ್ ಫಲಿತಾಂಶಗಳಲ್ಲಿ ದೋಷ ಸಂದೇಶವನ್ನು ಹುಡುಕಿ
- ನೀವು ಮೊದಲ ವಿಫಲ ಸಿಸ್ಟಂ ಕರೆಯನ್ನು ಹೊಡೆಯುವವರೆಗೆ ಮೇಲಕ್ಕೆ ಹೋಗಿ
ಹಂತ 4 ರಲ್ಲಿ ಸಿಸ್ಟಮ್ ಕರೆ ಏನು ತಪ್ಪಾಗಿದೆ ಎಂಬುದನ್ನು ಬಹಿರಂಗಪಡಿಸುವ ಸಾಧ್ಯತೆಯಿದೆ.
ಸುಳಿವುಗಳು
ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಡೀಬಗ್ ಮಾಡುವಿಕೆಯ ಉದಾಹರಣೆಯನ್ನು ನಿಮಗೆ ತೋರಿಸುವ ಮೊದಲು, ಪರಿಣಾಮಕಾರಿ ಬಳಕೆಗಾಗಿ ನಾನು ನಿಮಗೆ ಕೆಲವು ತಂತ್ರಗಳನ್ನು ತೋರಿಸುತ್ತೇನೆ ಸ್ಟ್ರೇಸ್:
ಮನುಷ್ಯ ನಿಮ್ಮ ಸ್ನೇಹಿತ
ಅನೇಕ *nix ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ, ಕರ್ನಲ್‌ಗೆ ಸಿಸ್ಟಮ್ ಕರೆಗಳ ಸಂಪೂರ್ಣ ಪಟ್ಟಿಯನ್ನು ರನ್ ಮಾಡುವ ಮೂಲಕ ಪಡೆಯಬಹುದು ಮನುಷ್ಯ ಸಿಸ್ಕಾಲ್ಸ್. ಮುಂತಾದ ವಿಷಯಗಳನ್ನು ನೀವು ನೋಡುತ್ತೀರಿ brk(2), ಅಂದರೆ ಚಾಲನೆಯಲ್ಲಿರುವ ಮೂಲಕ ಹೆಚ್ಚಿನ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಬಹುದು ಮನುಷ್ಯ 2 brk.
ಸಣ್ಣ ಕುಂಟೆ: ಮನುಷ್ಯ 2 ಫೋರ್ಕ್ ಶೆಲ್‌ಗಾಗಿ ಪುಟವನ್ನು ನನಗೆ ತೋರಿಸುತ್ತದೆ ಫೋರ್ಕ್ () в GNU libc, ಇದು ತಿರುಗಿದರೆ, ಕರೆ ಬಳಸಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಕ್ಲೋನ್ (). ಶಬ್ದಾರ್ಥವನ್ನು ಕರೆಯಿರಿ ಫೋರ್ಕ್ ನೀವು ಬಳಸಿ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಬರೆದರೆ ಅದೇ ಆಗಿರುತ್ತದೆ ಫೋರ್ಕ್ (), ಮತ್ತು ಟ್ರೇಸ್ ಅನ್ನು ರನ್ ಮಾಡಿ - ನಾನು ಯಾವುದೇ ಕರೆಗಳನ್ನು ಕಾಣುವುದಿಲ್ಲ ಫೋರ್ಕ್, ಅವುಗಳ ಬದಲಿಗೆ ಇರುತ್ತದೆ ಕ್ಲೋನ್ (). ನೀವು ಮೂಲವನ್ನು ಔಟ್‌ಪುಟ್‌ನೊಂದಿಗೆ ಹೋಲಿಸಲು ಪ್ರಾರಂಭಿಸಿದರೆ ಅಂತಹ ರೇಕ್‌ಗಳು ನಿಮ್ಮನ್ನು ಗೊಂದಲಗೊಳಿಸುತ್ತವೆ ಸ್ಟ್ರೇಸ್.
ಫೈಲ್‌ಗೆ ಔಟ್ಪುಟ್ ಅನ್ನು ಉಳಿಸಲು -o ಬಳಸಿ
ಸ್ಟ್ರೇಸ್ ವ್ಯಾಪಕವಾದ ಔಟ್ಪುಟ್ ಅನ್ನು ಉತ್ಪಾದಿಸಬಹುದು, ಆದ್ದರಿಂದ ಜಾಡಿನ ಫಲಿತಾಂಶಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಫೈಲ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲು ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಉಪಯುಕ್ತವಾಗಿದೆ (ಮೇಲಿನ ಉದಾಹರಣೆಯಲ್ಲಿರುವಂತೆ). ಔಟ್‌ಪುಟ್‌ನೊಂದಿಗೆ ಪ್ರೋಗ್ರಾಂ ಔಟ್ಪುಟ್ ಅನ್ನು ಗೊಂದಲಗೊಳಿಸುವುದನ್ನು ತಪ್ಪಿಸಲು ಇದು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಸ್ಟ್ರೇಸ್ ಕನ್ಸೋಲ್‌ನಲ್ಲಿ.
ಹೆಚ್ಚಿನ ಆರ್ಗ್ಯುಮೆಂಟ್ ಡೇಟಾವನ್ನು ವೀಕ್ಷಿಸಲು -s ಅನ್ನು ಬಳಸಿ
ಮೇಲಿನ ಉದಾಹರಣೆ ಟ್ರೇಸ್‌ನಲ್ಲಿ ದೋಷ ಸಂದೇಶದ ದ್ವಿತೀಯಾರ್ಧವನ್ನು ತೋರಿಸದಿರುವುದನ್ನು ನೀವು ಗಮನಿಸಿರಬಹುದು. ಇದು ಏಕೆಂದರೆ ಸ್ಟ್ರೇಸ್ ಡೀಫಾಲ್ಟ್ ಸ್ಟ್ರಿಂಗ್ ಆರ್ಗ್ಯುಮೆಂಟ್‌ನ ಮೊದಲ 32 ಬೈಟ್‌ಗಳನ್ನು ಮಾತ್ರ ತೋರಿಸುತ್ತದೆ. ನೀವು ಹೆಚ್ಚಿನದನ್ನು ನೋಡಲು ಬಯಸಿದರೆ, ಅಂತಹದನ್ನು ಸೇರಿಸಿ -ಎಸ್ 128 ಕರೆಗೆ ಸ್ಟ್ರೇಸ್.
-y ಫೈಲ್‌ಗಳು, ಸಾಕೆಟ್‌ಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.
"ಎಲ್ಲವೂ ಫೈಲ್" ಎಂದರೆ * ನಿಕ್ಸ್ ಸಿಸ್ಟಮ್‌ಗಳು ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಎಲ್ಲಾ I/O ಗಳನ್ನು ಮಾಡುತ್ತದೆ, ಅದು ಫೈಲ್ ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಅಥವಾ ಇಂಟರ್‌ಪ್ರೊಸೆಸ್ ಪೈಪ್‌ಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಇದು ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ಗೆ ಅನುಕೂಲಕರವಾಗಿದೆ, ಆದರೆ ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ನೋಡಿದಾಗ ನಿಜವಾಗಿಯೂ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದರ ಕುರಿತು ನಿಗಾ ಇಡಲು ಕಷ್ಟವಾಗುತ್ತದೆ ಓದಲು и ಬರೆಯಲು ಸಿಸ್ಟಮ್ ಕರೆ ಟ್ರೇಸ್ ಫಲಿತಾಂಶಗಳಲ್ಲಿ.
ಆಪರೇಟರ್ ಅನ್ನು ಸೇರಿಸುವ ಮೂಲಕ -у, ನೀವು ಒತ್ತಾಯಿಸುತ್ತೀರಿ ಸ್ಟ್ರೇಸ್ ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಪ್ರತಿ ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಅನ್ನು ಅದು ಏನನ್ನು ಸೂಚಿಸುತ್ತದೆ ಎಂಬುದರ ಟಿಪ್ಪಣಿಯೊಂದಿಗೆ ಟಿಪ್ಪಣಿ ಮಾಡಿ.
-p** ನೊಂದಿಗೆ ಈಗಾಗಲೇ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಗೆ ಲಗತ್ತಿಸಿ
ಕೆಳಗಿನ ಉದಾಹರಣೆಯಿಂದ ನೀವು ನೋಡುವಂತೆ, ಕೆಲವೊಮ್ಮೆ ನೀವು ಈಗಾಗಲೇ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಪತ್ತೆಹಚ್ಚಬೇಕಾಗುತ್ತದೆ. ಇದು ಪ್ರಕ್ರಿಯೆ 1337 ನಂತೆ ಚಾಲನೆಯಲ್ಲಿದೆ ಎಂದು ತಿಳಿದಿದ್ದರೆ (ಔಟ್‌ಪುಟ್‌ನಿಂದ ಹೇಳು ps), ನಂತರ ನೀವು ಇದನ್ನು ಈ ರೀತಿ ಪತ್ತೆಹಚ್ಚಬಹುದು:
$ strace -p 1337
...system call trace output...ನಿಮಗೆ ಮೂಲ ಹಕ್ಕುಗಳು ಬೇಕಾಗಬಹುದು.
ಮಕ್ಕಳ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು -f ಬಳಸಿ
ಸ್ಟ್ರೇಸ್ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಇದು ಕೇವಲ ಒಂದು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತದೆ. ಈ ಪ್ರಕ್ರಿಯೆಯು ಮಗುವಿನ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಹುಟ್ಟುಹಾಕಿದರೆ, ನಂತರ ಮಗುವಿನ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹುಟ್ಟುಹಾಕಲು ಸಿಸ್ಟಮ್ ಕರೆಯನ್ನು ನೋಡಬಹುದು, ಆದರೆ ಮಗುವಿನ ಪ್ರಕ್ರಿಯೆಯ ಸಿಸ್ಟಮ್ ಕರೆಗಳನ್ನು ಪ್ರದರ್ಶಿಸಲಾಗುವುದಿಲ್ಲ.
ದೋಷವು ಮಗುವಿನ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿದೆ ಎಂದು ನೀವು ಭಾವಿಸಿದರೆ, ಹೇಳಿಕೆಯನ್ನು ಬಳಸಿ -f, ಇದು ಅದರ ಪತ್ತೆಹಚ್ಚುವಿಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಇದರ ನ್ಯೂನತೆಯೆಂದರೆ, ಔಟ್ಪುಟ್ ನಿಮ್ಮನ್ನು ಇನ್ನಷ್ಟು ಗೊಂದಲಗೊಳಿಸುತ್ತದೆ. ಯಾವಾಗ ಸ್ಟ್ರೇಸ್ ಒಂದು ಪ್ರಕ್ರಿಯೆ ಅಥವಾ ಒಂದು ಥ್ರೆಡ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತದೆ, ಇದು ಕರೆ ಘಟನೆಗಳ ಒಂದು ಸ್ಟ್ರೀಮ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ. ಇದು ಏಕಕಾಲದಲ್ಲಿ ಅನೇಕ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಿದಾಗ, ಸಂದೇಶದಿಂದ ಅಡ್ಡಿಪಡಿಸಿದ ಕರೆಯ ಪ್ರಾರಂಭವನ್ನು ನೀವು ನೋಡಬಹುದು , ನಂತರ - ಇತರ ಮರಣದಂಡನೆ ಶಾಖೆಗಳಿಗೆ ಕರೆಗಳ ಗುಂಪೇ, ಮತ್ತು ನಂತರ ಮಾತ್ರ - ಮೊದಲನೆಯದು ಅಂತ್ಯ <...foocall ಪುನರಾರಂಭಿಸಲಾಗಿದೆ>. ಅಥವಾ ಆಪರೇಟರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಎಲ್ಲಾ ಟ್ರೇಸ್ ಫಲಿತಾಂಶಗಳನ್ನು ವಿಭಿನ್ನ ಫೈಲ್‌ಗಳಾಗಿ ವಿಭಜಿಸಿ -ff (ವಿವರಗಳು ರಲ್ಲಿ ಮೇಲೆ ಸ್ಟ್ರೇಸ್).
-e ಬಳಸಿಕೊಂಡು ಕುರುಹುಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಿ
ನೀವು ನೋಡುವಂತೆ, ಜಾಡಿನ ಫಲಿತಾಂಶವು ಎಲ್ಲಾ ಸಂಭವನೀಯ ಸಿಸ್ಟಮ್ ಕರೆಗಳ ನಿಜವಾದ ರಾಶಿಯಾಗಿದೆ. ಧ್ವಜ -e ನೀವು ಜಾಡಿನ ಫಿಲ್ಟರ್ ಮಾಡಬಹುದು (ನೋಡಿ ಮೇಲೆ ಸ್ಟ್ರೇಸ್) ಪೂರ್ಣ ಜಾಡಿನ ಮತ್ತು ನಂತರ ಮಾಡುವುದಕ್ಕಿಂತ ಫಿಲ್ಟರ್ ಮಾಡಿದ ಟ್ರೇಸ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಇದು ವೇಗವಾಗಿರುತ್ತದೆ ಎಂಬುದು ಮುಖ್ಯ ಪ್ರಯೋಜನವಾಗಿದೆ grep`ನಲ್ಲಿ. ನಿಜ ಹೇಳಬೇಕೆಂದರೆ, ನಾನು ಯಾವಾಗಲೂ ಹೆದರುವುದಿಲ್ಲ.
ಎಲ್ಲಾ ತಪ್ಪುಗಳು ಕೆಟ್ಟದ್ದಲ್ಲ
ಒಂದು ಸರಳ ಮತ್ತು ಸಾಮಾನ್ಯ ಉದಾಹರಣೆಯೆಂದರೆ, ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಫೈಲ್ ಅನ್ನು ಒಳಗೊಂಡಿರುವ ಡೈರೆಕ್ಟರಿಯನ್ನು ಹುಡುಕುತ್ತಿರುವ ಶೆಲ್‌ನಂತೆ ಏಕಕಾಲದಲ್ಲಿ ಹಲವಾರು ಸ್ಥಳಗಳಲ್ಲಿ ಫೈಲ್ ಅನ್ನು ಹುಡುಕುವ ಪ್ರೋಗ್ರಾಂ:
$ strace sh -c uname
...
stat("/home/user/bin/uname", 0x7ffceb817820) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/uname", 0x7ffceb817820) = -1 ENOENT (No such file or directory)
stat("/usr/bin/uname", {st_mode=S_IFREG|0755, st_size=39584, ...}) = 0
..."ದೋಷವನ್ನು ವರದಿ ಮಾಡುವ ಮೊದಲು ಕೊನೆಯ ವಿಫಲ ವಿನಂತಿ" ನಂತಹ ಹ್ಯೂರಿಸ್ಟಿಕ್ಸ್ ಸಂಬಂಧಿತ ದೋಷಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವಲ್ಲಿ ಉತ್ತಮವಾಗಿದೆ. ಅದು ಇರಲಿ, ಕೊನೆಯಿಂದಲೇ ಪ್ರಾರಂಭಿಸುವುದು ತಾರ್ಕಿಕವಾಗಿದೆ.
ಸಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಟ್ಯುಟೋರಿಯಲ್ ನಿಮಗೆ ಸಿಸ್ಟಮ್ ಕರೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಸಿ ಲೈಬ್ರರಿಗಳಿಗೆ ಪ್ರಮಾಣಿತ ಕರೆಗಳು ಸಿಸ್ಟಮ್ ಕರೆಗಳಲ್ಲ, ಆದರೆ ತೆಳುವಾದ ಮೇಲ್ಮೈ ಪದರ ಮಾತ್ರ. ಆದ್ದರಿಂದ, ಸಿ ಯಲ್ಲಿ ಹೇಗೆ ಮತ್ತು ಏನು ಮಾಡಬೇಕೆಂದು ನೀವು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಅರ್ಥಮಾಡಿಕೊಂಡರೆ, ಸಿಸ್ಟಮ್ ಕರೆ ಟ್ರೇಸ್ನ ಫಲಿತಾಂಶಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಿಮಗೆ ಸುಲಭವಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನೆಟ್‌ವರ್ಕ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಕರೆಗಳನ್ನು ಡೀಬಗ್ ಮಾಡುವಲ್ಲಿ ನಿಮಗೆ ತೊಂದರೆ ಇದೆ, ಅದೇ ಕ್ಲಾಸಿಕ್ ಅನ್ನು ನೋಡಿ .
ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಡೀಬಗ್ ಮಾಡುವ ಉದಾಹರಣೆ
ಸರಳ ಡೀಬಗ್ ಮಾಡುವಿಕೆಯ ಉದಾಹರಣೆಯು ಕೆಲಸ ಮಾಡುವಾಗ ನಾನು ಹೆಚ್ಚಾಗಿ ವ್ಯವಹರಿಸಬೇಕಾದ ಉದಾಹರಣೆಯಾಗಿದೆ ಎಂದು ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದೆ ಸ್ಟ್ರೇಸ್. ಆದಾಗ್ಯೂ, ಕೆಲವೊಮ್ಮೆ ನೈಜ ತನಿಖೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೆಚ್ಚು ಮುಂದುವರಿದ ಡೀಬಗ್ ಮಾಡುವಿಕೆಯ ನೈಜ-ಜೀವನದ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ.
- ಟಾಸ್ಕ್ ಪ್ರೊಸೆಸಿಂಗ್ ಶೆಡ್ಯೂಲರ್, *ನಿಕ್ಸ್ ಡೀಮನ್‌ನ ಮತ್ತೊಂದು ಅಳವಡಿಕೆ ಕ್ರಾನ್. ಇದನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಆದರೆ ಯಾರಾದರೂ ವೇಳಾಪಟ್ಟಿಯನ್ನು ಸಂಪಾದಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ಇದು ಸಂಭವಿಸುತ್ತದೆ:
# crontab -e -u logs
bcrontab: Fatal: Could not create temporary fileಸರಿ, ಅಂದರೆ bcron ನಿರ್ದಿಷ್ಟ ಫೈಲ್ ಅನ್ನು ಬರೆಯಲು ಪ್ರಯತ್ನಿಸಿದರು, ಆದರೆ ಅದು ಕೆಲಸ ಮಾಡಲಿಲ್ಲ ಮತ್ತು ಏಕೆ ಎಂದು ಅವನು ಒಪ್ಪಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಬಯಲಿಗೆಳೆಯುತ್ತಿದೆ ಸ್ಟ್ರೇಸ್:
# strace -o /tmp/trace crontab -e -u logs
bcrontab: Fatal: Could not create temporary file
# cat /tmp/trace
...
openat(AT_FDCWD, "bcrontab.14779.1573691864.847933", O_RDONLY) = 3
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f82049b4000
read(3, "#Ansible: logsaggn20 14 * * * lo"..., 8192) = 150
read(3, "", 8192) = 0
munmap(0x7f82049b4000, 8192) = 0
close(3) = 0
socket(AF_UNIX, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/bcron-spool"}, 110) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f82049b4000
write(3, "156:Slogs #Ansible: logsaggn20 1"..., 161) = 161
read(3, "32:ZCould not create temporary f"..., 8192) = 36
munmap(0x7f82049b4000, 8192) = 0
close(3) = 0
write(2, "bcrontab: Fatal: Could not creat"..., 49) = 49
unlink("bcrontab.14779.1573691864.847933") = 0
exit_group(111) = ?
+++ exited with 111 +++ಕೊನೆಯಲ್ಲಿ ಒಂದು ದೋಷ ಸಂದೇಶವಿದೆ ಬರೆಯಲು, ಆದರೆ ಈ ಬಾರಿ ಏನೋ ವಿಭಿನ್ನವಾಗಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ಯಾವುದೇ ಸಂಬಂಧಿತ ಸಿಸ್ಟಮ್ ಕರೆ ದೋಷವಿಲ್ಲ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಈ ಮೊದಲು ಸಂಭವಿಸುತ್ತದೆ. ಎರಡನೆಯದಾಗಿ, ಎಲ್ಲೋ ಯಾರಾದರೂ ಈಗಾಗಲೇ ದೋಷ ಸಂದೇಶವನ್ನು ಓದಿದ್ದಾರೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ನಿಜವಾದ ಸಮಸ್ಯೆ ಬೇರೆಡೆ ಇದೆ ಎಂದು ತೋರುತ್ತಿದೆ, ಮತ್ತು bcrontab ಸಂದೇಶವನ್ನು ಸರಳವಾಗಿ ಪ್ಲೇ ಮಾಡುತ್ತದೆ.
ನೀವು ನೋಡಿದರೆ ಮನುಷ್ಯ 2 ಓದಿದ್ದಾನೆ, ಮೊದಲ ಆರ್ಗ್ಯುಮೆಂಟ್ (3) ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಆಗಿರುವುದನ್ನು ನೀವು ನೋಡಬಹುದು, ಇದು *nix ಎಲ್ಲಾ I/O ಪ್ರಕ್ರಿಯೆಗೆ ಬಳಸುತ್ತದೆ. ಯಾವ ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ 3 ಪ್ರತಿನಿಧಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಹೇಗೆ? ಈ ನಿರ್ದಿಷ್ಟ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಚಲಾಯಿಸಬಹುದು ಸ್ಟ್ರೇಸ್ ಆಪರೇಟರ್ ಜೊತೆ -у (ಮೇಲೆ ನೋಡಿ) ಮತ್ತು ಇದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿಮಗೆ ತಿಳಿಸುತ್ತದೆ, ಆದರೆ ಈ ರೀತಿಯ ವಿಷಯವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು, ಫಲಿತಾಂಶಗಳನ್ನು ಹೇಗೆ ಓದುವುದು ಮತ್ತು ಪಾರ್ಸ್ ಮಾಡುವುದು ಎಂದು ತಿಳಿಯುವುದು ಉಪಯುಕ್ತವಾಗಿದೆ.
ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ನ ಮೂಲವು ಅನೇಕ ಸಿಸ್ಟಮ್ ಕರೆಗಳಲ್ಲಿ ಒಂದಾಗಿರಬಹುದು (ಇದು ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಯಾವುದಕ್ಕಾಗಿ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ - ಕನ್ಸೋಲ್, ನೆಟ್‌ವರ್ಕ್ ಸಾಕೆಟ್, ಫೈಲ್ ಸ್ವತಃ ಅಥವಾ ಇನ್ನೇನಾದರೂ), ಆದರೆ ಅದು ಇರಲಿ, ನಾವು ಹುಡುಕುತ್ತೇವೆ 3 ಅನ್ನು ಹಿಂತಿರುಗಿಸುವ ಮೂಲಕ ಕರೆಗಳು (ಅಂದರೆ ನಾವು ಟ್ರೇಸಿಂಗ್ ಫಲಿತಾಂಶಗಳಲ್ಲಿ "= 3" ಅನ್ನು ಹುಡುಕುತ್ತೇವೆ). ಈ ಫಲಿತಾಂಶದಲ್ಲಿ ಅವುಗಳಲ್ಲಿ 2 ಇವೆ: openat ಅತ್ಯಂತ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಮತ್ತು ಸಾಕೆಟ್ ಮಧ್ಯದಲ್ಲಿ. openat ಫೈಲ್ ತೆರೆಯುತ್ತದೆ ಆದರೆ ನಿಕಟ(3) ನಂತರ ಅದು ಮತ್ತೆ ಮುಚ್ಚುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. (ರೇಕ್: ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗಳನ್ನು ತೆರೆದಾಗ ಮತ್ತು ಮುಚ್ಚಿದಾಗ ಅವುಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಬಹುದು). ಕರೆ ಮಾಡಿ ಸಾಕೆಟ್ () ಸೂಕ್ತವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಮೊದಲು ಕೊನೆಯದು ಓದಿ (), ಮತ್ತು bcrontab ಸಾಕೆಟ್ ಮೂಲಕ ಏನಾದರೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಸಂಯೋಜಿತವಾಗಿದೆ ಎಂದು ಮುಂದಿನ ಸಾಲು ತೋರಿಸುತ್ತದೆ unix ಡೊಮೇನ್ ಸಾಕೆಟ್ ದಾರಿಯಲ್ಲಿ /var/run/bcron-spool.
ಆದ್ದರಿಂದ, ನಾವು ಸಂಬಂಧಿಸಿದ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು ಯುನಿಕ್ಸ್ ಸಾಕೆಟ್ ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ. ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ ಒಂದೆರಡು ಅಚ್ಚುಕಟ್ಟಾದ ತಂತ್ರಗಳಿವೆ, ಇವೆರಡೂ ಸರ್ವರ್ ನಿಯೋಜನೆಗಳನ್ನು ಡೀಬಗ್ ಮಾಡಲು ಉಪಯುಕ್ತವಾಗಿವೆ. ಮೊದಲನೆಯದು ಬಳಸುವುದು netstat ಅಥವಾ ಹೊಸದು ss (ಸಾಕೆಟ್ ಸ್ಥಿತಿ). ಎರಡೂ ಆಜ್ಞೆಗಳು ಸಿಸ್ಟಮ್‌ನ ಸಕ್ರಿಯ ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕಗಳನ್ನು ತೋರಿಸುತ್ತವೆ ಮತ್ತು ಹೇಳಿಕೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ -l ಆಲಿಸುವ ಸಾಕೆಟ್‌ಗಳನ್ನು ವಿವರಿಸಲು, ಹಾಗೆಯೇ ಆಪರೇಟರ್ -p ಕ್ಲೈಂಟ್‌ನಂತೆ ಸಾಕೆಟ್‌ಗೆ ಸಂಪರ್ಕಗೊಂಡಿರುವ ಪ್ರೋಗ್ರಾಂಗಳನ್ನು ಪ್ರದರ್ಶಿಸಲು. (ಇನ್ನೂ ಹಲವು ಉಪಯುಕ್ತ ಆಯ್ಕೆಗಳಿವೆ, ಆದರೆ ಈ ಕಾರ್ಯಕ್ಕೆ ಈ ಎರಡು ಸಾಕು.)
# ss -pl | grep /var/run/bcron-spool
u_str LISTEN 0 128 /var/run/bcron-spool 1466637 * 0 users:(("unixserver",pid=20629,fd=3))ಕೇಳುಗನು ಆಜ್ಞೆ ಎಂದು ಇದು ಸೂಚಿಸುತ್ತದೆ inixserver, ಪ್ರಕ್ರಿಯೆ ID 20629 ನೊಂದಿಗೆ ಚಾಲನೆಯಲ್ಲಿದೆ. (ಮತ್ತು, ಕಾಕತಾಳೀಯವಾಗಿ, ಇದು ಸಾಕೆಟ್ ಆಗಿ ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ 3 ಅನ್ನು ಬಳಸುತ್ತದೆ.)
ಅದೇ ಮಾಹಿತಿಯನ್ನು ಹುಡುಕಲು ಎರಡನೇ ನಿಜವಾಗಿಯೂ ಉಪಯುಕ್ತ ಸಾಧನವನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ lsof. ಇದು ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಎಲ್ಲಾ ತೆರೆದ ಫೈಲ್‌ಗಳನ್ನು (ಅಥವಾ ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗಳು) ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ಅಥವಾ ನೀವು ಒಂದು ನಿರ್ದಿಷ್ಟ ಫೈಲ್ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಬಹುದು:
# lsof /var/run/bcron-spool
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
unixserve 20629 cron 3u unix 0x000000005ac4bd83 0t0 1466637 /var/run/bcron-spool type=STREAMಪ್ರಕ್ರಿಯೆ 20629 ದೀರ್ಘಾವಧಿಯ ಸರ್ವರ್ ಆಗಿದೆ, ಆದ್ದರಿಂದ ನೀವು ಅದನ್ನು ಲಗತ್ತಿಸಬಹುದು ಸ್ಟ್ರೇಸ್ ಯಾವುದನ್ನಾದರೂ ಬಳಸುವುದು strace -o /tmp/trace -p 20629. ನೀವು ಇನ್ನೊಂದು ಟರ್ಮಿನಲ್‌ನಲ್ಲಿ ಕ್ರಾನ್ ಕೆಲಸವನ್ನು ಸಂಪಾದಿಸಿದರೆ, ನೀವು ದೋಷದೊಂದಿಗೆ ಟ್ರೇಸ್ ಔಟ್ಪುಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ. ಮತ್ತು ಫಲಿತಾಂಶ ಇಲ್ಲಿದೆ:
accept(3, NULL, NULL) = 4
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7faa47c44810) = 21181
close(4) = 0
accept(3, NULL, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21181, si_uid=998, si_status=0, si_utime=0, si_stime=0} ---
wait4(0, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG|WSTOPPED, NULL) = 21181
wait4(0, 0x7ffe6bc36764, WNOHANG|WSTOPPED, NULL) = -1 ECHILD (No child processes)
rt_sigaction(SIGCHLD, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, 8) = 0
rt_sigreturn({mask=[]}) = 43
accept(3, NULL, NULL) = 4
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7faa47c44810) = 21200
close(4) = 0
accept(3, NULL, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21200, si_uid=998, si_status=111, si_utime=0, si_stime=0} ---
wait4(0, [{WIFEXITED(s) && WEXITSTATUS(s) == 111}], WNOHANG|WSTOPPED, NULL) = 21200
wait4(0, 0x7ffe6bc36764, WNOHANG|WSTOPPED, NULL) = -1 ECHILD (No child processes)
rt_sigaction(SIGCHLD, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, 8) = 0
rt_sigreturn({mask=[]}) = 43
accept(3, NULL, NULL(ಕೊನೆಯ ಒಪ್ಪಿಕೊಳ್ಳಿ() ಪತ್ತೆಹಚ್ಚುವಾಗ ಪೂರ್ಣಗೊಳ್ಳುವುದಿಲ್ಲ.) ಮತ್ತೊಮ್ಮೆ, ದುರದೃಷ್ಟವಶಾತ್, ಈ ಫಲಿತಾಂಶವು ನಾವು ಹುಡುಕುತ್ತಿರುವ ದೋಷವನ್ನು ಹೊಂದಿಲ್ಲ. ಸಾಕೆಟ್‌ಗೆ bcrontag ಕಳುಹಿಸುವ ಅಥವಾ ಸ್ವೀಕರಿಸುವ ಯಾವುದೇ ಸಂದೇಶಗಳನ್ನು ನಾವು ನೋಡುವುದಿಲ್ಲ. ಬದಲಾಗಿ, ಸಂಪೂರ್ಣ ಪ್ರಕ್ರಿಯೆ ನಿಯಂತ್ರಣ (ಕ್ಲೋನ್, ನಿರೀಕ್ಷಿಸಿ 4, SIGCHLD ಇತ್ಯಾದಿ) ಈ ಪ್ರಕ್ರಿಯೆಯು ಮಗುವಿನ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹುಟ್ಟುಹಾಕುತ್ತದೆ, ಇದು ನೀವು ಊಹಿಸುವಂತೆ, ನಿಜವಾದ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತದೆ. ಮತ್ತು ನೀವು ಅವಳ ಜಾಡು ಹಿಡಿಯಬೇಕಾದರೆ, ಕರೆಗೆ ಸೇರಿಸಿ ಸ್ಟ್ರೇಸ್ -ಎಫ್. ನಾವು ಹೊಸ ಫಲಿತಾಂಶದಲ್ಲಿ ದೋಷ ಸಂದೇಶವನ್ನು ಸ್ಟ್ರೇಸ್‌ನೊಂದಿಗೆ ಹುಡುಕಿದಾಗ ಇದು ನಮಗೆ ಕಂಡುಬರುತ್ತದೆ -f -o /tmp/trace -p 20629:
21470 openat(AT_FDCWD, "tmp/spool.21470.1573692319.854640", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
21470 write(1, "32:ZCould not create temporary f"..., 36) = 36
21470 write(2, "bcron-spool[21470]: Fatal: logs:"..., 84) = 84
21470 unlink("tmp/spool.21470.1573692319.854640") = -1 ENOENT (No such file or directory)
21470 exit_group(111) = ?
21470 +++ exited with 111 +++ಈಗ, ಅದು ಏನೋ. ಪ್ರಕ್ರಿಯೆ 21470 ಪಾಥ್‌ನಲ್ಲಿ ಫೈಲ್ ಅನ್ನು ರಚಿಸಲು ಪ್ರಯತ್ನಿಸುವಾಗ "ಪ್ರವೇಶ ನಿರಾಕರಿಸಲಾಗಿದೆ" ದೋಷವನ್ನು ಪಡೆಯುತ್ತದೆ tmp/spool.21470.1573692319.854640 (ಪ್ರಸ್ತುತ ಕೆಲಸ ಮಾಡುವ ಡೈರೆಕ್ಟರಿಗೆ ಸಂಬಂಧಿಸಿದೆ). ಪ್ರಸ್ತುತ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಡೈರೆಕ್ಟರಿಯನ್ನು ನಾವು ತಿಳಿದಿದ್ದರೆ, ನಾವು ಸಂಪೂರ್ಣ ಮಾರ್ಗವನ್ನು ಸಹ ತಿಳಿದಿರುತ್ತೇವೆ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯು ಅದರ ತಾತ್ಕಾಲಿಕ ಫೈಲ್ ಅನ್ನು ಏಕೆ ರಚಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ದುರದೃಷ್ಟವಶಾತ್, ಪ್ರಕ್ರಿಯೆಯು ಈಗಾಗಲೇ ನಿರ್ಗಮಿಸಿದೆ, ಆದ್ದರಿಂದ ನೀವು ಕೇವಲ ಬಳಸಲಾಗುವುದಿಲ್ಲ lsof -p 21470 ಪ್ರಸ್ತುತ ಡೈರೆಕ್ಟರಿಯನ್ನು ಹುಡುಕಲು, ಆದರೆ ನೀವು ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿ ಕೆಲಸ ಮಾಡಬಹುದು - ಡೈರೆಕ್ಟರಿಯನ್ನು ಬದಲಾಯಿಸುವ PID 21470 ಸಿಸ್ಟಮ್ ಕರೆಗಳಿಗಾಗಿ ನೋಡಿ. (ಯಾವುದೇ ಇಲ್ಲದಿದ್ದರೆ, PID 21470 ಅವುಗಳನ್ನು ಅದರ ಪೋಷಕರಿಂದ ಆನುವಂಶಿಕವಾಗಿ ಪಡೆದಿರಬೇಕು ಮತ್ತು ಇದು ಈಗಾಗಲೇ lsof -p ಕಂಡುಹಿಡಿಯಲು ಸಾಧ್ಯವಿಲ್ಲ.) ಈ ಸಿಸ್ಟಮ್ ಕರೆ chdir (ಆಧುನಿಕ ಆನ್‌ಲೈನ್ ಸರ್ಚ್ ಇಂಜಿನ್‌ಗಳ ಸಹಾಯದಿಂದ ಕಂಡುಹಿಡಿಯುವುದು ಸುಲಭ). ಮತ್ತು ಟ್ರೇಸ್ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ರಿವರ್ಸ್ ಹುಡುಕಾಟಗಳ ಫಲಿತಾಂಶ ಇಲ್ಲಿದೆ, ಸರ್ವರ್ PID 20629 ಗೆ ಎಲ್ಲಾ ರೀತಿಯಲ್ಲಿ:
20629 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7faa47c44810) = 21470
...
21470 execve("/usr/sbin/bcron-spool", ["bcron-spool"], 0x55d2460807e0 /* 27 vars */) = 0
...
21470 chdir("/var/spool/cron") = 0
...
21470 openat(AT_FDCWD, "tmp/spool.21470.1573692319.854640", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
21470 write(1, "32:ZCould not create temporary f"..., 36) = 36
21470 write(2, "bcron-spool[21470]: Fatal: logs:"..., 84) = 84
21470 unlink("tmp/spool.21470.1573692319.854640") = -1 ENOENT (No such file or directory)
21470 exit_group(111) = ?
21470 +++ exited with 111 +++(ನೀವು ಕಳೆದುಹೋದರೆ, ನೀವು ನನ್ನ ಹಿಂದಿನ ಪೋಸ್ಟ್ ಅನ್ನು ಓದಲು ಬಯಸಬಹುದು .) ಆದ್ದರಿಂದ, ಸರ್ವರ್ PID 20629 ಮಾರ್ಗದಲ್ಲಿ ಫೈಲ್ ರಚಿಸಲು ಅನುಮತಿಯನ್ನು ಸ್ವೀಕರಿಸಲಿಲ್ಲ /var/spool/cron/tmp/spool.21470.1573692319.854640. ಹೆಚ್ಚಾಗಿ, ಇದಕ್ಕೆ ಕಾರಣವೆಂದರೆ ಕ್ಲಾಸಿಕ್ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನುಮತಿ ಸೆಟ್ಟಿಂಗ್ಗಳು. ಪರಿಶೀಲಿಸೋಣ:
# ls -ld /var/spool/cron/tmp/
drwxr-xr-x 2 root root 4096 Nov 6 05:33 /var/spool/cron/tmp/
# ps u -p 20629
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
cron 20629 0.0 0.0 2276 752 ? Ss Nov14 0:00 unixserver -U /var/run/bcron-spool -- bcron-spoolಅಲ್ಲಿಯೇ ನಾಯಿಯನ್ನು ಸಮಾಧಿ ಮಾಡಲಾಗಿದೆ! ಸರ್ವರ್ ಬಳಕೆದಾರರ ಕ್ರಾನ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಡೈರೆಕ್ಟರಿಗೆ ಬರೆಯಲು ರೂಟ್ ಮಾತ್ರ ಅನುಮತಿಯನ್ನು ಹೊಂದಿದೆ /var/spool/cron/tmp/. ಸರಳ ಆಜ್ಞೆ ಚೌನ್ ಕ್ರಾನ್ /var/spool/cron/tmp/ ಒತ್ತಾಯಿಸುತ್ತದೆ bcron ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಿ. (ಅದು ಸಮಸ್ಯೆಯಾಗಿಲ್ಲದಿದ್ದರೆ, ಮುಂದಿನ ಶಂಕಿತವು SELinux ಅಥವಾ AppArmor ನಂತಹ ಕರ್ನಲ್ ಭದ್ರತಾ ಮಾಡ್ಯೂಲ್ ಆಗಿರುತ್ತದೆ, ಹಾಗಾಗಿ ನಾನು ಕರ್ನಲ್ ಸಂದೇಶ ಲಾಗ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇನೆ dmesg.)
ಒಟ್ಟು
ಸಿಸ್ಟಂ ಕರೆ ಟ್ರೇಸ್‌ಗಳು ಹರಿಕಾರರಿಗೆ ಅಗಾಧವಾಗಿರಬಹುದು, ಆದರೆ ಸಾಮಾನ್ಯ ನಿಯೋಜನೆ ಸಮಸ್ಯೆಗಳ ಸಂಪೂರ್ಣ ವರ್ಗವನ್ನು ಡೀಬಗ್ ಮಾಡಲು ಅವು ತ್ವರಿತ ಮಾರ್ಗವೆಂದು ನಾನು ತೋರಿಸಿದ್ದೇನೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಬಹುಪ್ರಕ್ರಿಯೆಯನ್ನು ಡೀಬಗ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವುದನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ bcronಹಂತ-ಹಂತದ ಡೀಬಗರ್ ಅನ್ನು ಬಳಸುವುದು.
ಸಿಸ್ಟಂ ಕರೆ ಸರಪಳಿಯ ಉದ್ದಕ್ಕೂ ಟ್ರೇಸ್ ಫಲಿತಾಂಶಗಳನ್ನು ಹಿಮ್ಮುಖವಾಗಿ ಪಾರ್ಸಿಂಗ್ ಮಾಡಲು ಕೌಶಲ್ಯದ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದರೆ ನಾನು ಹೇಳಿದಂತೆ, ಯಾವಾಗಲೂ ಬಳಸುವುದು ಸ್ಟ್ರೇಸ್, ನಾನು ಟ್ರೇಸ್ ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯುತ್ತೇನೆ ಮತ್ತು ಅಂತ್ಯದಿಂದ ಪ್ರಾರಂಭವಾಗುವ ದೋಷಗಳನ್ನು ಹುಡುಕುತ್ತೇನೆ. ಹೇಗಾದರೂ, ಸ್ಟ್ರೇಸ್ ಡೀಬಗ್ ಮಾಡುವಲ್ಲಿ ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಉಳಿಸಲು ನನಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಇದು ನಿಮಗೂ ಉಪಯುಕ್ತವಾಗಲಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ಮೂಲ: www.habr.com