जैसा कि मैं समझता हूं, लिनक्स कर्नेल /proc/kmsgफ़ाइल (ज्यादातर हार्डवेयर-संबंधित संदेश) और /dev/logसॉकेट में प्रवेश करता है? कहीं और? क्या अन्य एप्लिकेशन भी संदेश भेजने में सक्षम हैं /proc/kmsgया /dev/log? इतना ही नहीं बल्कि, मैं सही है कि यह syslog डेमॉन है कर रहा हूँ ( rsyslog , syslog-एनजी ) जो उन दो स्थानों से संदेशों की जाँच करता है और उसके बाद जैसे विभिन्न फ़ाइलों के लिए उन वितरित करता है /var/log/messagesया /var/log/kern.logया यहां तक कि केंद्रीय syslog सर्वर?
जवाबों:
सरलीकृत, यह इस तरह से कम या ज्यादा होता है:
printk()कर्नेल अंतरिक्ष में एक रिंग बफर को संदेश ( फ़ंक्शन का उपयोग करके ) लॉग करता है। ये संदेश दो तरह से उपयोगकर्ता-स्पेस एप्लिकेशन को उपलब्ध कराए जाते हैं: /proc/kmsgफाइल के माध्यम से (बशर्ते कि /procमुहिम शुरू की गई है) और sys_syslogsyscall के माध्यम से ।
कर्नेल की रिंग बफर: (और कुछ हद तक नियंत्रित कर सकते हैं) पढ़ने वाले दो मुख्य अनुप्रयोग हैं: dmesg(1)और klogd(8)। पूर्व का उद्देश्य उपयोगकर्ताओं द्वारा रिंग बफर की सामग्री को प्रिंट करने की मांग पर चलाया जाना है। उत्तरार्द्ध एक डेमन है जो संदेशों को पढ़ता है /proc/kmsg(या कॉल करता है sys_syslog, यदि /procमाउंट नहीं है) और उन्हें syslogd(8)या कंसोल पर भेजता है। यह कर्नेल पक्ष को कवर करता है।
उपयोगकर्ता अंतरिक्ष में, वहाँ है syslogd(8)। यह एक डेमॉन है जो कई यूनिक्स डोमेन सॉकेट्स पर सुनता है (मुख्य रूप से /dev/log, लेकिन दूसरों को भी कॉन्फ़िगर किया जा सकता है), और वैकल्पिक रूप से संदेशों के लिए यूडीपी पोर्ट 514। यह संदेश भी प्राप्त करता है klogd(8)( syslogd(8)इसकी परवाह नहीं करता है /proc/kmsg)। यह तब इन संदेशों को कुछ फाइलों में /logया नामित पाइपों में लिखता है , या उन्हें कुछ दूरस्थ होस्ट ( syslogप्रोटोकॉल के माध्यम से , UDP पोर्ट 514 पर) में कॉन्फ़िगर किया गया है, के रूप में भेजता है /etc/syslog.conf।
उपयोगकर्ता-अंतरिक्ष अनुप्रयोग आम तौर पर संदेश लॉग करने के लिए libcफ़ंक्शन syslog(3)का उपयोग करते हैं । libcइन संदेशों को UNIX डोमेन सॉकेट /dev/log(जहाँ वे पढ़ते हैं syslogd(8)) पर भेजते हैं , लेकिन यदि कोई एप्लिकेशन chroot(2)-ed है तो संदेश अंत में अन्य सॉकेट्स को लिखे जा रहे हैं, फिर भी /var/named/dev/log। यह निश्चित रूप से, इन लॉग भेजने वाले अनुप्रयोगों के लिए और syslogd(8)इन सॉकेट्स के स्थान पर सहमत होने के लिए आवश्यक है । इन कारणों syslogd(8)से मानक से अलग अतिरिक्त सॉकेट्स को सुनने के लिए कॉन्फ़िगर किया जा सकता है /dev/log।
अंत में, syslogप्रोटोकॉल सिर्फ एक डेटाग्राम प्रोटोकॉल है। किसी भी एप्लिकेशन को किसी भी UNIX डोमेन सॉकेट में syslog डेटाग्राम भेजने से कोई भी रोकता नहीं है (बशर्ते कि उसकी साख इसे सॉकेट को खोलने की अनुमति देती है), syslog(3)फ़ंक्शन को libcपूरी तरह से दरकिनार करते हुए । यदि डेटाग्राम सही ढंग से स्वरूपित syslogd(8)हैं, तो उनका उपयोग कर सकते हैं जैसे कि संदेश के माध्यम से भेजे गए थे syslog(3)।
बेशक, उपरोक्त केवल "क्लासिक" लॉगिंग सिद्धांत को कवर करता है। अन्य डेमॉन (जैसे कि rsyslogऔर syslog-ngजैसा कि आप उल्लेख करते हैं) सादे को बदल सकते हैं syslogd(8), और सभी प्रकार की निफ्टी चीजें कर सकते हैं, जैसे एन्क्रिप्टेड टीसीपी कनेक्शन के माध्यम से दूरस्थ मेजबानों को संदेश भेजते हैं, उच्च संकल्प टाइमस्टैम्प प्रदान करते हैं, और इसी तरह। और वहाँ भी है systemd, कि धीरे धीरे लिनक्स के यूनिक्स भाग phagocytosing है। systemdअपने स्वयं के लॉगिंग तंत्र हैं, लेकिन उस कहानी को किसी और के द्वारा बताना होगा। :)
* BSD दुनिया के साथ मतभेद:
* BSD पर कोई नहीं है klogd(8), और /procया तो मौजूद नहीं है (OpenBSD पर) या ज्यादातर अप्रचलित है (FreeBSD और NetBSD पर)। syslogd(8)वर्ण डिवाइस से कर्नेल संदेश पढ़ता है /dev/klog, और कर्नेल नामों को डीकोड करने के लिए dmesg(1)उपयोग करता /dev/kmemहै। केवल ओपनबीएसडी में ए /dev/log। FreeBSD दो UNIX डोमेन सॉकेट्स का उपयोग करता है /var/run/logऔर var/rub/logprivइसके बजाय, और NetBSD a /var/run/log।
rsyslogउपयोग नहीं किया जाता है klogd(8)क्योंकि इसकी जड़ें वापस चली जाती हैं, इसलिए नहीं कि इसने हाल ही में इसके साथ दूर करने का स्पष्ट निर्णय लिया है। मेरी स्मृति हालांकि विफल हो सकती है। वैसे भी, जैसा मैंने कहा, मैं केवल "क्लासिक" लॉगिंग को कवर करने की कोशिश कर रहा था।
rsyslogdचल रहा है और एक Ubuntu 12.04 के साथ syslog-ngचल रहा है और वे दोनों दायर किया था /proc/kmsgके अनुसार खुला lsof, यानी klogdउपयोग नहीं किया गया। एक और दिलचस्प बात जो मैंने देखी वह यह है कि लॉग संदेश /proc/kmsgफ़ाइल में संग्रहीत किए जाते हैं यदि कोई साइलॉग डेमॉन नहीं चल रहा है और कोई भी उदाहरण catया पाठ संपादक के साथ देख सकता है । हालाँकि, केवल उन संदेशों को एक बार देखना संभव है क्योंकि वे देखने के बाद गायब हो जाते हैं। अंतिम लेकिन कम से कम, निष्पादन फ़ाइल dmesgकी सामग्री को स्पष्ट नहीं करता है /proc/kmsg।
/proc/kmsgएक नियमित फ़ाइल नहीं है, वहाँ कुछ भी "संग्रहीत" नहीं है, बल्कि यह कर्नेल के रिंग बफर का सिर्फ एक दृश्य है। आप इसे catठीक से पढ़ सकते हैं क्योंकि आपके पास कोई klogd(8)दौड़ नहीं है (आपको दौड़ना चाहिए klogd(8), cat /proc/kmsgब्लॉक होना चाहिए )। dmesg(1)के /dev/kmsgबजाय से संदेश पढ़ता है /proc/kmsg; और यह बफर को साफ कर सकता है यदि आप इसे बताते हैं।
systemd has its own logging mechanisms, but that story would have to be told by somebody else. :)- कृपया बताएं, आपको प्रतिभा मिली :-)
अन्य उत्तर बताते हैं, जैसा कि इसके लेखक कहते हैं, लिनक्स में "क्लासिक लॉगिंग"। यही कारण है कि आजकल बहुत सारी प्रणालियों में चीजें कैसे काम करती हैं।
कर्नेल तंत्र बदल गए हैं।
कर्नेल एक इन-मेमोरी बफर में आउटपुट उत्पन्न करता है। एप्लिकेशन सॉफ्टवेयर्स इसे दो तरीकों से एक्सेस कर सकते हैं। लॉगिंग सबसिस्टम आमतौर पर इसे नाम के छद्म-फीफो के रूप में एक्सेस करता है /proc/kmsg। लॉग जानकारी का यह स्रोत लॉग पाठकों के बीच उपयोगी रूप से साझा नहीं किया जा सकता है, क्योंकि यह एक बार पढ़ा जाता है। यदि कई प्रक्रियाएं इसे साझा करती हैं, तो वे प्रत्येक को कर्नेल लॉग डेटा स्ट्रीम का केवल एक हिस्सा प्राप्त करते हैं। यह भी केवल पढ़ने के लिए है।
इसे एक्सेस करने का दूसरा तरीका नया /dev/kmsgकैरेक्टर डिवाइस है। यह एक पढ़ा-लिखा इंटरफ़ेस है जो कई क्लाइंट प्रक्रियाओं के बीच साझा करने योग्य है। यदि कई प्रक्रियाएं इसे साझा करती हैं, तो वे सभी एक ही पूर्ण डेटा स्ट्रीम को पढ़ते हैं, एक दूसरे से अप्रभावित। यदि वे इसे लिखने की पहुंच के लिए खोलते हैं, तो वे संदेश को कर्नेल की लॉग स्ट्रीम में भी इंजेक्ट कर सकते हैं, जैसे कि वे कर्नेल द्वारा उत्पन्न किए गए थे।
/proc/kmsgऔर /dev/kmsgगैर- RFC-5424 फॉर्म में लॉग डेटा प्रदान करते हैं।
एप्लिकेशन बदल गए हैं।
जीएनयू सी लाइब्रेरी के syslog()मुख्य समारोह में एक AF_LOCALडाटाग्राम सॉकेट से जुड़ने का प्रयास किया जाता है, जिसे /dev/logलॉग एंट्रीज लिखा जाता है और इसे लॉग एंट्रीज लिखा जाता है। (बीएसडी सी लाइब्रेरी का syslog()फ़ंक्शन आजकल /var/run/logसॉकेट नाम के रूप में उपयोग करता है , और /var/run/logprivपहले कोशिश करता है ।) सीधे यह करने के लिए आवेदन का अपना कोड हो सकता है। लाइब्रेरी फ़ंक्शन केवल एप्लिकेशन का कोड, खोलने, कनेक्ट करने, लिखने और सॉकेट को बंद करने) का कोड है।
यदि कोई मशीन पर AF_INET/ AF_INET6डेटाग्राम सॉकेट पर सुन रहा है, तो अनुप्रयोग UFC के माध्यम से RFC 5424 संदेश स्थानीय RFC 5426 सर्वर पर भी भेज सकता है।
पिछले दो दशकों में डेमोंटोल्स की दुनिया के दबाव के लिए धन्यवाद, बहुत सारे डॉमन एक मोड में चल रहे हैं, जहां वे GNU syslog()C लाइब्रेरी फ़ंक्शन या UDP सॉकेट का उपयोग नहीं करते हैं, लेकिन मानक त्रुटि के लिए अपने लॉग डेटा को थूक देते हैं साधारण यूनिक्स फैशन।
टूलसेट के डेमोंटोल्स परिवार के साथ लॉगिंग में बहुत लचीलापन है। लेकिन पूरे परिवार में सामान्य तौर पर यह विचार है कि प्रत्येक "मुख्य" डूमोन में एक संबद्ध "लॉगिंग" डॉमन होता है। "मुख्य" dæmons गैर-डॉमॉन प्रक्रियाओं की तरह काम करते हैं और मानक त्रुटि (या मानक आउटपुट) के लिए अपने लॉग संदेश लिखते हैं, जिसे सेवा प्रबंधन सबसिस्टम एक पाइप के माध्यम से कनेक्ट करने की व्यवस्था करता है (जो इसे खुला रखता है ताकि लॉग डेटा खत्म न हो जाए "लॉगिंग" d servicemon के मानक इनपुट के लिए एक सेवा पुनरारंभ)।
"लॉगिंग" के सभी डॉमन एक प्रोग्राम चलाते हैं जो कहीं न कहीं लॉग होता है । आम तौर पर यह प्रोग्राम कुछ ऐसा होता है multilogया cyclogजो इसके मानक इनपुट से पढ़ता है और (नैनोसेकंड टाइमस्टैम्प्ड) लॉग फ़ाइलों को कड़ाई से आकार में छाया हुआ, स्वचालित रूप से घुमाए गए, विशेष-लेखन, निर्देशिका में लिखता है। आम तौर पर, ये भी, ये सभी व्यक्तिगत समर्पित अनपेक्षित उपयोगकर्ता खातों के तत्वावधान में चलते हैं।
इसलिए प्रत्येक सेवा के लॉग डेटा को अलग से संसाधित करने के साथ, एक बड़े पैमाने पर वितरित लॉगिंग सिस्टम के साथ समाप्त होता है।
एक या एक डेमोंटोल्स-परिवार सेवा प्रबंधन के तहत कुछ या जैसे चला सकते हैं । लेकिन डेमोंटोल्स की दुनिया ने कई साल पहले महसूस किया था कि "लॉगिंग" डमन्स के साथ सेवा प्रबंधन संरचना चीजों को सरल तरीके से करने के लिए बहुत करीने से उधार देती है। एक विशाल मिश-मैश में लॉग स्ट्रीम के सभी पंखे लगाने की आवश्यकता नहीं है, लॉग डेटा को पार्स करें, और फिर लॉग फाइल को अलग करने के लिए स्ट्रीम को वापस पंखा करें; और फिर (कुछ मामलों में) पक्ष पर एक अविश्वसनीय बाहरी लॉग रोटेशन तंत्र बोल्ट। अपने मानक लॉग प्रबंधन के हिस्से के रूप में डेमोनटूलस-पारिवारिक संरचना पहले से ही लॉग रोटेशन, लॉगफ़ाइल लेखन और स्ट्रीम पृथक्करण करती है।klogdsyslogdrsyslogd
इसके अलावा: सभी सेवाओं के लिए उपकरण के साथ विशेषाधिकारों को छोड़ने का चेन-लोडिंग मॉडल का मतलब है कि लॉगिंग कार्यक्रमों को सुपरयूसर विशेषाधिकारों की कोई आवश्यकता नहीं है; और UCSPI मॉडल का मतलब है कि उन्हें केवल स्ट्रीम बनाम डेटाग्राम ट्रांसपोर्ट जैसे मतभेदों के बारे में ध्यान रखने की आवश्यकता है।
नोश टूलसेट इसका उदाहरण देता है। जबकि कोई भी इसके rsyslogdअंतर्गत चला सकता है, बॉक्स से बाहर, और सिर्फ कर्नेल का प्रबंधन कर सकता है /run/log, और पुराने तरीके से UDP लॉग इनपुट; यह इन चीजों को लॉग करने के और अधिक "डेमोनटूल देशी" तरीके भी प्रदान करता है:
klogdसेवा जो इससे पढ़ती है /proc/kmsgऔर बस उस मानक त्रुटि के लिए लॉग स्ट्रीम लिखती है। यह नाम के एक साधारण प्रोग्राम द्वारा किया जाता है klog-read। संबंधित लॉगिंग d feedmon एक /var/log/sv/klogdलॉग डायरेक्टरी में अपने मानक इनपुट पर लॉग स्ट्रीम को फीड करता है ।local-syslog-readसेवा जो /dev/log( /run/logBSD पर) से डेटाग्राम पढ़ती है और बस उस लॉग स्ट्रीम को उसकी मानक त्रुटि पर लिखती है। यह नाम के एक कार्यक्रम द्वारा किया जाता है syslog-read। संबंधित लॉगिंग d associatedmon एक /var/log/sv/local-syslog-readलॉग डायरेक्टरी में अपने मानक इनपुट पर लॉग स्ट्रीम को फीड करता है ।udp-syslog-readसेवा जो UDP syslog पोर्ट पर सुनती है, पढ़ती है कि उसे क्या भेजा गया है और बस उस लॉग स्ट्रीम को उसकी मानक त्रुटि पर लिखती है। फिर से, कार्यक्रम है syslog-read। संबंधित लॉगिंग d associatedmon एक /var/log/sv/udp-syslog-readलॉग डायरेक्टरी में अपने मानक इनपुट पर लॉग स्ट्रीम को फीड करता है ।local-priv-syslog-readसेवा जिसमें से datagrams पढ़ता है /run/logprivऔर बस उस मानक त्रुटि के लिए लॉग स्ट्रीम लिखता है। फिर से, कार्यक्रम है syslog-read। संबंधित लॉगिंग d associatedmon एक /var/log/sv/local-priv-syslog-readलॉग डायरेक्टरी में अपने मानक इनपुट पर लॉग स्ट्रीम को फीड करता है ।टूलसेट भी एक export-to-rsyslogउपकरण के साथ आता है जो एक या कई लॉग निर्देशिकाओं (गैर-घुसपैठ लॉग कर्सर की एक प्रणाली का उपयोग करके) की निगरानी कर सकता है और आरएफसी 5424 फॉर्म में नेटवर्क पर एक निर्दिष्ट आरएफसी 5426 सर्वर पर नई प्रविष्टियां भेज सकता है।
systemd एक अखंड लॉग प्रबंधन कार्यक्रम है, systemd-journald। यह सिस्टमड द्वारा प्रबंधित सेवा के रूप में चलता है।
/dev/kmsgकर्नेल लॉग डेटा के लिए पढ़ता है ।/dev/log(एक प्रतीकात्मक लिंक /run/systemd/journal/dev-log) पढ़ता है syslog()।AF_LOCALस्ट्रीम सॉकेट पर सुनता है /run/systemd/journal/stdout।AF_LOCALडेटाग्राम सॉकेट पर /run/systemd/journal/socketलॉग ऑन प्रोग्राम्स से आने वाले डेटा के लिए सुनता है जो सिस्टमड-विशिष्ट जर्नल प्रोटोकॉल (यानी sd_journal_sendv()एट अल।) बोलते हैं ।/run/log/journal/या में लिखता है /var/log/journal/।AF_LOCALडेटाग्राम सॉकेट के लिए, /run/systemd/journal/syslogवहाँ जर्नल डेटा लिखता है, अगर syslog को अग्रेषित करना कॉन्फ़िगर किया गया है।/dev/kmsgतंत्र का उपयोग करके कर्नेल बफर को जर्नल डेटा लिखता है।यदि यह प्रोग्राम क्रैश हो जाता है, या सेवा बंद हो जाती है, तो खराब चीजें सिस्टम-वाइड हो जाती हैं।
systemd स्वयं मानक आउटपुट और /run/systemd/journal/stdoutसॉकेट से जुड़ी (कुछ) सेवाओं की त्रुटियों के लिए व्यवस्था करता है । इसलिए सामान्य फैशन में मानक त्रुटि के लिए लॉग इन करने वाले डॉमन्स का अपना आउटपुट जर्नल को भेज दिया जाता है।
यह पूरी तरह से klogd, syslogd, syslog-ng और rsyslogd को दबा देता है।
इन्हें अब सिस्टम-विशिष्ट होना आवश्यक है। एक systemd सिस्टम पर उन्हें सर्वर का अंत नहीं मिलता है /dev/log। इसके बजाय, वे दो तरीकों में से एक लेते हैं:
/run/systemd/journal/syslog, जो (यदि आपको याद है) systemd-journaldजर्नल डेटा को कनेक्ट करने और लिखने का प्रयास करता है। कुछ साल पहले, किसी ने imuxsockऐसा करने के लिए rsyslogd के इनपुट विधि को कॉन्फ़िगर किया होगा ।imjournalऐसा करने के लिए rsyslogd के इनपुट विधि को कॉन्फ़िगर करता है।