उबंटू 13.X पर अपस्टार्ट लॉग संदेश कहां हैं?


28

उबंटू 12.04 पर, मुझे उपस्टार्ट लॉग संदेश मिल सकते हैं /var/log/syslog

आदेश:

# initctl log-priority info
# initctl emit hello

लॉग इन करें:

Apr  1 01:56:56 precise64 kernel: [ 8365.820425] init: Connection from private client
Apr  1 01:56:56 precise64 kernel: [ 8365.821130] init: Handling hello event

उबंटू 13.10 पर, निर्देशिका के syslogतहत या कहीं और संदेश दिखाई नहीं देते हैं /var/log, हालांकि logger helloअपेक्षा के अनुरूप काम करते हैं। क्या मुझे कहीं और उनकी तलाश होनी चाहिए? क्या कोई कॉन्फ़िगरेशन सेटिंग है जिसे मुझे कहीं बदलने की आवश्यकता है?

सर्वर फाल्ट पर एक सवाल है जो उबंटू 13.04 पर एक ही समस्या से लगता है, और यहाँ और यहाँ भी वही समस्या का वर्णन हो सकता है। दुर्भाग्य से, ये प्रश्न समस्या के लिए कोई संकेत नहीं देते हैं।

जवाबों:


39

2016-06-02 संपादित करें

यदि आप सामान्य रूप से "अपस्टार्ट लॉग संदेश" खोजने की कोशिश कर रहे हैं, तो जांच करें /var/log/upstart/। यहीं पर अपस्टार्ट सेव करता है stdoutऔर stderrअपस्टार्ट सेवाओं से। यह इंगित करने के लिए तेंदुए के जवाब के लिए धन्यवाद।

यदि आप स्वयं उपस्टार्ट से लॉग संदेशों की तलाश कर रहे हैं, तो इसके द्वारा कॉन्फ़िगर initctl log-priorityऔर उत्सर्जित initctl emit, पर पढ़ें!

लघु संस्करण

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

यदि आप उन्हें /var/logभी चाहते हैं , तो $KLogPermitNonKernelFacility onrsyslogd के विन्यास में जोड़ें । मेरा सुझाव है कि /etc/rsyslog.d/60-custom.confसंपादन से बचने के लिए एक कस्टम फ़ाइल बनाना /etc/rsyslog.conf, क्योंकि यह dpkg द्वारा प्रबंधित किया गया है। अब कल का नवाब संदेशों में दिखाई देना चाहिए /var/log/syslog, एक बार आप कल का नवाब के सेट log-priorityकरने के लिए infoया तो।

दीर्घ संस्करण

यह मुझे ट्रैक करने में दिन लग गए, लेकिन जाहिरा तौर पर Upstart (1.5) syslog में प्रवेश नहीं करता है , अर्थात यह ग्लिब फ़ंक्शन को कॉल नहीं करता है syslog()। इसके बजाय, अपस्टार्ट कर्नेल रिंग बफर में लॉग करता है, जो कि dmesg पढ़ता है। अब, मुझे नहीं लगा कि उपयोगकर्ता अंतरिक्ष प्रक्रियाओं के लिए उस बफर को लिखना संभव था , लेकिन जाहिर है कि वे लिख कर सकते हैं /dev/kmsg, और ठीक यही उपस्टार्ट करता है। तो यह पहेली का पहला भाग है।

दूसरा भाग यह है कि एक व्यापक रूप से आयोजित धारणा है कि कर्नेल रिंग बफर को लिखे गए संदेश स्वचालित रूप से कर्नेल द्वारा syslog में कॉपी किए जाते हैं (कम से कम यही मैं हमेशा सोचता था)। यह वास्तव में एक उपयोगकर्ता अंतरिक्ष डेमॉन द्वारा किया जाता है, पारंपरिक रूप से क्लॉग, जो कि सिस्मलड के साथ मिलकर काम करता है। स्पष्ट रूप से rsyslogd syslogd की जगह लेता है, लेकिन जाहिर है कि यह klogd को भी प्रतिस्थापित करता है (जैसे: अंत में नोट्स देखें)।

तीसरा भाग यह है कि उपयोगकर्ता अंतरिक्ष से कर्नेल रिंग बफर को लिखे गए संदेश वास्तव में कर्नेल अंतरिक्ष से लिखे गए संदेशों से अलग दिखते हैं: उनके पास एक अलग सुविधा है। : dmesg कुछ ही विकल्प है कि इस के साथ सहभागिता है -xसुविधा (और प्राथमिकता) से पता चलता है, जबकि -uऔर -kdmesg बता केवल उपयोगकर्ता सुविधा संदेश और गिरी सुविधा संदेशों क्रमश: दिखाने के लिए।

अब यहाँ का क्लिनिक है: डिफ़ॉल्ट रूप से, rsyslogd गैर-कर्नेल सुविधा के साथ संदेशों को अनदेखा करता है जब यह कर्नेल रिंग बफर से संदेश पढ़ रहा होता है। प्रासंगिक कॉन्फ़िगरेशन विकल्प है $KLogPermitNonKernelFacility, जो डिफ़ॉल्ट रूप से बंद है और यदि आप इन संदेशों को संसाधित करने के लिए rsyslogd चाहते हैं, तो इसे चालू करना होगा। ध्यान दें कि rsyslogd के बाकी विन्यास कर्नेल रिंग बफर के सभी संदेशों को kernसुविधा के रूप में मानते हैं, भले ही वे कर्नेल रिंग बफर में मौजूद सुविधा के बावजूद।

अधिक जानकारी

syslog

कोड glibc फ़ंक्शन को कॉल करके syslog को लिख सकता है syslog(), जिसमें वर्णित है man 3 syslog। जाहिर है कि ये कार्य लिखते हैं /dev/log। कोड को पढ़ने से syslog से पढ़ा जा सकता है /dev/log, और यह वही है जो syslogdइसकी प्रतिस्थापन करता है। इसके इनपुट मॉड्यूल का उपयोग करके rsyslogdपढ़ता है ।/dev/logimuxsock

कर्नेल रिंग बफर

कर्नेल स्थान कर्नेल फ़ंक्शन को कॉल करके इस बफर को लिखता है printk(), इसलिए इसे कभी-कभी प्रिंट बफर कहा जाता है। उपयोगकर्ता स्थान को लिखकर उसे लिख सकता है /dev/kmsg। उपयोगकर्ता स्थान इस बफ़र से कई विधियों से पढ़ सकता है: यह /proc/kmsg(डिफ़ॉल्ट रूप से dmesg क्या करता है) से पढ़ सकता है, या इसे पढ़ सकता है /dev/kmsg, या इसे सिस्टम कॉल कह सकता है syslog(), जो वर्णित है man 2 syslogऔर वर्णित glibc फ़ंक्शन से पूरी तरह से अलग है syslog()में है man 3 syslog। glibc वास्तव में सिस्टम कॉल को एक आवरण प्रदान करता है syslog(), जिसे klogctl()इस भ्रम को कम करने में मदद करने के लिए बुलाया जाता है।

परंपरागत रूप से, klogdइनमें से एक इंटरफेस से पढ़ता है, फिर syslog()उन्हें सिब्लॉग पर कॉपी करने के लिए ग्लिबक फ़ंक्शन को कॉल करता है । rsyslogd अपने imklogइनपुट मॉड्यूल के माध्यम से इनमें से एक इंटरफेस को पढ़ता है, लेकिन AFAIK ग्लिबक को कॉल करने से परेशान नहीं syslog()होता है, यही वजह है कि यह बिल्कुल क्लॉग की तरह नहीं है; यह बस के उत्पादन की प्रक्रिया की imklogतरह यह किसी भी अन्य इनपुट मॉड्यूल से उत्पादन प्रक्रियाओं। जोड़ा गया चेतावनी है कि सभी imklogआउटपुट में kernसुविधा संदेशों की परवाह किए बिना कर्नेल रिंग बफर में सुविधा थी।

संदर्भ


4
यह क्यों काम नहीं कर रहा था और इसे कैसे ठीक किया जाए, इसकी गहन व्याख्या के लिए आपका धन्यवाद। उल्लिखित लिंक के सवालों के जवाबों में से एक, dmesgलेकिन यहां दिए गए संदर्भ के बिना इसका कोई मतलब नहीं था।
ब्रैड सजोनी

16

मुझे मेरा अंदर मिल गया /var/log/upstart/


मुझे उस फ़ाइल में मेरा नाम मिला /var/log/upstart/job.logजहां jobमेरी नौकरी का नाम है।
केनी एविट

AFAIK है कि जहां नौकरियों से stdout / stderr जाना है। यह सवाल उपस्टार्ट के लॉग संदेशों के बारे में है, जो किसी विशेष नौकरी से जुड़े नहीं हैं।
वैनेसा फिप्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.