प्रॉम्प्ट और दायरा
कोर डंप एक प्रोसेस एड्रेस स्पेस का स्नैपशॉट होता है। इसमें कुंजियाँ (keys), रिक्वेस्ट बॉडी, यूज़र डेटा और अनक्लियर किए गए बफ़र्स शामिल हो सकते हैं। यह प्रश्न Linux डायग्नोसिस और प्रोडक्शन डेटा गवर्नेंस का परीक्षण करता है: क्या डंप एकत्र किया जा सकता है, इसे कौन देख सकता है, यह कितने समय तक रहता है, और क्लीनअप कैसे साबित होता है, इन बातों को अलग-अलग रखें।
साक्षात्कारकर्ता क्या मूल्यांकन कर रहा है
- एग्जिट सिग्नल्स, journal, कर्नेल संदेशों, वर्ज़न और कोर मेटाडेटा से साक्ष्य।
- systemd-coredump कलेक्शन, कम्प्रेशन, स्टोरेज और
coredumpctlसीमाओं की समझ। - सटीक बाइनरी, लाइब्रेरीज़, डिबग सिम्बल्स और build ID के साथ सिम्बलाइजेशन।
- कंटेंट, अनुमतियों, एन्क्रिप्शन, रिटेंशन, कैपेसिटी और प्राइवेसी के लिए संपूर्ण नियंत्रण।
- रीप्रोडक्शन, क्रैश मेट्रिक्स, विलोपन जाँच और एक्सेस समीक्षा के माध्यम से फिक्स के बाद प्रमाण।
अनुशंसित उत्तर संरचना
कम जोखिम वाले साक्ष्यों से शुरुआत करें: सर्विस स्थिति, सिग्नल, journal, कर्नेल संदेश, वर्ज़न और संसाधन मेट्रिक्स। यदि कोर न्यायसंगत है, तो एक आइसोलेटेड इंस्टेंस पर थोड़े समय के लिए नियंत्रित कैप्चर सक्षम करें, आकार और संख्या को सीमित करें, और समर्पित एन्क्रिप्टेड स्टोरेज का उपयोग करें। इसका तुरंत विश्लेषण करें और नष्ट करें या किसी दस्तावेज़ीकृत रिटेंशन जॉब द्वारा इसे समाप्त होने दें।
डीप डाइव: क्रैश से समाधान तक
पहले एग्जिट का कारण पहचानें
systemctl status, journal, कर्नेल OOM रिकॉर्ड, एग्जिट सिग्नल और रीस्टार्ट काउंट की जाँच करें। SIGSEGV, SIGABRT और SIGBUS अलग-अलग सुराग प्रदान करते हैं; एग्जिट 137 को पहले cgroup OOM जाँच को ट्रिगर करना चाहिए। केवल एक कोर फ़ाइल सेग्मेंटेशन फॉल्ट का प्रमाण नहीं है।
सिम्बलाइजेशन इनपुट को फिक्स करें
क्रैश हुए इंस्टेंस के लिए सटीक बाइनरी, शेयर्ड लाइब्रेरीज़, डिबग सिम्बल्स और build ID रखें। उन्हें एक विश्वसनीय आर्टिफैक्ट स्टोर से प्राप्त करें। जोखिम कम करने के लिए पहले थ्रेड्स, सिग्नल और स्टैक्स पढ़ें; हीप और रजिस्टर्स का निरीक्षण केवल तभी करें जब आवश्यक हो।
नियंत्रित कलेक्शन का निर्माण करें
systemd-coredump डंप को एक समर्पित सर्विस को सौंप सकता है और इसे journal या किसी बाहरी डायरेक्टरी में स्टोर कर सकता है। प्रति-फ़ाइल और कुल कोटा, कम्प्रेशन, कॉनकरेंसी और अलर्ट सेट करें। अत्यधिक संवेदनशील सर्विस के लिए, LimitCORE=0 सेट करें या रिकॉर्डेड रोलबैक के साथ केवल मेटाडेटा और एक नियंत्रित स्टैक एकत्र करें।
एक्सेस और रिटेंशन सीमाएं स्थापित करें
कोर स्टोरेज को एन्क्रिप्ट करें, न्यूनतम विशेषाधिकार (least privilege) दें और प्रत्येक एक्सेस का ऑडिट करें। सामान्य ऑपरेशन्स खातों को डंप डाउनलोड करने की अनुमति न दें। स्वचालित समाप्ति (expiry) और कैपेसिटी अलार्म के साथ, डायग्नोस्टिक विंडो और नीति के आधार पर रिटेंशन सेट करें। कमांड्स, पाथ्स और टिकट्स में टोकन नहीं होने चाहिए।
साक्ष्य के साथ लूप को पूरा करें
फिक्स से पहले के क्रैश को रीप्रोड्यूस करें, उसी इनपुट के तहत नए बिल्ड को सत्यापित करें, और क्रैश तथा रीस्टार्ट दरों का निरीक्षण करें। डंप, कैश और बैकअप की समाप्ति को सत्यापित करें और एक्सेस समीक्षा करें। यदि संवेदनशील डेटा को हटाना साबित नहीं किया जा सकता है, तो जोखिम बना रहता है।
नमूना उत्तर
“मैं SIGSEGV और एग्जिट 137 के बीच अंतर करते हुए सिग्नल, journal, कर्नेल OOM रिकॉर्ड, डिप्लॉयमेंट वर्ज़न और cgroup मेट्रिक्स की पुष्टि करूँगा। यदि यह एक एप्लिकेशन क्रैश है, तो मैं एक आइसोलेटेड नोड पर थोड़े समय के लिए systemd-coredump सक्षम करूँगा, प्रति-फ़ाइल और कुल आकार को सीमित करूँगा, और हीप से पहले स्टैक्स का निरीक्षण करने के लिए build ID से मेल खाने वाले सिम्बल्स का उपयोग करूँगा। एन्क्रिप्टेड डायरेक्टरी केवल इंसिडेंट टीम को अल्पकालिक एक्सेस की अनुमति देगी; टोकन कभी भी टिकट में नहीं जाएंगे। मैं मूल इनपुट का रिग्रेशन-टेस्ट करूँगा, क्रैश दर का निरीक्षण करूँगा, डंप को हटा दूँगा, और journal, बैकअप और अनुमतियों की समीक्षा करूँगा। यदि सीमा को भरोसेमंद नहीं बनाया जा सकता है, तो मैं पूर्ण डंप को अक्षम कर दूँगा और केवल नियंत्रित मेटाडेटा और स्टैक रखूँगा।”
सामान्य विफलता मोड और समाधान
- यह मान लेना कि कोर का मतलब SIGSEGV है → सिग्नल, OOM, cgroup और डिप्लॉयमेंट साक्ष्यों को सत्यापित करें।
- सीधे प्रोडक्शन पर टूल्स इंस्टॉल करना → मेल खाने वाले आर्टिफैक्ट्स और एक आइसोलेटेड विश्लेषण वातावरण का उपयोग करें।
- केवल डिस्क स्थान पर चर्चा करना → कोटा, रिटेंशन, एन्क्रिप्शन और क्लीनअप को शामिल करें।
- डंप को एक सामान्य लॉग की तरह मानना → न्यूनतम विशेषाधिकार, अस्थायी एक्सेस और स्वतंत्र ऑडिट का उपयोग करें।
- सर्विस रिकवर होने के बाद रुक जाना → रीप्रोडक्शन, क्रैश दर, विलोपन, बैकअप और एक्सेस को सत्यापित करें।
स्कोरिंग रूब्रिक और सेल्फ़-चेक
मजबूत उत्तरों में एग्जिट साक्ष्य, build IDs और सिम्बल्स, systemd-coredump सीमाएं, कलेक्शन स्विच, कोटा, एन्क्रिप्शन, एक्सेस कंट्रोल, रिटेंशन और विलोपन, डेटा न्यूनीकरण, रोलबैक और फिक्स के बाद के मेट्रिक्स शामिल होते हैं।
स्वयं से पूछें: क्या मैं कारण साबित कर सकता हूँ? क्या विश्लेषण फ़ाइलें बिल्ड से मेल खाती हैं? उन तक कौन पहुँच सकता है? उन्हें कितने समय तक रखा जाता है? टोकन को लॉग से बाहर कैसे रखा जाता है? क्या चीज़ समाधान और क्लीनअप को साबित करती है?
फॉलो-अप और विस्तार
आपको कोर डंप को पूरी तरह से कब अक्षम कर देना चाहिए?
जब एड्रेस स्पेस अत्यधिक संवेदनशील हो और भरोसेमंद आइसोलेशन, एन्क्रिप्शन, एक्सेस और क्लीनअप स्थापित नहीं किया जा सके, तो पूर्ण डंप को अक्षम करें। सिग्नल, थ्रेड-स्टैक, या न्यूनतम डायग्नोस्टिक साक्ष्य रखें और खोई हुई डायग्नोस्टिक क्षमता को रिकॉर्ड करें।
जब केवल एक मशीन क्रैश होती है तो आप जोखिम कैसे कम करते हैं?
पहले मेटाडेटा और एक नियंत्रित स्टैक एकत्र करें, जो उस इंस्टेंस और एक छोटी विंडो तक सीमित हो। यदि पूर्ण डंप आवश्यक है, तो स्वचालित समाप्ति, वन-टाइम प्राधिकरण और अपलोड के बाद स्थानीय प्रतिलिपि को तत्काल हटाने का उपयोग करें।
आप भ्रामक सिम्बलाइजेशन से कैसे बचते हैं?
बाइनरी, लाइब्रेरीज़ और सिम्बल्स के लिए build ID, चेकसम और आर्टिफैक्ट मैनिफ़ेस्ट को सत्यापित करें। जब वे मेल नहीं खाते हैं तो स्टैक को अनिश्चित चिह्नित करें; कभी भी किसी समान रिलीज़ से निष्कर्ष न निकालें।
क्या होगा यदि डंप पहले से ही बैकअप में है?
बैकअप को एक अलग डेटा डोमेन के रूप में मानें। ऑब्जेक्ट वर्ज़न और समाप्ति को ट्रैक करें, रिस्टोर एक्सेस को प्रतिबंधित करें, और इरेज़र प्रक्रिया में बैकअप इंडेक्स और रोटेशन जॉब्स को शामिल करें। किसी भी स्वीकृत अपवाद और नवीनतम क्लीनअप समय को रिकॉर्ड करें।