गैर-पैक किए गए एप्लिकेशन क्रैश के लिए apport डिफ़ॉल्ट व्यवहार को कैसे बदला जाए?

Question

हमारे पास एक उबंटू सर्वर है जो दिखाए गए एपपोर्ट सक्षम के साथ तैनात है।

~$ cat /proc/sys/kernel/core_pattern 
|/usr/share/apport/apport %p %s %c 

दुर्भाग्य से गैर-पैक किए गए एप्लिकेशन क्रैश से निपटने में अपपोर्ट का व्यवहार पूरी तरह से हमारी पसंद के लिए नहीं है। apport इन परिदृश्यों में कार्यशील निर्देशिका में "कोर" फ़ाइलों का उत्पादन कर रहा है (माना जाता है कि ulimit -c उचित रूप से सेट है)। उदाहरण के लिए, apport लॉग,

ERROR: apport (pid 10117) Tue Jan 8 08:56:25 2013: executable: /home/jess/a.out (command line "./a.out") 
ERROR: apport (pid 10117) Tue Jan 8 08:56:25 2013: executable does not belong to a package, ignoring 
ERROR: apport (pid 10117) Tue Jan 8 08:56:25 2013: writing core dump to /home/jess/core (limit: 18889465931478580853760) 

Frustratingly से, एक बार एक कोर फ़ाइल वहाँ यह ओवरराइट नहीं किया जाएगा। तो उदाहरण के लिए यदि हम एक ऐप का परीक्षण कर रहे हैं और कार्यशील निर्देशिका से पुरानी कोर फ़ाइल को साफ़ करना भूल गए हैं, तो ऐप परीक्षण के दौरान क्रैश हो जाता है, हम एक नई कोर फ़ाइल नहीं देखेंगे। यहां तक ​​कि अगर इसे ओवरराइट किया गया हो, तो यह आदर्श नहीं हो सकता है क्योंकि हम पुराने कोर को खो देते हैं।

आदर्श रूप से हम जो चाहते हैं वह अपवाद कहने की क्षमता है, उदाहरण के लिए तर्क के माध्यम से, कि गैर-पैक किए गए एप्लिकेशन केस के लिए, एक निर्दिष्ट फ़ाइल के अनुसार प्रारूपित फ़ाइल नाम के साथ कोर फ़ाइल उत्पन्न करें (core_pattern के अनुसार फ़ाइल विनिर्देश) ... क्या ऐसा करने का कोई तरीका है, या समकक्ष कुछ है?

Answer 1

यदि यह एक अनपेक्षित बाइनरी है, तोपोर्ट अभी भी /proc/sys/kernel/core_uses_pid का पालन करेगा ताकि आप सही कोर फ़ाइल प्राप्त करने की संभावनाओं को बढ़ाने के लिए इसे सेट कर सकें।

/proc/sys/kernel/core_pattern माना जाता है कि यह स्वयंपोर्ट का संदर्भ है, इसलिए इस तरह के मामले में वापस आने के लिए कुछ भी नहीं है।

आप /usr/share/apport/apport स्क्रिप्ट में कोड देख सकते हैं जिसे कर्नेल कोर पैटर्न द्वारा apport के साथ बुलाया जाता है।

एक स्पष्ट विकल्प उपयोग करने के लिए एक नई पायथन लिपि बनाने के लिए होगा, लेकिन write_user_coredump फ़ंक्शन में संशोधन के साथ, और उसके बाद कर्नेल कोर पैटर्न sysctl के माध्यम से इसे हुक करें।

Answer 2

एक और विकल्प अपने दुर्घटनाओं को संभालने के लिए अपपोर्ट का उपयोग करना है। यह क्रैश के बारे में अन्य उपयोगी संदर्भ के टन के साथ कोर डंप को बचाएगा। ~/.config/apport/settings (अगर यह मौजूद नहीं है इसे बनाने) में निम्नलिखित पंक्तियां जोड़ें:

[main] 
unpackaged=true 

अब /var/crash में Apport .crash फ़ाइलों के रूप में दिखाई देगा दुर्घटनाओं। आप उन्हें apport-unpack के साथ अनपैक कर सकते हैं।

एक चेतावनी: ऐसा प्रतीत होता है कि उपयोगकर्ता अभी भी उबंटू बग ट्रैकर को इन क्रैश को अपलोड करने का प्रयास करता है यदि उपयोगकर्ता 'त्रुटि रिपोर्ट भेजें' चेकबॉक्स चेक करता है; यदि आप मालिकाना कोड आदि पर काम कर रहे हैं तो यह एक समस्या हो सकती है। मैं इस पर अधिक जानकारी ढूंढ रहा हूं; ऐसा लगता है कि /etc/apport/crashdb.conf नियंत्रण कर सकता है जहां क्रैश रिपोर्ट भेजी जाती है।