🥇Strace के साथ सॉफ्टवेयर परिनियोजन डिबगिंग

स्ट्रेस के साथ डिबगिंग सॉफ़्टवेयर परिनियोजन

मेरा दैनिक कार्य मुख्यतः सॉफ्टवेयर सिस्टम स्थापित करना है, जिसका अर्थ है कि मैं इन जैसे प्रश्नों के उत्तर देने में बहुत समय व्यतीत करता हूँ:

डेवलपर के पास यह सॉफ़्टवेयर काम कर रहा है, लेकिन मेरे पास नहीं है। क्यों?
कल यह सॉफ्टवेयर मेरे लिए काम कर रहा था, लेकिन आज नहीं। क्यों?

यह एक तरह की डिबगिंग है जो नियमित सॉफ़्टवेयर डिबगिंग से थोड़ी अलग है। नियमित डिबगिंग कोड के तर्क के बारे में है, लेकिन परिनियोजन डिबगिंग कोड और पर्यावरण की बातचीत के बारे में है। भले ही समस्या की जड़ एक तार्किक त्रुटि हो, लेकिन यह तथ्य कि सब कुछ एक मशीन पर काम करता है और दूसरे पर नहीं, इसका मतलब है कि समस्या किसी तरह पर्यावरण में है।

इसलिए सामान्य डिबगिंग टूल जैसे जी.डी.बी. मेरे पास डिप्लॉयमेंट को डीबग करने के लिए उपकरणों का एक और सेट है। और "यह सॉफ़्टवेयर मेरे लिए काम क्यों नहीं कर रहा है?" समस्या से निपटने के लिए मेरा पसंदीदा उपकरण है स्ट्रेस.

स्ट्रेस क्या है?

स्ट्रेस — यह "सिस्टम कॉल ट्रेसिंग" के लिए एक उपकरण है। इसे मूल रूप से इसके अंतर्गत बनाया गया था। Linuxलेकिन अन्य प्रणालियों के लिए उपकरणों के साथ भी यही डिबगिंग तरकीबें अपनाई जा सकती हैं (DTrace या केट्रेस).

बुनियादी उपयोग बहुत सरल है। आपको बस किसी भी कमांड के साथ strace चलाने की ज़रूरत है और यह सभी सिस्टम कॉल को डंप कर देगा (हालाँकि आपको शायद इसे पहले खुद इंस्टॉल करना होगा)। स्ट्रेस):

$ 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 चलाना चाहते हैं, और आपको यह मिलता है:

$ 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, mप्रोटेक्ट, नि: निम्न-स्तरीय मेमोरी डिटेक्शन और डायनेमिक लाइब्रेरी मैपिंग जैसी चीज़ों के लिए।) वास्तव में, डिबगिंग करते समय, आउटपुट स्ट्रेस अंत से पढ़ना बेहतर है। नीचे एक चुनौती होगी लिखना, जो एक त्रुटि संदेश प्रदर्शित करता है। ऊपर देखने पर, हम पहली त्रुटिपूर्ण सिस्टम कॉल देखते हैं - कॉल openat, त्रुटि दे रहा है ENOENT ("फ़ाइल या निर्देशिका नहीं मिली") खोलने का प्रयास कर रहा हूँ /etc/foo/config.jsonयह वह स्थान है जहां कॉन्फ़िगरेशन फ़ाइल होनी चाहिए।

यह तो सिर्फ एक उदाहरण था, लेकिन मैं कहूंगा कि 90% समय मैं इसका उपयोग करता हूं स्ट्रेस, इससे ज़्यादा जटिल कुछ भी नहीं है। नीचे डीबगिंग के लिए एक संपूर्ण चरण-दर-चरण मार्गदर्शिका दी गई है:

प्रोग्राम से अस्पष्ट सिस्टम-वाई त्रुटि संदेश से निराश
प्रोग्राम को पुनः प्रारंभ करें स्ट्रेस
ट्रेस परिणामों में त्रुटि संदेश ढूंढें
जब तक आप पहली असफल सिस्टम कॉल तक नहीं पहुंच जाते, तब तक ऊपर जाएं

यह बहुत संभव है कि चरण 4 में सिस्टम कॉल यह बता देगा कि क्या गलत हुआ।

टिप्स

इससे पहले कि मैं आपको अधिक जटिल डिबगिंग उदाहरण दिखाऊं, मैं आपको इसे प्रभावी ढंग से उपयोग करने के लिए कुछ तरकीबें दिखाऊंगा। स्ट्रेस:

आदमी तुम्हारा दोस्त है

कई *nix प्रणालियों पर, कर्नेल के लिए सिस्टम कॉल की पूरी सूची चलाकर प्राप्त की जा सकती है मैन सिस्टम कॉल.आप इस तरह की चीजें देखेंगे बीआरके(2), जिसका अर्थ है कि चलाकर अधिक जानकारी प्राप्त की जा सकती है आदमी 2 बीआरके.

छोटी-मोटी खामियां: आदमी 2 कांटा मुझे शेल के लिए पृष्ठ दिखाता है कांटा() в जीएनयू libc, जो, यह पता चला है, कॉल करके कार्यान्वित किया जाता है क्लोन (). कॉल शब्दार्थ कांटा यदि आप ऐसा प्रोग्राम लिखते हैं जो इसका उपयोग करता है तो वही रहता है कांटा(), और ट्रेस चलाएँ - मुझे कोई कॉल नहीं मिलेगी कांटा, उनके स्थान पर होगा क्लोन ()ऐसे रेक केवल तभी भ्रमित करते हैं जब आप स्रोत की तुलना आउटपुट से करने लगते हैं स्ट्रेस.

आउटपुट को फ़ाइल में सहेजने के लिए -o का प्रयोग करें।

स्ट्रेस बहुत सारा आउटपुट उत्पन्न कर सकता है, इसलिए ट्रेस परिणामों को अलग-अलग फ़ाइलों में संग्रहीत करना अक्सर उपयोगी होता है (जैसा कि ऊपर दिए गए उदाहरण में है)। यह प्रोग्राम आउटपुट और के बीच अंतर करने में भी मदद करता है स्ट्रेस कंसोल में.

अधिक तर्क डेटा देखने के लिए -s का उपयोग करें.

आपने देखा होगा कि त्रुटि संदेश का दूसरा भाग ऊपर दिए गए उदाहरण ट्रेस में नहीं दिखाया गया है। ऐसा इसलिए है क्योंकि स्ट्रेस डिफ़ॉल्ट रूप से यह स्ट्रिंग तर्क के केवल पहले 32 बाइट्स दिखाता है। यदि आप और देखना चाहते हैं, तो कुछ इस तरह जोड़ें -एस 128 चुनौती के लिए स्ट्रेस.

- फाइलों, सॉकेट्स आदि को ट्रैक करना आसान बनाता है।

"सब कुछ एक फ़ाइल है" का अर्थ है कि *nix सिस्टम फ़ाइल डिस्क्रिप्टर का उपयोग करके सभी I/O निष्पादित करते हैं, चाहे वह फ़ाइल हो या नेटवर्क या इंटरप्रोसेस पाइप। यह प्रोग्रामिंग के लिए सुविधाजनक है, लेकिन जब आप जेनेरिक देखते हैं तो यह देखना मुश्किल हो जाता है कि वास्तव में क्या हो रहा है पढ़ना и लिखना सिस्टम कॉल ट्रेस परिणामों में.

ऑपरेटर जोड़कर -वाई, आप मजबूर करेंगे स्ट्रेस आउटपुट में प्रत्येक फ़ाइल डिस्क्रिप्टर को इस बात के साथ एनोटेट करें कि वह किस ओर इंगित करता है।

-p** के साथ पहले से चल रही प्रक्रिया से जुड़ें

जैसा कि आप नीचे दिए गए उदाहरण से देखेंगे, कभी-कभी आप पहले से चल रहे प्रोग्राम को ट्रेस करना चाहते हैं। यदि आप जानते हैं कि यह प्रक्रिया 1337 के रूप में चल रहा है (मान लीजिए, आउटपुट से ps), तो आप इसे इस तरह से ट्रेस कर सकते हैं:

$ strace -p 1337
...system call trace output...

आपको रूट एक्सेस की आवश्यकता हो सकती है.

चाइल्ड प्रोसेस की निगरानी के लिए -f का उपयोग करें

स्ट्रेस डिफ़ॉल्ट रूप से, यह केवल एक प्रक्रिया का पता लगाता है। यदि वह प्रक्रिया चाइल्ड प्रक्रियाओं को जन्म देती है, तो आप चाइल्ड प्रक्रिया को जन्म देने के लिए सिस्टम कॉल देख सकते हैं, लेकिन चाइल्ड प्रक्रिया की सिस्टम कॉल प्रदर्शित नहीं होगी।

यदि आपको लगता है कि त्रुटि चाइल्ड प्रोसेस में है, तो ऑपरेटर का उपयोग करें -f, इससे इसकी ट्रेसिंग सक्षम हो जाएगी। इसका नकारात्मक पक्ष यह है कि आउटपुट आपको और भी अधिक भ्रमित करेगा। स्ट्रेस किसी एकल प्रक्रिया या थ्रेड का पता लगाता है, तो यह कॉल ईवेंट का एकल प्रवाह दिखाता है। जब यह एक साथ कई प्रक्रियाओं का पता लगाता है, तो आप किसी संदेश द्वारा बाधित कॉल की शुरुआत देख सकते हैं , फिर निष्पादन की अन्य शाखाओं के लिए कॉल का एक गुच्छा, और उसके बाद ही पहले का अंत <… फ़ूकॉल फिर से शुरू>या ऑपरेटर का उपयोग करके सभी ट्रेस परिणामों को अलग-अलग फ़ाइलों में विभाजित करें। -एफएफ (विवरण यहां देखें) मार्गदर्शक पर स्ट्रेस).

ट्रेस को -e से फ़िल्टर करें

जैसा कि आप देख सकते हैं, ट्रेस परिणाम सभी संभावित सिस्टम कॉल का एक वास्तविक ढेर है। -e आप ट्रेस को फ़िल्टर कर सकते हैं (देखें नेतृत्व पर स्ट्रेस) मुख्य लाभ यह है कि फ़िल्टरिंग के साथ ट्रेस चलाना पूर्ण ट्रेस करने और फिर फ़िल्टरिंग करने की तुलना में तेज़ है। ग्रेपईमानदारी से कहूं तो, मुझे लगभग हमेशा परवाह नहीं होती।

सभी गलतियाँ बुरी नहीं होतीं

एक सरल और सामान्य उदाहरण एक प्रोग्राम है जो एक ही समय में कई स्थानों पर एक फ़ाइल खोजता है, जैसे एक शेल जो निष्पादन योग्य फ़ाइल वाली निर्देशिका को खोजता है:

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

"त्रुटि संदेश से पहले अंतिम विफल अनुरोध" जैसे अनुमान प्रासंगिक त्रुटियों को खोजने के लिए अच्छे हैं। हालाँकि, अंत से शुरू करना तर्कसंगत है।

सिस्टम कॉल को समझने के लिए सी प्रोग्रामिंग गाइड एक अच्छी जगह है।

सी लाइब्रेरी के लिए मानक कॉल सिस्टम कॉल नहीं हैं, बल्कि केवल एक पतली सतह परत है। इसलिए यदि आप कम से कम थोड़ा सा समझते हैं कि सी में कैसे और क्या करना है, तो आपको सिस्टम कॉल ट्रेस के परिणामों को समझना आसान लगेगा। उदाहरण के लिए, यदि आपको नेटवर्क सिस्टम पर कॉल डिबग करने में परेशानी होती है, तो उसी क्लासिक को देखें बिज द्वारा "नेटवर्क प्रोग्रामिंग के लिए एक गाइड".

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

मैंने पहले ही कहा कि सरल डिबगिंग उदाहरण एक उदाहरण है कि मुझे काम करते समय ज्यादातर क्या करना पड़ता है स्ट्रेसहालांकि, कभी-कभी वास्तविक जांच की आवश्यकता होती है, इसलिए यहां डिबगिंग का एक वास्तविक उदाहरण दिया गया है जो अधिक जटिल है।

बी.सी.आर.ओ.एन. — कार्य अनुसूचक, *nix डेमॉन का एक और कार्यान्वयन क्रॉनयह सर्वर पर स्थापित है, लेकिन जब कोई शेड्यूल को संपादित करने का प्रयास करता है, तो यह होता है:

# crontab -e -u logs
bcrontab: Fatal: Could not create temporary file

अच्छा तब, बी.सी.आर.ओ.एन. एक निश्चित फ़ाइल लिखने की कोशिश की, लेकिन वह असफल रहा, और वह यह भी नहीं बताएगा कि ऐसा क्यों हुआ। चलिए इसे खोलते हैं स्ट्रेस:

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

बिल्कुल अंत में एक त्रुटि संदेश है लिखना, लेकिन इस बार कुछ चीजें अलग हैं। सबसे पहले, कोई प्रासंगिक सिस्टम कॉल त्रुटि नहीं है, जो आमतौर पर इससे पहले होती है। दूसरा, यह स्पष्ट है कि कहीं न कहीं, किसी ने पहले ही त्रुटि संदेश पढ़ लिया है। ऐसा लगता है कि असली समस्या कहीं और है, और बक्रोंटैब बस संदेश चलाता है.

अगर आप देखें आदमी 2 पढ़ा, आप देख सकते हैं कि पहला तर्क (3) एक फ़ाइल डिस्क्रिप्टर है, जिसका उपयोग *nix सभी I/O प्रोसेसिंग के लिए करता है। आप कैसे पता लगाएँगे कि फ़ाइल डिस्क्रिप्टर 3 क्या दर्शाता है? इस विशेष मामले में, आप चला सकते हैं स्ट्रेस ऑपरेटर के साथ -वाई (ऊपर देखें), और यह आपको स्वचालित रूप से बता देगा, हालांकि, इस तरह की चीजों का पता लगाने के लिए, यह जानना उपयोगी है कि ट्रेस परिणामों को कैसे पढ़ा और विश्लेषण किया जाए।

फ़ाइल डिस्क्रिप्टर का स्रोत कई सिस्टम कॉल में से एक हो सकता है (यह सब इस बात पर निर्भर करता है कि डिस्क्रिप्टर किस लिए है - कंसोल, नेटवर्क सॉकेट, फ़ाइल खुद या कुछ और), लेकिन जो भी मामला हो, हम 3 लौटाकर कॉल की तलाश करते हैं (यानी, हम ट्रेस परिणामों में "= 3" की तलाश करते हैं)। इस परिणाम में, उनमें से 2 हैं: openat सबसे ऊपर और सॉकेट बीच में। openat फ़ाइल खोलता है लेकिन बंद करे(3) तब दिखाएगा कि इसे फिर से बंद किया जा रहा है। (एक नुकसान: फ़ाइल डिस्क्रिप्टर को खोले और बंद किए जाने पर उनका पुनः उपयोग किया जा सकता है।) कॉल सॉकेट () यह सही बैठता है क्योंकि यह इससे पहले का आखिरी है पढ़ें (), और यह पता चलता है कि bcrontab सॉकेट के माध्यम से कुछ एक्सेस कर रहा है। अगली पंक्ति दर्शाती है कि फ़ाइल डिस्क्रिप्टर किससे जुड़ा हुआ है यूनिक्स डोमेन सॉकेट रास्ते में /var/run/bcron-स्पूल.

इसलिए, हमें एक ऐसी प्रक्रिया ढूंढ़ने की जरूरत है जो इससे जुड़ी हो यूनिक्स सॉकेट दूसरी ओर। इस उद्देश्य के लिए कुछ बढ़िया तरकीबें हैं, जो दोनों ही सर्वर परिनियोजन को डीबग करने के लिए उपयोगी हैं। पहला है उपयोग करना 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))

इससे पता चलता है कि श्रोता ही टीम है। inixसर्वर, प्रक्रिया आईडी 20629 के साथ चल रहा है। (और, संयोग से, यह फ़ाइल डिस्क्रिप्टर 3 को अपने सॉकेट के रूप में उपयोग करता है।)

समान जानकारी प्राप्त करने के लिए दूसरा वास्तव में उपयोगी उपकरण कहलाता है एलसोफेयह सिस्टम पर सभी खुली हुई फ़ाइलों (या फ़ाइल डिस्क्रिप्टर) को सूचीबद्ध करता है। या आप किसी एक विशिष्ट फ़ाइल के बारे में जानकारी प्राप्त कर सकते हैं:

# 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 एक दीर्घकालिक सर्वर है, इसलिए आप इससे जुड़ सकते हैं स्ट्रेस कुछ इस तरह का उपयोग करना स्ट्रेस -o /tmp/ट्रेस -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, सिगचल्ड आदि) यह प्रक्रिया एक चाइल्ड प्रक्रिया को जन्म देती है, जो, जैसा कि आप अनुमान लगा सकते हैं, वास्तविक कार्य करती है। और यदि आपको इसका पता लगाना है, तो कॉल में जोड़ें स्ट्रेस-एफ. यह वही है जो हमें तब मिलता है जब हम strace के साथ नए परिणाम में त्रुटि संदेश खोजते हैं -f -o /tmp/ट्रेस -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/स्पूल.21470.1573692319.854640 (वर्तमान कार्यशील निर्देशिका से संबंधित)। यदि हम केवल वर्तमान कार्यशील निर्देशिका जानते हैं, तो हम पूरा पथ जान पाएंगे और यह पता लगाने में सक्षम होंगे कि प्रक्रिया वहां अपनी अस्थायी फ़ाइल क्यों नहीं बना सकती है। दुर्भाग्य से, प्रक्रिया पहले ही बाहर निकल चुकी है, इसलिए हम इसका उपयोग नहीं कर सकते एलएसओएफ-पी 21470 वर्तमान निर्देशिका को खोजने के लिए, लेकिन आप दूसरे तरीके से भी काम कर सकते हैं - PID 21470 सिस्टम कॉल की तलाश करें जो निर्देशिका को बदलते हैं। (यदि कोई नहीं है, तो PID 21470 ने उन्हें पैरेंट से विरासत में लिया होगा, और वह पहले से ही है एलएसओएफ-पी यह पता नहीं लगा सकते हैं.) यह सिस्टम कॉल है 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 +++

(यदि आप भ्रमित हैं, तो आप मेरी पिछली पोस्ट पढ़ सकते हैं) *nix प्रक्रिया प्रबंधन और शैल के बारे में.) अतः, सर्वर 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/स्पूल/क्रॉन/tmp/. सरल आदेश चाउन क्रॉन /var/स्पूल/क्रॉन/tmp/ मजबूर कर देंगे बी.सी.आर.ओ.एन. ठीक से काम करें। (अगर यह समस्या नहीं थी, तो अगला सबसे संभावित संदिग्ध SE कर्नेल सुरक्षा मॉड्यूल है।)Linux या AppArmor, इसलिए मैं कर्नेल संदेश लॉग की जाँच करूँगा। dmesg.)

कुल मिलाकर

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

ट्रेस परिणामों को सिस्टम कॉल श्रृंखला के साथ पार्स करने के लिए कौशल की आवश्यकता होती है, लेकिन जैसा कि मैंने कहा, लगभग हमेशा, स्ट्रेस, मैं बस ट्रेस परिणाम प्राप्त करता हूं और अंत से शुरू होने वाली त्रुटियों की तलाश करता हूं। वैसे भी, स्ट्रेस इससे मुझे डिबगिंग में बहुत समय बचाने में मदद मिलती है। मुझे उम्मीद है कि आपको भी यह उपयोगी लगेगा।

स्रोत: www.habr.com