स्ट्रेससह डीबगिंग सॉफ्टवेअर उपयोजन

माझे दिवसाचे काम बहुतेक सॉफ्टवेअर उपयोजन आहे, याचा अर्थ मी यासारख्या प्रश्नांची उत्तरे देण्यासाठी बराच वेळ घालवतो:

• हे सॉफ्टवेअर विकसकासाठी कार्य करते, परंतु माझ्यासाठी नाही. का?
• काल या सॉफ्टवेअरने माझ्यासाठी काम केले, परंतु आज ते नाही. का?

हे एक प्रकारचे डीबगिंग आहे जे नियमित सॉफ्टवेअर डीबगिंगपेक्षा थोडे वेगळे आहे. रेग्युलर डीबगिंग हे कोडच्या लॉजिकबद्दल असते, परंतु डिप्लॉयमेंट डीबगिंग कोड आणि पर्यावरण यांच्यातील परस्परसंवादाबद्दल असते. जरी समस्येचे मूळ तार्किक त्रुटी असले तरीही, सर्व काही एका मशीनवर कार्य करते आणि दुसर्‍यावर नाही याचा अर्थ असा होतो की समस्या कोणत्या तरी वातावरणात आहे.

त्यामुळे नेहमीच्या डीबगिंग टूल्सऐवजी जसे जीडीबी माझ्याकडे डीबगिंग डिप्लॉयमेंटसाठी टूल्सचा एक वेगळा संच आहे. आणि "हे सॉफ्टवेअर माझ्यासाठी का काम करत नाही?" सारख्या समस्येला सामोरे जाण्यासाठी माझे आवडते साधन. म्हणतात स्ट्रेस.

स्ट्रेस म्हणजे काय?

स्ट्रेस "सिस्टम कॉल ट्रेसिंग" साठी एक साधन आहे. हे मूळतः लिनक्ससाठी तयार केले गेले होते, परंतु त्याच डीबगिंग युक्त्या इतर सिस्टमसाठी साधनांसह केल्या जाऊ शकतात (डीट्रेस किंवा ktrace).

मूलभूत अनुप्रयोग खूप सोपे आहे. तुम्हाला फक्त कोणत्याही कमांडसह स्ट्रेस चालवणे आवश्यक आहे आणि ते सर्व सिस्टम कॉल डंप करेल (जरी प्रथम तुम्हाला ते स्वतः स्थापित करावे लागेल. स्ट्रेस):

$ 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
• प्रक्रिया थ्रेडचे जीवनकाळ व्यवस्थापित करणे
• निम्न-स्तरीय मेमरी व्यवस्थापन
• विशिष्ट डिव्हाइस ड्रायव्हर्समध्ये प्रवेश

स्ट्रेस कधी वापरायचे?

सिद्धांतामध्ये, स्ट्रेस वापरकर्ता स्पेसमधील कोणत्याही प्रोग्रामसह वापरले जाते, कारण वापरकर्ता स्पेसमधील कोणत्याही प्रोग्रामने सिस्टम कॉल करणे आवश्यक आहे. हे संकलित, निम्न-स्तरीय प्रोग्रामसह अधिक कार्यक्षमतेने कार्य करते, परंतु आपण रनटाइम आणि इंटरप्रिटरमधून अतिरिक्त आवाज कमी करू शकत असल्यास पायथन सारख्या उच्च-स्तरीय भाषांसह देखील कार्य करते.

सर्व वैभवात स्ट्रेस सॉफ्टवेअरच्या डीबगिंग दरम्यान स्वतःला प्रकट करते जे एका मशीनवर चांगले कार्य करते, परंतु अचानक दुसर्‍या मशीनवर कार्य करणे थांबवते, फायली, परवानग्या किंवा काही आदेश किंवा इतर गोष्टी अंमलात आणण्याच्या अयशस्वी प्रयत्नांबद्दल अस्पष्ट संदेश तयार करते... ही खेदाची गोष्ट आहे, परंतु तसे होत नाही प्रमाणपत्र पडताळणी त्रुटींसारख्या उच्च-स्तरीय समस्यांसह चांगले एकत्र करा. सहसा यासाठी संयोजन आवश्यक असते स्ट्रेस, कधीकधी ltrace आणि उच्च स्तरीय साधने (जसे कमांड लाइन टूल openssl प्रमाणपत्र डीबग करण्यासाठी).

आम्ही उदाहरण म्हणून स्टँडअलोन सर्व्हर वापरू, परंतु सिस्टम कॉल ट्रेसिंग अधिक जटिल उपयोजन प्लॅटफॉर्मवर केले जाऊ शकते. आपल्याला फक्त योग्य साधने निवडण्याची आवश्यकता आहे.

साधे डीबगिंग उदाहरण

समजा तुम्हाला अप्रतिम सर्व्हर ऍप्लिकेशन foo चालवायचे आहे, आणि तुम्ही हेच संपवाल:

$ 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 +++

आउटपुटचे अंदाजे संपूर्ण प्रथम पृष्ठ स्ट्रेस - ही सहसा लॉन्चसाठी निम्न-स्तरीय तयारी असते. (खूप कॉल्स mmap, mpprotect, क्विल कमी-स्तरीय मेमरी शोधणे आणि डायनॅमिक लायब्ररी प्रदर्शित करणे यासारख्या गोष्टींसाठी.) वास्तविक, आउटपुट डीबग करताना स्ट्रेस अगदी शेवटून वाचणे चांगले. खाली एक आव्हान असेल लिहू, जे त्रुटी संदेश प्रदर्शित करते. आम्ही वर पाहतो आणि पहिला चुकीचा सिस्टम कॉल पाहतो - कॉल उघडणे, जे एरर टाकते ENOENT (“फाइल किंवा निर्देशिका सापडली नाही”) उघडण्याचा प्रयत्न करत आहे /etc/foo/config.json. येथे कॉन्फिगरेशन फाइल असावी.

हे फक्त एक उदाहरण होते, परंतु मी वापरत असलेल्या वेळेपैकी 90% म्हणेन स्ट्रेस, यापेक्षा जास्त कठीण काहीही नाही. खाली एक संपूर्ण चरण-दर-चरण डीबगिंग मार्गदर्शक आहे:

• प्रोग्राममधील सिस्टम-वाय त्रुटीबद्दल अस्पष्ट संदेशामुळे अस्वस्थ व्हा
• सह प्रोग्राम रीस्टार्ट करा स्ट्रेस
• ट्रेस परिणामांमध्ये त्रुटी संदेश शोधा
• तुम्ही पहिला अयशस्वी सिस्टम कॉल दाबेपर्यंत वर जा

स्टेप 4 मधील सिस्टम कॉलमध्ये काय चूक झाली हे उघड होण्याची शक्यता आहे.

इशारे

तुम्हाला अधिक जटिल डीबगिंगचे उदाहरण दाखवण्यापूर्वी, मी तुम्हाला प्रभावी वापरासाठी काही युक्त्या दाखवतो स्ट्रेस:

माणूस तुमचा मित्र आहे

बर्‍याच *nix सिस्टीमवर, कर्नलला सिस्टम कॉल्सची संपूर्ण यादी रन करून मिळवता येते माणूस syscalls. सारख्या गोष्टी तुम्हाला दिसतील 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, हे त्याचे ट्रेसिंग सक्षम करेल. याचे नकारात्मक बाजू म्हणजे आउटपुट तुम्हाला आणखी गोंधळात टाकेल. कधी स्ट्रेस एक प्रक्रिया किंवा एक थ्रेड ट्रेस करते, ते कॉल इव्हेंट्सचा एकच प्रवाह दर्शविते. जेव्हा ते एकाच वेळी अनेक प्रक्रियांचा मागोवा घेते, तेव्हा तुम्हाला संदेशाद्वारे व्यत्यय आलेल्या कॉलची सुरुवात दिसेल , नंतर - इतर अंमलबजावणी शाखांसाठी कॉलचा एक समूह आणि त्यानंतरच - पहिल्याचा शेवट <…foocal पुन्हा सुरू>. किंवा ऑपरेटर वापरून सर्व ट्रेस परिणाम वेगवेगळ्या फायलींमध्ये विभाजित करा -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
...

संबंधित त्रुटी शोधण्यात "एररचा अहवाल देण्यापूर्वी शेवटची अयशस्वी विनंती" सारखी ह्युरिस्टिक्स चांगली आहेत. ते जसे असो, अगदी शेवटपासून सुरुवात करणे तर्कसंगत आहे.

सी प्रोग्रामिंग ट्यूटोरियल तुम्हाला सिस्टम कॉल्स समजण्यास मदत करू शकतात.

सी लायब्ररींना केलेले मानक कॉल्स हे सिस्टीम कॉल्स नसतात, तर फक्त पातळ पृष्ठभाग असतात. म्हणून, C मध्ये कसे आणि काय करावे हे आपण थोडेसे समजून घेतल्यास, सिस्टम कॉल ट्रेसचे परिणाम समजून घेणे आपल्यासाठी सोपे होईल. उदाहरणार्थ, तुम्हाला नेटवर्क सिस्टमवर कॉल डीबग करण्यात समस्या येत आहे, समान क्लासिक पहा नेटवर्क प्रोग्रामिंगसाठी बिजाचे मार्गदर्शक.

एक अधिक जटिल डीबगिंग उदाहरण

मी आधीच सांगितले आहे की साध्या डीबगिंगचे उदाहरण हे एक उदाहरण आहे जे मला काम करताना मुख्यतः सामोरे जावे लागते स्ट्रेस. तथापि, काहीवेळा प्रत्यक्ष तपासणी आवश्यक असते, म्हणून येथे अधिक प्रगत डीबगिंगचे वास्तविक-जीवन उदाहरण आहे.

bcron - टास्क प्रोसेसिंग शेड्यूलर, *निक्स डिमनची दुसरी अंमलबजावणी क्रोन. हे सर्व्हरवर स्थापित केले आहे, परंतु जेव्हा कोणीतरी वेळापत्रक संपादित करण्याचा प्रयत्न करते, तेव्हा असे होते:

# 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 आहेत: उघडणे अगदी शीर्षस्थानी आणि सॉकेट मध्ये. उघडणे फाइल उघडते पण बंद(3) नंतर ते पुन्हा बंद झाल्याचे दर्शवेल. (रेक: फाईल डिस्क्रिप्टर्स उघडले आणि बंद केल्यावर पुन्हा वापरले जाऊ शकतात). कॉल करा सॉकेट () योग्य कारण ते आधीचे शेवटचे आहे वाचा(), आणि असे दिसून आले की bcrontab सॉकेटद्वारे काहीतरी कार्य करते. पुढील ओळ दर्शवते की फाइल वर्णनकर्ता संबद्ध आहे युनिक्स डोमेन सॉकेट वाटेत /var/run/bcron-sool.

म्हणून, आम्हाला संबंधित प्रक्रिया शोधण्याची आवश्यकता आहे युनिक्स सॉकेट दुसऱ्या बाजूला. या उद्देशासाठी दोन नीट युक्त्या आहेत, त्या दोन्ही सर्व्हर उपयोजन डीबग करण्यासाठी उपयुक्त आहेत. प्रथम वापरणे आहे नेटस्टॅट किंवा नवीन 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, प्रोसेस आयडी 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 इ.) ही प्रक्रिया बाल प्रक्रियेला जन्म देते, जी तुमच्या अंदाजाप्रमाणे खरे काम करते. आणि जर तुम्हाला तिचा माग पकडायचा असेल तर कॉलमध्ये जोडा strace -f. जेव्हा आपण नवीन निकालात स्ट्रेससह त्रुटी संदेश शोधतो तेव्हा आपल्याला हेच सापडेल -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/sool.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/sool/cron/tmp/sool.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/sool/cron/tmp/. साधी आज्ञा chown cron /var/spool/cron/tmp/ सक्ती करेल bcron योग्यरित्या कार्य करा. (जर ही समस्या नसेल, तर पुढील बहुधा संशयित SELinux किंवा AppArmor सारखे कर्नल सुरक्षा मॉड्यूल आहे, म्हणून मी कर्नल संदेश लॉग तपासू. dmesg.)

एकूण

सिस्टीम कॉल ट्रेस नवशिक्यासाठी जबरदस्त असू शकतात, परंतु मला आशा आहे की मी दर्शविले आहे की ते सामान्य उपयोजन समस्यांचा संपूर्ण वर्ग डीबग करण्याचा एक द्रुत मार्ग आहे. मल्टीप्रोसेस डीबग करण्याचा प्रयत्न करण्याची कल्पना करा bcronचरण-दर-चरण डीबगर वापरणे.

सिस्टम कॉल चेनच्या बाजूने ट्रेस निकालांचे विश्लेषण करण्यासाठी कौशल्य आवश्यक आहे, परंतु मी म्हटल्याप्रमाणे, जवळजवळ नेहमीच, वापरणे स्ट्रेस, मला फक्त ट्रेस परिणाम मिळतो आणि शेवटपासून सुरू होणाऱ्या त्रुटी शोधतो. असो, स्ट्रेस मला डीबगिंगवर बराच वेळ वाचविण्यात मदत करते. मला आशा आहे की ते तुम्हाला देखील उपयुक्त ठरेल.

स्त्रोत: www.habr.com