मैं systemd + rsyslog होस्ट में `/ dev / log` को कैसे पुनर्स्थापित करूं?

Question

RHEL7 पर, systemd-journaldएक बार जो किया गया था उसके कई जिम्मेदारियों को संभालता है rsyslogd। चाहे इन दो डेमों के बीच बग या संघर्ष, कभी-कभी /dev/logलापता हो जाएगा। परिणामस्वरूप, syslog(3)कॉल पर निर्भर प्रोग्राम ठीक से काम नहीं करेंगे, उदाहरण के लिए, सहित logger। मैं /dev/logसॉकेट को कैसे पुनर्स्थापित कर सकता हूं ?

Answer 1

मेरे स्वयं के प्रश्न पूछना और उत्तर देना क्योंकि Google इस पर बहुत मददगार नहीं था।

आम तौर पर, के साथ rsyslogd, imuxsockमॉड्यूल पैदा करेगा /dev/logसॉकेट अपने आप ही, इसे बनाने से पहले पिछली प्रविष्टि अनलिंक करने। जब rsyslogdरोक दिया जाता है (संभवतः क्योंकि पुनरारंभ जो दोषपूर्ण कॉन्फ़िगरेशन के कारण विफल हो जाता है), rsyslogd निकालता है /dev/log ।

हालांकि, आपूर्ति की गई rsyslog RHEL7के साथ संयोजन के रूप में उपयोग किए जाने की उम्मीद है systemd, और imuxsockमॉड्यूल वास्तव में /run/systemd/journal/syslogसॉकेट को खोल देगा और हटा देगा । इस बीच, /dev/logडिवाइस सिस्टम सर्विस-फाइल द्वारा बनाया जाता है systemd-journald.socketजो ट्रिगर करता है journald।

जाहिर है, $imjournalमॉड्यूल का उपयोग किया जाता है या नहीं , निम्नलिखित कार्य करता है।

संक्षेप में, यदि /dev/logगायब हो जाता है:

1. पुनः आरंभ करें systemd-journald.socket:

   systemctl restart systemd-journald.socket
   

2. फिर rsyslogd को पुनः आरंभ करें

   systemctl start rsyslogd
   

अद्यतन करें: मेरा मानना ​​है कि restart rsyslogdयदि rsyslogdपहले से ही चल रहा है तो सॉकेट को फिर से हटा सकते हैं ।

Comments

इस लिए आपका बहुत - बहुत धन्यवाद! मैंने अभी कई घंटे खो दिए हैं कि लॉगिंग किसी सेवा के लिए काम क्यों नहीं कर रही है। मैंने अंत में इसे लापता / देव / लॉग को ट्रैक किया, जो मुझे आपके समाधान की ओर ले जाता है।

— चाड हुनेयकट

Answer 2

systemctl restart systemd-journald.socket && systemctl restart rsyslogसमाधान उबंटू 16.04 पर मेरे लिए काम नहीं किया।

इसके बजाय, मुझे /dev/logएक सिम्लिंक के रूप में फिर से बनाना पड़ा /run/systemd/journal/dev-log:

ln -s /run/systemd/journal/dev-log /dev/log

Comments

हां, मैन्युअल रूप से लिंक करने के लिए भी काम करना चाहिए। लेकिन यह याद करने के लिए थोड़ा सा बोझिल है। प्रश्न: उबंटू systemd-journald.socketमें एक सेवा के रूप में मौजूद है? Q2: शायद restart rsyslogdसमस्या थी? शायद यह बस होना चाहिए start rsyslogd?

— ओथियस

Q1: हाँ, यह मौजूद है। Q2: कोई restartआदेश नहीं है, वहाँ serviceऔर है /etc/init.d/rsyslog।

— १११ 9१

तक restart rsyslogdमैंने सोचा कि यह स्पष्ट मैं मतलब था systemctl restart rsyslogd। क्या उबंटू अभी भी rsyslog के लिए init स्क्रिप्ट का उपयोग करता है?

— ओथियस

@Otheus /etc/init.d/rsyslog stopने इसके बाद /etc/init.d/rsyslog startमदद नहीं की। न तो systemctl stop syslog.socket rsyslog.service && systemctl start syslog.socket rsyslog.serviceमेरे सिस्टम पर दोनों /lib/systemd/system/rsyslog.serviceऔर है /etc/init.d/rsyslog। फिर भी, मैं इस समस्या पर अधिक समय नहीं देना चाहता।

— १११

Answer 3

मेरे लिए यह एक समस्या थी कि rsyslog में प्रयुक्त imuxsock मॉड्यूल सिस्टमैड के साथ कैसे काम कर रहा था।

में imuxsock प्रलेखन वे के माध्यम से चलना कैसे मॉड्यूल systemd के लिए काम करने के लिए माना जाता है। चरण 1 वह जगह थी जहाँ मैं मुद्दों को देख रहा था:

चरण 1: सिस्टम सॉकेट का नाम चुनें

1. यदि उपयोगकर्ता ने स्पष्ट रूप से SysSock.Use = "बंद" सेट करने के लिए नहीं चुना है, तो डिफ़ॉल्ट श्रोता सॉकेट (उर्फ, "सिस्टम लॉग सॉकेट" या बस "सिस्टम सॉकेट") नाम / देव / लॉग पर सेट है। अन्यथा, यदि उपयोगकर्ता ने स्पष्ट रूप से SysSock.Use = "बंद" सेट किया है, तो rsyslog SysSock.Name पैरामीटर द्वारा परिभाषित / dev / log या किसी भी सॉकेट पर नहीं सुनेगा और इस खंड के बाकी हिस्से पर लागू नहीं होता है।

2. यदि उपयोगकर्ता ने sysSock.Name = "/ path / to / custom / socket" निर्दिष्ट किया है (और स्पष्ट रूप से SysSock.Use = "off") सेट नहीं किया है, तो डिफ़ॉल्ट श्रोता सॉकेट नाम को "पथ / / to / custom / socket के साथ ओवरराइट किया जाता है" ।

3. अन्यथा, अगर rsyslog systemd और / run / systemd / journal / syslog के अंतर्गत चल रहा है, (और उपयोगकर्ता ने स्पष्ट रूप से SysSock.Use = "off") सेट नहीं किया है, तो डिफ़ॉल्ट श्रोता सॉकेट का नाम / रन / systemd / पत्रिका के साथ ओवरराइट हो जाता है / syslog।

सिस्टम को चरण 3 में गिरना चाहिए और डिफ़ॉल्ट पथ को "/ run / systemd / journal / syslog" में बदलना चाहिए, लेकिन इसके बजाय यह शेष था "/ var / log"। इसका मतलब यह था कि imuxsock मॉड्यूल कोशिश करेगा (और कभी-कभी सफल होगा) / डेव / लॉग पर एक सॉकेट बनाने के लिए जहां सिस्टम-जर्नल-देव-लॉग-लॉकेट द्वारा प्रतीकात्मक लिंक बनाया जाना चाहिए। इस मामले में कि यह असली सॉकेट बनाने में विफल होगा, प्रतीकात्मक लिंक अभी भी हटा दिया जाएगा।

यह दस्तावेज rsyslog github पर रिपोर्ट किए गए इस मुद्दे का परिणाम था । यदि आप चर्चा को छोड़ना चाहते हैं और क्रमशः PR # 1 और PR # 2 में परिवर्तन देखें ।

मेरा समाधान सिर्फ मेरे /etc/rsyslog.conf में systemd पथ का उपयोग करने के लिए imuxsock मॉड्यूल को कॉन्फ़िगर करना था:

module(load="imuxsock"
    SysSock.Name="/run/systemd/journal/syslog")

ऐसा लगता है कि मेरा मुद्दा ठीक हो गया है और एक अच्छे समाधान की तरह लग रहा है क्योंकि यह बताता है कि जब आप मैन्युअल रूप से इसे बनाएंगे तो प्रतीकात्मक लिंक फिर से क्यों गायब हो सकता है।

यदि आप अपने सिस्टम को देखते हैं और "/ run / systemd / journal / syslog" को "syslog.socket" में देखने के लिए उपस्थित नहीं हैं, तो यह देखें कि क्या यह सफलतापूर्वक शुरू हो रहा है, जो सॉकेट बनाने के लिए जिम्मेदार है।

systemctl status syslog.socket

यह हो सकता है कि rsyslog.service का आपका संस्करण syslog.service को एक उपनाम के रूप में परिभाषित नहीं करता है, जिसकी आवश्यकता है क्योंकि syslog.socket उस सेवा को सक्रिय करने का प्रयास करता है। यह भी संभव है कि कई लॉगिंग सेवाएं उर्फ ​​syslog.service को करने की कोशिश करती हैं, जिस स्थिति में अंतिम रूप से सक्षम जीत हासिल होती है।