🥇स्ट्रेसको साथ डिबगिङ सफ्टवेयर डिप्लोइमेन्ट

मेरो दिनको काम प्रायः सफ्टवेयर परिनियोजन हो, जसको मतलब मैले प्रश्नहरूको जवाफ दिन धेरै समय खर्च गर्छु:

यो सफ्टवेयर विकासकर्ताको लागि काम गर्दछ, तर मेरो लागि होइन। किन?
हिजो यो सफ्टवेयरले मेरो लागि काम गर्यो, तर आज यो गर्दैन। किन?

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

त्यसैले सामान्य डिबगिङ उपकरणहरू जस्तै gdb डिबगिङ डिप्लोयमेन्टका लागि मसँग उपकरणहरूको फरक सेट छ। र "किन यो सफ्टवेयर मेरो लागि काम गर्दैन?" जस्तै समस्या समाधान गर्न मेरो मनपर्ने उपकरण। बोलाइयो स्ट्रेस.

स्ट्रेस भनेको के हो?

स्ट्रेस "सिस्टम कल ट्रेसिङ" को लागी एक उपकरण हो। यो मूल रूपमा लिनक्सको लागि सिर्जना गरिएको थियो, तर उही डिबगिङ चालहरू अन्य प्रणालीहरूको लागि उपकरणहरूसँग गर्न सकिन्छ (डीट्रेस वा 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
प्रक्रिया थ्रेडको जीवनकाल प्रबन्ध गर्दै
कम-स्तर मेमोरी व्यवस्थापन
विशिष्ट यन्त्र चालकहरूमा पहुँच

strace कहिले प्रयोग गर्ने?

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

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

हामी उदाहरणको रूपमा एक स्ट्यान्डअलोन सर्भर प्रयोग गर्नेछौं, तर प्रणाली कल ट्रेसिङ प्राय: अधिक जटिल डिप्लोइमेन्ट प्लेटफर्महरूमा गर्न सकिन्छ। तपाईंले मात्र सही उपकरणहरू छनौट गर्न आवश्यक छ।

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

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

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

कार्यक्रमबाट प्रणाली-y त्रुटिको बारेमा अस्पष्ट सन्देशको कारण निराश हुनुहोस्
संग कार्यक्रम पुन: सुरु गर्नुहोस् स्ट्रेस
ट्रेस परिणामहरूमा त्रुटि सन्देश फेला पार्नुहोस्
तपाईंले पहिलो असफल प्रणाली कललाई हिट नगरेसम्म माथि जानुहोस्

यो धेरै सम्भव छ कि चरण 4 मा प्रणाली कलले के गल्ती भयो प्रकट गर्नेछ।

सुझावहरू

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

मान्छे तिम्रो साथी हो

धेरै *nix प्रणालीहरूमा, कर्नेलमा प्रणाली कलहरूको पूर्ण सूची चलाएर प्राप्त गर्न सकिन्छ मान्छे syscalls। जस्ता चीजहरू देख्नुहुनेछ brk(2), जसको अर्थ चलाएर थप जानकारी प्राप्त गर्न सकिन्छ मान्छे 2 brk.

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

फाइलमा आउटपुट बचत गर्न -o प्रयोग गर्नुहोस्

स्ट्रेस व्यापक आउटपुट उत्पन्न गर्न सक्छ, त्यसैले यो प्रायः फरक फाइलहरूमा ट्रेस परिणामहरू भण्डारण गर्न उपयोगी हुन्छ (माथिको उदाहरणमा जस्तै)। यसले आउटपुटको साथ भ्रामक कार्यक्रम आउटपुटबाट बच्न मद्दत गर्दछ स्ट्रेस कन्सोलमा।

थप तर्क डाटा हेर्न -s प्रयोग गर्नुहोस्

तपाईंले याद गर्नुभएको होला कि त्रुटि सन्देशको दोस्रो आधा माथिको उदाहरण ट्रेसमा देखाइएको छैन। यो किनभने स्ट्रेस पूर्वनिर्धारितले स्ट्रिङ आर्गुमेन्टको पहिलो ३२ बाइटहरू मात्र देखाउँछ। यदि तपाईं थप हेर्न चाहनुहुन्छ भने, जस्तै केहि थप्नुहोस् -एस 128 कल गर्न स्ट्रेस.

-y फाइलहरू, सकेटहरू, आदि ट्र्याक गर्न सजिलो बनाउँछ।

"सबै फाइल हो" को अर्थ हो कि *निक्स प्रणालीहरूले फाइल वर्णनकर्ताहरू प्रयोग गरेर सबै I/O गर्छ, चाहे त्यो फाइल वा नेटवर्क वा इन्टरप्रोसेस पाइपहरूमा लागू हुन्छ। यो प्रोग्रामिङको लागि सुविधाजनक छ, तर तपाईले सामान्य देख्दा के भइरहेको छ भनेर ट्र्याक राख्न गाह्रो बनाउँछ पढ्नुहोस и लेख्न प्रणाली कल ट्रेस परिणामहरूमा।

अपरेटर थपेर -у, तपाईले जबरजस्ती गर्नुहुनेछ स्ट्रेस आउटपुटमा प्रत्येक फाइल वर्णनकर्तालाई यसले के संकेत गर्छ भन्ने नोटको साथ एनोटेट गर्नुहोस्।

-p** सँग पहिले नै चलिरहेको प्रक्रियामा संलग्न गर्नुहोस्

तपाईले तलको उदाहरणबाट देख्नुहुनेछ, कहिलेकाहीँ तपाईले पहिले नै चलिरहेको प्रोग्राम ट्रेस गर्न आवश्यक छ। यदि यो थाहा छ कि यो प्रक्रिया 1337 को रूपमा चलिरहेको छ (भन्नुहोस्, आउटपुटबाट ps), त्यसो भए तपाईले यसलाई यसरी ट्रेस गर्न सक्नुहुन्छ:

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

तपाईंलाई रूट अधिकार चाहिन्छ।

बाल प्रक्रियाहरू निगरानी गर्न -f प्रयोग गर्नुहोस्

स्ट्रेस पूर्वनिर्धारित रूपमा, यसले केवल एउटा प्रक्रियालाई ट्रेस गर्छ। यदि यो प्रक्रियाले बाल प्रक्रियाहरू उत्पन्न गर्छ भने, बच्चा प्रक्रियालाई स्प्यान गर्नको लागि प्रणाली कल देख्न सकिन्छ, तर चाइल्ड प्रक्रियाको प्रणाली कलहरू प्रदर्शन हुने छैनन्।

यदि तपाईंलाई त्रुटि बाल प्रक्रियामा छ भन्ने लाग्छ भने, कथन प्रयोग गर्नुहोस् -f, यसले यसको ट्रेसिङ सक्षम पार्नेछ। यसको नकारात्मक पक्ष यो हो कि आउटपुटले तपाईंलाई अझ बढी भ्रमित गर्नेछ। कहिले स्ट्रेस एउटा प्रक्रिया वा एउटा थ्रेड ट्रेस गर्दछ, यसले कल घटनाहरूको एकल स्ट्रिम देखाउँछ। जब यसले एकैचोटि धेरै प्रक्रियाहरू ट्रेस गर्छ, तपाईंले सन्देशले अवरोध गरेको कलको सुरुवात देख्न सक्नुहुन्छ , त्यसपछि - अन्य कार्यान्वयन शाखाहरूको लागि कलहरूको गुच्छा, र त्यसपछि मात्र - पहिलोको अन्त्य । वा सबै ट्रेस परिणामहरू विभिन्न फाइलहरूमा विभाजन गर्नुहोस्, अपरेटर प्रयोग गरेर -ff (विवरण मा गाईड मा स्ट्रेस).

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

"त्रुटि रिपोर्ट गर्नु अघि अन्तिम असफल अनुरोध" जस्ता ह्युरिस्टिकहरू सान्दर्भिक त्रुटिहरू फेला पार्नमा राम्रो छन्। जस्तोसुकै होस्, अन्त्यबाट सुरु गर्नु तार्किक छ।

सी प्रोग्रामिङ ट्यूटोरियलहरूले तपाईंलाई प्रणाली कलहरू बुझ्न मद्दत गर्न सक्छ।

C पुस्तकालयहरूमा मानक कलहरू प्रणाली कलहरू होइनन्, तर पातलो सतह तह मात्र हुन्। त्यसोभए, यदि तपाइँ कम्तिमा पनि सी मा कसरी र के गर्ने भनेर बुझ्नुभयो भने, तपाइँलाई प्रणाली कल ट्रेसको परिणामहरू बुझ्न सजिलो हुनेछ। उदाहरणका लागि, तपाईंलाई नेटवर्क प्रणालीहरूमा कलहरू डिबग गर्न समस्या छ, उही क्लासिक हेर्नुहोस् नेटवर्क प्रोग्रामिङको लागि बिजाको गाइड.

थप जटिल डिबगिङ उदाहरण

मैले पहिले नै भनेको छु कि साधारण डिबगिङको उदाहरण भनेको काम गर्दा मैले प्राय जसो व्यवहार गर्नुपर्छ भन्ने उदाहरण हो स्ट्रेस। यद्यपि, कहिलेकाहीँ वास्तविक अनुसन्धान आवश्यक हुन्छ, त्यसैले यहाँ थप उन्नत डिबगिङको वास्तविक जीवन उदाहरण हो।

bcron - कार्य प्रशोधन अनुसूचक, * निक्स डेमनको अर्को कार्यान्वयन cron। यो सर्भरमा स्थापित छ, तर जब कसैले तालिका सम्पादन गर्ने प्रयास गर्छ, यो के हुन्छ:

# 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 धेरै शीर्ष मा र socket बिचमा। openat फाइल खोल्छ तर नजिक(3) त्यसपछि यो फेरि बन्द हुन्छ भनेर देखाउनेछ। (रेक: फाइल वर्णनकर्ताहरू खोल्दा र बन्द हुँदा पुन: प्रयोग गर्न सकिन्छ)। कल गर्नुहोस् सकेट() उपयुक्त किनभने यो पहिलेको अन्तिम हो पढ्नुहोस्), र यो बाहिर जान्छ कि bcrontab सकेट मार्फत केहि काम गर्दछ। अर्को रेखाले फाइल वर्णनकर्तासँग सम्बन्धित छ भनेर देखाउँछ युनिक्स डोमेन सकेट बाटोमा /var/run/bcron-sool.

त्यसोभए, हामीले सम्बन्धित प्रक्रिया खोज्न आवश्यक छ युनिक्स सकेट अर्कोतीर। यस उद्देश्यका लागि त्यहाँ दुईवटा सफा चालहरू छन्, जुन दुवै सर्भर डिप्लोइमेन्टहरू डिबग गर्नका लागि उपयोगी छन्। पहिलो प्रयोग गर्नु हो 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 आदि) यो प्रक्रियाले बाल प्रक्रियालाई जन्म दिन्छ, जुन तपाईले अनुमान गर्न सक्नुहुन्छ, वास्तविक काम गर्दछ। र यदि तपाईंलाई उनको ट्रेल समात्न आवश्यक छ भने, कलमा थप्नुहोस् 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/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/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

स्ट्रेसको साथ डिबगिङ सफ्टवेयर डिप्लोइमेन्ट

स्ट्रेस भनेको के हो?

strace कहिले प्रयोग गर्ने?

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

सुझावहरू

थप जटिल डिबगिङ उदाहरण

कुल

एक टिप्पणी थप्न Отменить ответ