Syslog में Ascii NUL वर्णों के साथ सर्वर क्रैश (^ @ ^ @ ^ @…)

Question

मेरे पास एक समर्पित सर्वर है जो ओवीएच (फ्रेंच सर्विस प्रोवाइडर) द्वारा होस्ट किया जाता है। OS: उबंटू 12.04 x64

कुछ महीने पहले, मेरा एक सर्वर क्रैश हो गया था। केवल अजीब बात थी कुछ "ASCII NUL" कारसेवकों के syslog में:

^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ @ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @ ^ @

मेरे सेवा प्रदाता की मदद से, हमने जाँच की:

• राम
• सीपीयू
• डिस्क

सब कुछ ठीक था, इसलिए मेरे सेवा प्रदाता ने सर्वर के मदरबोर्ड को बदलने और कर्नेल (जो हमने किया था) को अपडेट करने की सिफारिश की। लेकिन जब से, यह सर्वर दो और बार दुर्घटनाग्रस्त हो गया, उसी कारसेवक के साथ सिसलॉग में।

किसी भी अधिक स्पष्टीकरण के बिना, हमने इस सर्वर को बदलने का फैसला किया (यह कुछ हफ्तों में योजनाबद्ध है)।

लेकिन, समस्या है, इस रात, यह एक और सर्वर के लिए हुआ। एक ही दुर्घटना, syslog में समान कैक्टर्स, कोई स्पष्टीकरण नहीं।

क्या किसी के पास कोई सुराग है कि हमें क्या जांचना चाहिए? क्या यह एक हार्डवेयर या एक सॉफ्टवेयर समस्या है?

Comments

क्या आपको इस समस्या का हल मिला? मैं वर्तमान में एक ही मुद्दा पीड़ित हूँ ...

— BurninLeo

@BurninLeo: यहां भी

— WoJ

दरअसल, मुझे कोई समाधान नहीं मिला (वर्चुअल सर्वर पर)। थोड़ी देर और स्थिर-रिलीज़ से कुछ (नियमित) अपडेट के बाद, समस्या गायब हो गई ...

— BurninLeo

Syslog में एनयूएल बाइट्स एक दुर्घटना का एक सामान्य प्रभाव है जो सिस्टम को साफ-साफ सिंक करने और फाइल सिस्टम को अनमाउंट करने से रोकता है। वे इस बात का संकेत नहीं देते हैं कि वास्तव में दुर्घटना क्या हुई।

— एनटी।

Answer 1

मैं @ n-st द्वारा दिए गए शानदार उत्तर को अधिक व्यापक रूप से साझा करूंगा:

Syslog में एनयूएल बाइट्स एक दुर्घटना का एक सामान्य प्रभाव है जो सिस्टम को साफ-साफ सिंक करने और फाइल सिस्टम को अनमाउंट करने से रोकता है। वे इस बात का संकेत नहीं देते हैं कि वास्तव में दुर्घटना क्या हुई।

वास्तव में, मैंने अक्सर सर्वर क्रैश के बाद के व्यवहार को देखा है: वे अक्षर हैं NULL( \0) वर्ण जो एक पुनर्प्राप्त ब्लॉक का प्रतिनिधित्व कर सकते हैं जो कुछ पुनर्प्राप्ति प्रक्रिया द्वारा शून्य से भरा था।

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

Answer 2

यदि आप लॉग फ़ाइलों को देखने के लिए पाठ-संपादक का उपयोग कर रहे हैं, तो इसका कारण हो सकता है;

• " ^@" वर्ण संकेत कर सकते हैं कि एक रेखा बहुत लंबी है (उदाहरण के लिए: लपेटकरvim चालू करें )
• एन्कोडिंग बेमेल है, फ़ाइल देखने के लिए या उपयोग किए गए एन्कोडिंग को बदलने के लिए या तो एक अलग टेक्स्ट-एडिटर का उपयोग करें syslog।

Comments

मुझे एक ऐसी ही समस्या है। न तो एक लंबी लाइन और न ही एन्कोडिंग, SULlog के अंत में NUL वर्णों की व्याख्या करता है (फ़ाइल को बाहरी डिस्क पर कॉपी किया और इसे SciTE, UTF-8 एन्कोडिंग के साथ खोला)।

— BurninLeo

ऐसा लगता है कि आप एक संपादक में UTF-8 एन्कोडेड फ़ाइल खोल रहे होंगे जो UTF-8 को अच्छी तरह से नहीं समझता है। हालाँकि यह CRLF समस्या (dos2unix और unix2dos कमांड मददगार हो सकती है) हो सकती है

— सिग्नल 15

Syslog में एनयूएल बाइट्स एक दुर्घटना का एक सामान्य प्रभाव है जो सिस्टम को साफ-साफ सिंक करने और फाइल सिस्टम को अनमाउंट करने से रोकता है। वे इस बात का संकेत नहीं देते हैं कि वास्तव में दुर्घटना क्या हुई।

— n .st

@ n.st क्या शानदार जवाब है! :) आपको उस एक को "उत्तर" के रूप में रखना चाहिए

— सिग्नल 15