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

मेरा मुख्य काम है, अधिकांश भाग के लिए, सॉफ्टवेयर सिस्टम की तैनाती, यानी, मैं इन सवालों के जवाब देने की कोशिश में बहुत समय बिताता हूं:

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

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

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

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

स्ट्रेस एक सिस्टम कॉल ट्रेस करने का एक उपकरण है। प्रारंभ में लिनक्स के तहत बनाया गया था, लेकिन समान डिबगिंग चिप्स को अन्य सिस्टम ( DTrace या ktrace ) के लिए टूल के साथ घुमाया जा सकता है।

मुख्य अनुप्रयोग बहुत सरल है। आपको बस किसी भी कमांड के साथ स्ट्रेस चलाने की आवश्यकता है और यह डंप के लिए सभी सिस्टम कॉल भेजेगा (हालांकि, पहले, आपको संभवतः स्ट्रेस को खुद ही स्थापित करना होगा):

$ strace echo Hello ...Snip lots of stuff... write(1, "Hello\n", 6) = 6 close(1) = 0 close(2) = 0 exit_group(0) = ? +++ exited with 0 +++ 

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

बाइनरी स्तर पर, एक सिस्टम कॉल एक साधारण फ़ंक्शन कॉल से थोड़ा अलग है, हालांकि अधिकांश प्रोग्राम मानक लाइब्रेरी में एक आवरण का उपयोग करते हैं। यानी POSIX C मानक लाइब्रेरी में लिखने () फ़ंक्शन के लिए एक कॉल होता है, जिसमें राइट सिस्टम कॉल के लिए सभी आर्किटेक्चर-विशिष्ट कोड होते हैं।

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

• कंसोल I / O
• नेटवर्क इनपुट / आउटपुट
• फ़ाइल सिस्टम एक्सेस और फ़ाइल I / O
• प्रक्रिया / धागा जीवनकाल प्रबंधन
• निम्न स्तर का स्मृति प्रबंधन
• विशिष्ट डिवाइस ड्राइवरों तक पहुंच

स्ट्रेस का उपयोग कब करें?

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

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

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

सरल डिबगिंग उदाहरण

मान लें कि आप भयानक foo सर्वर एप्लिकेशन चलाना चाहते हैं, लेकिन यह इस बात को बताता है:

 $ foo Error opening configuration file: No such file or directory 

जाहिर है, वह आपके द्वारा लिखी गई कॉन्फ़िगरेशन फ़ाइल नहीं ढूंढ सका। ऐसा इसलिए होता है क्योंकि कभी-कभी, जब पैकेज प्रबंधक किसी एप्लिकेशन को संकलित करते हैं, तो वे फ़ाइलों के अपेक्षित स्थान को ओवरराइड करते हैं। और यदि आप एक वितरण के लिए अधिष्ठापन गाइड का पालन करते हैं, तो दूसरे में आप पूरी तरह से फाइलों को नहीं पाते हैं जहां मुझे उम्मीद थी। यह संभव होगा कि समस्या को कुछ सेकंड में हल किया जाए यदि त्रुटि संदेश में कहा गया है कि कॉन्फ़िगरेशन फ़ाइल को कहां देखना है, लेकिन यह नहीं कहता है। तो कहाँ देखना है?

यदि आपके पास स्रोत कोड तक पहुंच है, तो आप इसे पढ़ सकते हैं और पता लगा सकते हैं। एक अच्छा बैकअप प्लान, लेकिन सबसे तेज़ समाधान नहीं। आप gdb जैसे चरण-दर-चरण डिबगर का सहारा ले सकते हैं और देख सकते हैं कि कार्यक्रम क्या करता है, लेकिन यह एक उपकरण का उपयोग करने के लिए बहुत अधिक कुशल है जो विशेष रूप से पर्यावरण के साथ बातचीत दिखाने के लिए डिज़ाइन किया गया है: स्ट्रेस ।

स्ट्रेस का निष्कर्ष बेमानी लग सकता है, लेकिन अच्छी खबर यह है कि इसमें से अधिकांश को सुरक्षित रूप से अनदेखा किया जा सकता है। किसी फ़ाइल को ट्रेस परिणाम सहेजने के लिए -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, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260A\2\0\0\0\0\0"..., 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 +++ 

स्ट्रेस आउटपुट के पूरे पहले पृष्ठ के बारे में आमतौर पर लॉन्च के लिए एक निम्न-स्तरीय तैयारी होती है। (निम्न स्तर की मेमोरी का पता लगाने और गतिशील पुस्तकालयों को प्रदर्शित करने जैसी चीजों के लिए कई एमएमएपी , एमप्रोक्ट , ब्रैक कॉल हैं।) वास्तव में, डिबगिंग के दौरान, स्ट्रेस आउटपुट सबसे अंत से पढ़े जाते हैं। नीचे लिखने के लिए एक कॉल है, जो एक त्रुटि संदेश प्रदर्शित करता है। हम ऊपर देखते हैं और पहली गलत प्रणाली कॉल को देखते हैं - एक ओपनैट कॉल जो एक ENOENT त्रुटि ("फ़ाइल या निर्देशिका नहीं मिली") को फेंकता है , /etc/foo/config.json खोलने की कोशिश कर रहा है। यहां, कॉन्फ़िगरेशन फ़ाइल को झूठ बोलना चाहिए।

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

• एक प्रोग्राम से एक स्लेटेड सिस्टम-वाई त्रुटि संदेश से निराश
• कार्यक्रम को स्ट्रेस के साथ फिर से शुरू करें
• ट्रेस परिणामों में त्रुटि संदेश प्राप्त करें
• जब तक आप पहले विफल सिस्टम कॉल से टकरा नहीं जाते, तब तक अधिक जाएं

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

युक्तियाँ

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

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

कई * निक्स सिस्टमों पर, कर्नेल सिस्टम कॉल की पूरी सूची मैन सिस्कॉल चलाकर प्राप्त की जा सकती है। आपको brk (2) जैसी चीजें दिखाई देंगी, जिसका अर्थ है कि आप आदमी 2 brk चलाकर अधिक जानकारी प्राप्त कर सकते हैं।

एक छोटी सी रेक: मैन 2 कांटा मुझे GNU libc में फोर्क () शेल के लिए एक पेज दिखाता है, जो क्लोन () कॉल का उपयोग करके कार्यान्वित किया जाता है। कांटा कॉल के शब्दार्थ एक समान रहते हैं यदि आप एक प्रोग्राम लिखते हैं जो कांटा () का उपयोग करता है और अनुरेखण शुरू करता है - मुझे कांटा कॉल नहीं मिलेगा, उनके बजाय क्लोन () होगा । यदि आप स्ट्रेस के आउटपुट के साथ स्रोत की तुलना करना शुरू करते हैं तो ऐसी रेक केवल भ्रमित होती है।

एक फ़ाइल में आउटपुट को बचाने के लिए -o का उपयोग करें

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

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

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

-मैं ट्रैकिंग फाइल \ _ सॉकेट्स आदि की सुविधा देता हूं।

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

-U ऑपरेटर को जोड़कर, आप आउटपुट में प्रत्येक फ़ाइल डिस्क्रिप्टर को एनोटेट करने के लिए बल देते हैं, जो इस बात पर ध्यान देता है कि यह किस ओर इशारा करता है।

पहले से चल रही प्रक्रिया के साथ संलग्न करें -p **

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

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

शायद आपको रूट विशेषाधिकार की जरूरत है।

बाल प्रक्रियाओं की निगरानी के लिए -f का उपयोग करें

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

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

-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 एक कार्य प्रसंस्करण अनुसूचक है, जो * nix cron daemon का एक और कार्यान्वयन है। यह सर्वर पर स्थापित है, लेकिन जब कोई शेड्यूल को संपादित करने की कोशिश करता है, तो यही होता है:

 # 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: logsagg\n20 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\0#Ansible: logsagg\n20 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 का प्रतिनिधित्व करती है? इस विशेष मामले में, आप -u ऑपरेटर (ऊपर देखें) के साथ स्ट्रीम चला सकते हैं, और यह स्वचालित रूप से आपको बताएगा, हालांकि, ऐसी चीजों की गणना करने के लिए, ट्रेस परिणामों को पढ़ना और विश्लेषण करना जानना उपयोगी है।

फ़ाइल डिस्क्रिप्टर का स्रोत कई सिस्टम कॉलों में से एक हो सकता है (यह सब इस बात पर निर्भर करता है कि कंसोल, नेटवर्क सॉकेट, फ़ाइल के लिए या कुछ और) के लिए डिस्क्रिप्टर क्या है, लेकिन यह हो सकता है कि हम कॉलिंग 3 (टी) की तलाश में हों ।) ट्रेस परिणामों में "= 3" के लिए देखें)। नतीजतन, उनमें से 2 हैं: बीच में बहुत ऊपर और सॉकेट पर ओपनैट । Openat फ़ाइल को खोलता है, लेकिन इसके बाद (3) बंद होने से पता चलेगा कि यह फिर से बंद हो गया है। (रेक: फ़ाइल डिस्क्रिप्टर का उपयोग तब किया जा सकता है जब वे खुले और बंद हों)। सॉकेट () कॉल उपयुक्त है, क्योंकि यह पढ़ने से पहले अंतिम है () , और यह पता चलता है कि सॉकेट के माध्यम से bcrontab कुछ के साथ काम करता है। अगली पंक्ति बताती है कि फ़ाइल डिस्क्रिप्टर पथ / 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 कमांड है जो प्रोसेस आईडी 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 प्रक्रिया एक लंबे समय तक रहने वाला सर्वर है, इसलिए आप स्ट्रेस -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 , एसआईजीसीएचएलडी , आदि) यह प्रक्रिया एक बच्चे की प्रक्रिया को जन्म देती है, जो कि आप अनुमान लगा सकते हैं, असली काम करता है। और अगर आपको उसके निशान को पकड़ने की जरूरत है, तो कॉल में स्ट्रेस -f जोड़ें। यहाँ हम नए परिणाम में स्ट्रेस -f -o / tmp / ट्रेस -p २०६२ ९ के साथ त्रुटि संदेश की तलाश कर रहे हैं:

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

अब, यह कुछ है। पथ tmp / spool.21470.1573692319.854640 (वर्तमान कामकाजी निर्देशिका का जिक्र करते हुए) पर एक फ़ाइल बनाने की कोशिश करते समय प्रक्रिया 21470 को "एक्सेस अस्वीकृत" त्रुटि प्राप्त होती है। यदि हम केवल वर्तमान कार्यशील निर्देशिका को जानते हैं, तो हम पूर्ण पथ को जान सकते हैं और यह पता लगा सकते हैं कि प्रक्रिया इसमें अपनी अस्थायी फ़ाइल क्यों नहीं बना सकती है। दुर्भाग्य से, प्रक्रिया पहले ही समाप्त हो गई है, इसलिए आप वर्तमान निर्देशिका को खोजने के लिए बस lsof -p 21470 का उपयोग नहीं कर सकते हैं, लेकिन आप विपरीत दिशा में काम कर सकते हैं - पीआईडी ​​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/cool.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 

! cron, root /var/spool/cron/tmp/ . chown cron /var/spool/cron/tmp/ bcron . ( , — SELinux AppArmor, dmesg .)

कुल मिलाकर

, , , , — . , bcron , .

, , , strace , , . , strace . , .