systemd लॉग्स में महारत: Linux पर journalctl का उपयोग करने की पूरी गाइड

systemd जर्नल और journalctl लॉगिंग का परिचय

systemd के कुछ सबसे सम्मोहक लाभ प्रक्रिया और सिस्टम लॉगिंग से जुड़े हैं। अन्य टूल का उपयोग करते समय, लॉग आमतौर पर सिस्टम भर में बिखरे होते हैं, विभिन्न डेमॉन और प्रक्रियाओं द्वारा नियंत्रित होते हैं, और जब वे कई एप्लिकेशन में फैले होते हैं तो व्याख्या करना काफी मुश्किल हो सकता है। systemd एक केंद्रीकृत प्रबंधन समाधान प्रदान करके इन मुद्दों को संबोधित करने का प्रयास करता है जो सभी कर्नेल और यूजरलैंड प्रक्रियाओं को लॉग करता है। वह सिस्टम जो इन लॉग को एकत्र और प्रबंधित करता है, जर्नल के रूप में जाना जाता है।

जर्नल को journald डेमॉन द्वारा लागू किया गया है, जो कर्नेल, इनिटर्ड, सेवाओं आदि द्वारा उत्पादित सभी संदेशों को संभालता है। इस गाइड में, हम चर्चा करेंगे कि journalctl यूटिलिटी का उपयोग कैसे करें, जिसका उपयोग जर्नल के भीतर रखे गए डेटा तक पहुंचने और हेरफेर करने के लिए किया जा सकता है।

इस लेख में, आप सीखेंगे कि journalctl कमांड-लाइन टूल का उपयोग करके systemd जर्नल से लॉग डेटा तक कैसे पहुंचें और फ़िल्टर करें। हम कवर करेंगे कि विशिष्ट बूट या समय सीमा से लॉग कैसे देखें, सिस्टम यूनिट, उपयोगकर्ताओं, या प्राथमिकता स्तरों द्वारा फ़िल्टर करें, और JSON जैसे प्रारूपों में लॉग आउटपुट करें ताकि अन्य टूल के साथ एकीकरण हो सके। आप वास्तविक समय की घटनाओं की निगरानी करना, डिस्क उपयोग प्रबंधित करना, लगातार लॉगिंग कॉन्फ़िगर करना, और लापता लॉग या अनुमति त्रुटियों जैसे सामान्य मुद्दों को हल करना भी सीखेंगे। चाहे आप एक विफल सेवा को डीबग कर रहे हों या केंद्रीकृत लॉग संग्रह स्थापित कर रहे हों, journalctl आपके वर्कफ़्लो को सुव्यवस्थित करने के लिए लचीलापन और सटीकता प्रदान करता है।

मुख्य निष्कर्ष

• systemd जर्नल एक एकीकृत लॉगिंग सिस्टम प्रदान करता है जो कर्नेल, सेवाओं, और उपयोगकर्ता एप्लिकेशन से संदेशों को एक केंद्रीकृत, अनुक्रमित लॉग में कैप्चर करता है।
• journalctl कमांड आपको बूट सत्र, समय सीमा, systemd यूनिट, प्रोसेस ID, उपयोगकर्ता ID, समूह ID, और अधिक द्वारा लॉग फ़िल्टर करने की अनुमति देती है, जिससे प्रासंगिक घटनाओं को इंगित करना आसान हो जाता है।
• आप --since, --until, या "1 hour ago" या "yesterday" जैसे सापेक्ष अभिव्यक्तियों का उपयोग करके विशिष्ट समय विंडो से लॉग प्राप्त कर सकते हैं।
• लॉग को सादे टेक्स्ट, JSON, और वर्बोज़ मोड जैसे विभिन्न प्रारूपों में प्रदर्शित किया जा सकता है, जिससे बाहरी टूल के साथ एकीकरण या विश्लेषण के लिए पार्स करना आसान हो जाता है।
• journalctl -f का उपयोग करके, आप लॉग संदेशों का लाइव अनुसरण कर सकते हैं जैसे ही वे लिखे जाते हैं, tail -f के समान, जो सिस्टम गतिविधि या सेवा व्यवहार की वास्तविक समय में निगरानी के लिए उपयोगी है।
• डिफ़ॉल्ट रूप से, लॉग मेमोरी में संग्रहीत हो सकते हैं और रीबूट पर खो सकते हैं। आप /var/log/journal बनाकर और journald.conf को तदनुसार कॉन्फ़िगर करके लगातार लॉगिंग सक्षम कर सकते हैं।
• जर्नल के स्टोरेज फुटप्रिंट को --disk-usage, --vacuum-size, और --vacuum-time जैसे कमांड के साथ प्रबंधित किया जा सकता है, साथ ही अधिकतम आकार और प्रतिधारण को नियंत्रित करने के लिए कॉन्फ़िगरेशन विकल्प।
• journalctl बूट और यूनिट में लॉग को एकत्रित करके सेवा डीबगिंग को सरल बनाता है, जिससे विफलताओं की पहचान करना, SSH एक्सेस ट्रैक करना, और विस्तृत संदर्भ के साथ मुद्दों की जांच करना आसान हो जाता है।

systemd जर्नल कैसे काम करता है और यह क्यों मायने रखता है

systemd जर्नल के पीछे प्रेरणाओं में से एक यह है कि संदेश कहां से उत्पन्न हो रहे हैं, इसकी परवाह किए बिना लॉग के प्रबंधन को केंद्रीकृत किया जाए। चूंकि बूट प्रक्रिया और सेवा प्रबंधन का अधिकांश हिस्सा systemd प्रक्रिया द्वारा नियंत्रित किया जाता है, इसलिए लॉग एकत्र और एक्सेस किए जाने के तरीके को मानकीकृत करना समझ में आता है। journald डेमॉन सभी उपलब्ध स्रोतों से डेटा एकत्र करता है और इसे आसान और गतिशील हेरफेर के लिए बाइनरी प्रारूप में संग्रहीत करता है।

यह हमें कई महत्वपूर्ण लाभ देता है। एक ही यूटिलिटी का उपयोग करके डेटा के साथ बातचीत करके, प्रशासक अपनी आवश्यकताओं के अनुसार लॉग डेटा को गतिशील रूप से प्रदर्शित करने में सक्षम होते हैं। यह तीन बूट पहले के बूट डेटा को देखने जितना सरल हो सकता है, या दो संबंधित सेवाओं से लॉग प्रविष्टियों को क्रमिक रूप से संयोजित करके संचार समस्या को डीबग करना।

लॉग डेटा को बाइनरी प्रारूप में संग्रहीत करने का अर्थ यह भी है कि डेटा को पल की आवश्यकता के आधार पर मनमाने आउटपुट प्रारूप में प्रदर्शित किया जा सकता है। उदाहरण के लिए, दैनिक लॉग प्रबंधन के लिए आप मानक syslog प्रारूप में लॉग देखने के आदी हो सकते हैं, लेकिन यदि आप बाद में सेवा रुकावटों को ग्राफ करना चाहते हैं, तो आप प्रत्येक प्रविष्टि को JSON ऑब्जेक्ट के रूप में आउटपुट कर सकते हैं ताकि यह आपकी ग्राफिंग सेवा के लिए उपभोग योग्य हो। चूंकि डेटा सादे टेक्स्ट में डिस्क पर नहीं लिखा जाता है, इसलिए जब आपको एक अलग ऑन-डिमांड प्रारूप की आवश्यकता होती है तो कोई रूपांतरण आवश्यक नहीं होता है।

systemd जर्नल का उपयोग मौजूदा syslog कार्यान्वयन के साथ किया जा सकता है, या यह आपकी आवश्यकताओं के आधार पर syslog कार्यक्षमता को प्रतिस्थापित कर सकता है। जबकि systemd जर्नल अधिकांश प्रशासकों की लॉगिंग जरूरतों को कवर करेगा, यह मौजूदा लॉगिंग तंत्र को भी पूरक कर सकता है। उदाहरण के लिए, आपके पास एक केंद्रीकृत syslog सर्वर हो सकता है जिसका उपयोग आप कई सर्वरों से डेटा संकलित करने के लिए करते हैं, लेकिन आप systemd जर्नल के साथ एक ही सिस्टम पर कई सेवाओं के लॉग को इंटरलीव भी करना चाह सकते हैं। आप इन प्रौद्योगिकियों को संयोजित करके दोनों कर सकते हैं।

timedatectl के साथ सही सिस्टम समय कैसे सेट करें

लॉगिंग के लिए बाइनरी जर्नल का उपयोग करने के लाभों में से एक यह है कि लॉग रिकॉर्ड को UTC या स्थानीय समय में इच्छानुसार देखा जा सकता है। डिफ़ॉल्ट रूप से, systemd परिणामों को स्थानीय समय में प्रदर्शित करेगा।

इसके कारण, जर्नल के साथ शुरू करने से पहले, हम सुनिश्चित करेंगे कि टाइमज़ोन सही ढंग से सेट है। systemd सूट वास्तव में timedatectl नामक एक टूल के साथ आता है जो इसमें मदद कर सकता है।

पहले, list-timezones विकल्प के साथ उपलब्ध टाइमज़ोन देखें:

timedatectl list-timezones

यह आपके सिस्टम पर उपलब्ध टाइमज़ोन को सूचीबद्ध करेगा। जब आपको वह मिल जाए जो आपके सर्वर के स्थान से मेल खाता है, तो आप set-timezone विकल्प का उपयोग करके इसे सेट कर सकते हैं:

sudo timedatectl set-timezone zone

यह सुनिश्चित करने के लिए कि आपका मशीन अब सही समय का उपयोग कर रहा है, timedatectl कमांड का उपयोग अकेले या status विकल्प के साथ करें। प्रदर्शन समान होगा:

timedatectl status

 Local time: Fri 2021-07-09 14:44:30 EDT Universal time: Fri 2021-07-09 18:44:30 UTC RTC time: Fri 2021-07-09 18:44:31 Time zone: America/New_York (EDT, -0400) System clock synchronized: yes NTP service: active RTC in local TZ: no 

पहली पंक्ति को सही समय प्रदर्शित करना चाहिए।

journalctl के साथ लॉग कैसे देखें

journald डेमॉन द्वारा एकत्र किए गए लॉग देखने के लिए, journalctl कमांड का उपयोग करें।

जब अकेले उपयोग किया जाता है, तो सिस्टम में मौजूद हर जर्नल प्रविष्टि एक पेजर (आमतौर पर less) में प्रदर्शित होगी जिसे आप ब्राउज़ कर सकते हैं। सबसे पुरानी प्रविष्टियां शीर्ष पर होंगी:

journalctl

-- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. -- Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49. Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49. Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd). Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules. Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules. Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/ Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 8 users, 102 roles, 4976 types, 294 bools, 1 sens, Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 83 classes, 104131 rules . . . 

आपके पास स्क्रॉल करने के लिए पेज और पेज डेटा होगा, जो दसियों या लाखों लाइनों तक लंबा हो सकता है अगर systemd लंबे समय से आपके सिस्टम पर है। यह दर्शाता है कि जर्नल डेटाबेस में कितना डेटा उपलब्ध है।

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

आप देख सकते हैं कि प्रदर्शित सभी टाइमस्टैम्प स्थानीय समय हैं। यह अब हर लॉग प्रविष्टि के लिए उपलब्ध है क्योंकि हमने अपने सिस्टम पर स्थानीय समय को सही ढंग से सेट कर लिया है। सभी लॉग इस नई जानकारी का उपयोग करके प्रदर्शित किए जाते हैं।

यदि आप टाइमस्टैम्प को UTC में प्रदर्शित करना चाहते हैं, तो आप --utc फ्लैग का उपयोग कर सकते हैं:

journalctl --utc

journalctl के साथ समय के अनुसार systemd लॉग फ़िल्टर करें

इस तरह के बड़े डेटा संग्रह तक पहुंच निश्चित रूप से उपयोगी है, लेकिन इतनी बड़ी मात्रा में जानकारी को मैन्युअली इंस्पेक्ट और प्रोसेस करना मुश्किल या असंभव हो सकता है। इस वजह से, journalctl की सबसे महत्वपूर्ण विशेषताओं में से एक इसके फ़िल्टरिंग विकल्प हैं।

journalctl के साथ वर्तमान बूट सत्र से लॉग दिखाएं

इनमें से सबसे बुनियादी जिसका आप दैनिक उपयोग कर सकते हैं, वह है -b फ्लैग। यह आपको सबसे हालिया रीबूट के बाद से एकत्र की गई सभी जर्नल प्रविष्टियों को दिखाएगा।

journalctl -b

यह आपको अपने वर्तमान वातावरण से संबंधित जानकारी की पहचान और प्रबंधन करने में मदद करेगा।

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

. . . -- Reboot -- . . . 

इसका उपयोग जानकारी को बूट सत्र में तार्किक रूप से अलग करने में मदद के लिए किया जा सकता है।

journalctl का उपयोग करके पिछले बूट से लॉग कैसे एक्सेस करें

जबकि आप आमतौर पर वर्तमान बूट से जानकारी प्रदर्शित करना चाहेंगे, निश्चित रूप से ऐसे समय होते हैं जब पिछले बूट भी सहायक होंगे। जर्नल कई पिछले बूट से जानकारी सहेज सकता है, इसलिए journalctl को आसानी से जानकारी प्रदर्शित करने के लिए बनाया जा सकता है।

कुछ वितरण डिफ़ॉल्ट रूप से पिछले बूट जानकारी को सहेजने में सक्षम करते हैं, जबकि अन्य इस सुविधा को अक्षम करते हैं। लगातार बूट जानकारी सक्षम करने के लिए, आप या तो जर्नल को स्टोर करने के लिए निर्देशिका बना सकते हैं:

sudo mkdir -p /var/log/journal

या आप जर्नल कॉन्फ़िगरेशन फ़ाइल संपादित कर सकते हैं:

sudo nano /etc/systemd/journald.conf

[Journal] अनुभाग के तहत, लगातार लॉगिंग सक्षम करने के लिए Storage= विकल्प को "persistent" पर सेट करें:

/etc/systemd/journald.conf

. . . [Journal] Storage=persistent 

जब आपके सर्वर पर पिछले बूट सहेजना सक्षम होता है, तो journalctl बूट के साथ काम करने में आपकी सहायता के लिए कुछ कमांड प्रदान करता है। journald के बारे में जानने वाले बूट को देखने के लिए, journalctl के साथ --list-boots विकल्प का उपयोग करें:

journalctl --list-boots

-2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC -1 13883d180dc0420db0abcb5fa26d6198 Tue 2025-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC 0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC 

यह प्रत्येक बूट के लिए एक लाइन प्रदर्शित करेगा। पहला कॉलम बूट के लिए ऑफसेट है जिसे journalctl के साथ बूट को आसानी से संदर्भित करने के लिए उपयोग किया जा सकता है। यदि आपको एक पूर्ण संदर्भ की आवश्यकता है, तो बूट ID दूसरे कॉलम में है। आप अंत में सूचीबद्ध दो समय विशिष्टताओं के साथ बूट सत्र द्वारा संदर्भित समय बता सकते हैं।

इन बूट से जानकारी प्रदर्शित करने के लिए, आप पहले या दूसरे कॉलम से जानकारी का उपयोग कर सकते हैं।

उदाहरण के लिए, पिछले बूट से जर्नल देखने के लिए, -b फ्लैग के साथ -1 सापेक्ष पॉइंटर का उपयोग करें:

journalctl -b -1

आप बूट ID का उपयोग करके बूट से डेटा को वापस बुला सकते हैं:

journalctl -b caf0524a1d394ce0bdbcff75b94444fe

कस्टम तिथि और समय सीमा के अनुसार journalctl लॉग फ़िल्टर करें

बूट द्वारा लॉग प्रविष्टियों को देखना अविश्वसनीय रूप से उपयोगी है, अक्सर आप उन समय की विंडो का अनुरोध करना चाह सकते हैं जो सिस्टम बूट के साथ अच्छी तरह से संरेखित नहीं होती हैं। यह लंबे समय तक चलने वाले सर्वर के साथ महत्वपूर्ण अपटाइम के साथ काम करते समय विशेष रूप से सच हो सकता है।

आप --since और --until विकल्पों का उपयोग करके मनमाने समय सीमा से फ़िल्टर कर सकते हैं, जो प्रदर्शित प्रविष्टियों को दिए गए समय के बाद या पहले तक सीमित करते हैं, क्रमशः।

समय मान विभिन्न प्रारूपों में आ सकते हैं। पूर्ण समय मान के लिए, आपको निम्न प्रारूप का उपयोग करना चाहिए:

YYYY-MM-DD HH:MM:SS

उदाहरण के लिए, हम 10 जनवरी, 2015 को शाम 5:15 बजे से सभी प्रविष्टियों को देख सकते हैं:

journalctl --since "2015-01-10 17:15:00"

यदि उपरोक्त प्रारूप के घटक छोड़े जाते हैं, तो कुछ डिफ़ॉल्ट लागू होंगे। उदाहरण के लिए, यदि तिथि छोड़ी जाती है, तो वर्तमान तिथि मान ली जाएगी। यदि समय घटक गायब है, तो "00:00:00" (आधी रात) प्रतिस्थापित किया जाएगा। सेकंड फ़ील्ड को भी "00" पर डिफ़ॉल्ट करने के लिए छोड़ा जा सकता है:

journalctl --since "2015-01-10" --until "2015-01-11 03:00"

जर्नल कुछ सापेक्ष मान और नामित शॉर्टकट भी समझता है। उदाहरण के लिए, आप "कल", "आज", "कल", या "अब" शब्दों का उपयोग कर सकते हैं। आप एक संख्यात्मक मान से पहले "-" या "+" लगाकर या "ago" जैसे शब्दों का उपयोग करके वाक्य निर्माण में सापेक्ष समय कर सकते हैं।

कल से डेटा प्राप्त करने के लिए, आप टाइप कर सकते हैं:

journalctl --since yesterday

यदि आपको सुबह 9:00 बजे शुरू होने वाले सेवा रुकावट की रिपोर्ट मिली और एक घंटे पहले तक जारी रही, तो आप टाइप कर सकते हैं:

journalctl --since 09:00 --until "1 hour ago"

जैसा कि आप देख सकते हैं, उन प्रविष्टियों को फ़िल्टर करने के लिए समय की लचीली विंडो को परिभाषित करना अपेक्षाकृत सरल है जिन्हें आप देखना चाहते हैं।

सर्विस, PID, या उपयोगकर्ता के अनुसार systemd जर्नल लॉग फ़िल्टर करें

ऊपर, हमने समय प्रतिबंधों का उपयोग करके जर्नल डेटा फ़िल्टर करने के कुछ तरीके सीखे। इस अनुभाग में हम चर्चा करेंगे कि आप जिस सेवा या घटक में रुचि रखते हैं, उसके आधार पर फ़िल्टर कैसे करें। systemd जर्नल ऐसा करने के कई तरीके प्रदान करता है।

Systemd सर्विस यूनिट द्वारा लॉग देखें

शायद फ़िल्टर करने का सबसे उपयोगी तरीका वह यूनिट है जिसमें आप रुचि रखते हैं। हम -u विकल्प का उपयोग करके इस तरह फ़िल्टर कर सकते हैं।

उदाहरण के लिए, हमारे सिस्टम पर Nginx यूनिट से सभी लॉग देखने के लिए, हम टाइप कर सकते हैं:

journalctl -u nginx.service

आमतौर पर, आप शायद समय के अनुसार भी फ़िल्टर करना चाहेंगे ताकि उन पंक्तियों को प्रदर्शित किया जा सके जिनमें आप रुचि रखते हैं। उदाहरण के लिए, आज सेवा कैसे चल रही है, यह जांचने के लिए, आप टाइप कर सकते हैं:

journalctl -u nginx.service --since today

जब आप जर्नल की विभिन्न यूनिट से रिकॉर्ड को इंटरलीव करने की क्षमता का लाभ उठाते हैं तो इस प्रकार का फोकस अत्यधिक सहायक हो जाता है। उदाहरण के लिए, यदि आपकी Nginx प्रक्रिया डायनामिक कंटेंट को संसाधित करने के लिए PHP-FPM यूनिट से जुड़ी है, तो आप दोनों यूनिट निर्दिष्ट करके दोनों से प्रविष्टियों को कालानुक्रमिक क्रम में मर्ज कर सकते हैं:

journalctl -u nginx.service -u php-fpm.service --since today

यह व्यक्तिगत प्रक्रियाओं के बजाय सिस्टम को डीबग करने के लिए विभिन्न प्रोग्रामों के बीच इंटरैक्शन को पहचानना बहुत आसान बना सकता है।

PID, UID, या GID द्वारा systemd लॉग फ़िल्टर करें

कुछ सेवाएं काम करने के लिए विभिन्न चाइल्ड प्रोसेस को जन्म देती हैं। यदि आपने उस प्रक्रिया की सटीक PID का पता लगा लिया है जिसमें आप रुचि रखते हैं, तो आप उसके अनुसार भी फ़िल्टर कर सकते हैं।

इसे करने के लिए हम _PID फ़ील्ड निर्दिष्ट करके फ़िल्टर कर सकते हैं। उदाहरण के लिए, यदि हमारी रुचि की PID 8088 है, तो हम टाइप कर सकते हैं:

journalctl _PID=8088

अन्य समय में, आप किसी विशिष्ट उपयोगकर्ता या समूह से लॉग की गई सभी प्रविष्टियों को दिखाना चाह सकते हैं। यह _UID या _GID फ़िल्टर के साथ किया जा सकता है। उदाहरण के लिए, यदि आपका वेब सर्वर www-data उपयोगकर्ता के तहत चलता है, तो आप टाइप करके उपयोगकर्ता ID ढूंढ सकते हैं:

id -u www-data

33

इसके बाद, आप जर्नल परिणामों को फ़िल्टर करने के लिए वापस की गई ID का उपयोग कर सकते हैं:

journalctl _UID=33 --since today

systemd जर्नल में कई फ़ील्ड हैं जिनका उपयोग फ़िल्टरिंग के लिए किया जा सकता है। उनमें से कुछ लॉग की जा रही प्रक्रिया से पारित होते हैं और कुछ journald द्वारा उस समय सिस्टम से एकत्र की गई जानकारी का उपयोग करके लागू होते हैं।

अग्रणी अंडरस्कोर इंगित करता है कि _PID फ़ील्ड बाद के प्रकार का है। जर्नल बाद में फ़िल्टरिंग के लिए लॉगिंग करने वाली प्रक्रिया के PID को स्वचालित रूप से रिकॉर्ड और इंडेक्स करता है। आप निम्न टाइप करके सभी उपलब्ध जर्नल फ़ील्ड के बारे में जान सकते हैं:

man systemd.journal-fields

हम इस गाइड में इनमें से कुछ पर चर्चा करेंगे। अभी के लिए, हम फ़ील्ड द्वारा फ़िल्टरिंग से संबंधित एक और उपयोगी विकल्प पर जाएंगे। -F विकल्प का उपयोग किसी दिए गए जर्नल फ़ील्ड के लिए सभी उपलब्ध मान दिखाने के लिए किया जा सकता है।

उदाहरण के लिए, यह देखने के लिए कि systemd जर्नल में किन समूह IDs के लिए प्रविष्टियां हैं, आप टाइप कर सकते हैं:

journalctl -F _GID

32 99 102 133 81 84 100 0 124 87

यह आपको समूह ID फ़ील्ड के लिए जर्नल में संग्रहीत सभी मान दिखाएगा। यह आपके फ़िल्टर बनाने में मदद कर सकता है।

निष्पादन योग्य पथ द्वारा लॉग देखें

हम एक पथ स्थान प्रदान करके भी फ़िल्टर कर सकते हैं।

यदि पथ एक निष्पादन योग्य की ओर जाता है, तो journalctl प्रश्न में निष्पादन योग्य से जुड़ी सभी प्रविष्टियों को प्रदर्शित करेगा। उदाहरण के लिए, bash निष्पादन योग्य से जुड़ी उन प्रविष्टियों को खोजने के लिए, आप टाइप कर सकते हैं:

journalctl /usr/bin/bash

आमतौर पर, यदि निष्पादन योग्य के लिए एक यूनिट उपलब्ध है, तो वह विधि क्लीनर है और बेहतर जानकारी प्रदान करती है (संबंधित चाइल्ड प्रोसेस से प्रविष्टियां, आदि)। हालांकि, कभी-कभी यह संभव नहीं है।

journalctl -k का उपयोग करके कर्नेल लॉग कैसे देखें

कर्नेल संदेश, जो आमतौर पर dmesg आउटपुट में पाए जाते हैं, जर्नल से भी प्राप्त किए जा सकते हैं।

केवल इन संदेशों को प्रदर्शित करने के लिए, हम अपने कमांड में -k या --dmesg फ्लैग जोड़ सकते हैं:

journalctl -k

डिफ़ॉल्ट रूप से, यह वर्तमान बूट से कर्नेल संदेश प्रदर्शित करेगा। आप पहले चर्चा किए गए सामान्य बूट चयन फ्लैग का उपयोग करके एक वैकल्पिक बूट निर्दिष्ट कर सकते हैं। उदाहरण के लिए, पांच बूट पहले से संदेश प्राप्त करने के लिए, आप टाइप कर सकते हैं:

journalctl -k -b -5

journalctl -p के साथ गंभीरता स्तर द्वारा लॉग फ़िल्टर करें

एक फ़िल्टर जिसमें सिस्टम प्रशासक अक्सर रुचि रखते हैं वह है संदेश प्राथमिकता। जबकि बहुत वर्बोज़ स्तर पर जानकारी लॉग करना अक्सर उपयोगी होता है, जब वास्तव में उपलब्ध जानकारी को पचाने की बात आती है, तो कम प्राथमिकता वाले लॉग विचलित और भ्रमित करने वाले हो सकते हैं।

आप journalctl का उपयोग केवल निर्दिष्ट प्राथमिकता या उससे ऊपर के संदेशों को प्रदर्शित करने के लिए -p विकल्प का उपयोग करके कर सकते हैं। यह आपको कम प्राथमिकता वाले संदेशों को फ़िल्टर आउट करने की अनुमति देता है।

उदाहरण के लिए, केवल त्रुटि स्तर या उससे ऊपर पर लॉग की गई प्रविष्टियों को दिखाने के लिए, आप टाइप कर सकते हैं:

journalctl -p err -b

यह आपको त्रुटि, क्रिटिकल, अलर्ट, या आपातकाल के रूप में चिह्नित सभी संदेश दिखाएगा। जर्नल मानक syslog संदेश स्तरों को लागू करता है। आप प्राथमिकता नाम या उसके संबंधित संख्यात्मक मान दोनों का उपयोग कर सकते हैं। उच्चतम से निम्नतम प्राथमिकता के क्रम में, ये हैं:

• 0: emerg
• 1: alert
• 2: crit
• 3: err
• 4: warning
• 5: notice
• 6: info
• 7: debug

उपरोक्त संख्याओं या नामों का उपयोग -p विकल्प के साथ परस्पर विनिमय किया जा सकता है। एक प्राथमिकता का चयन करने से निर्दिष्ट स्तर और उससे ऊपर के स्तर पर चिह्नित संदेश प्रदर्शित होंगे।

journalctl लॉग आउटपुट डिस्प्ले अनुकूलित करें

ऊपर, हमने फ़िल्टरिंग के माध्यम से प्रविष्टि चयन का प्रदर्शन किया। ऐसे अन्य तरीके हैं जिनसे हम आउटपुट को संशोधित कर सकते हैं। हम विभिन्न आवश्यकताओं के अनुरूप journalctl डिस्प्ले को समायोजित कर सकते हैं।

journalctl में आउटपुट लंबाई और फ़ॉर्मेटिंग को कैसे नियंत्रित करें

हम journalctl को डेटा प्रदर्शित करने के तरीके को समायोजित कर सकते हैं यह बताकर कि आउटपुट को छोटा या विस्तारित करें।

डिफ़ॉल्ट रूप से, journalctl पेजर में पूरी प्रविष्टि दिखाएगा, जिससे प्रविष्टियां स्क्रीन के दाईं ओर ट्रेल हो जाएंगी। इस जानकारी को दायां तीर कुंजी दबाकर एक्सेस किया जा सकता है।

यदि आप आउटपुट को छोटा करना पसंद करते हैं, जहां जानकारी हटा दी गई है वहां दीर्घवृत्त सम्मिलित करते हुए, आप --no-full विकल्प का उपयोग कर सकते हैं:

journalctl --no-full

. . . Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2 Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth] Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot 

आप इसके विपरीत दिशा में भी जा सकते हैं और journalctl को अपनी सभी जानकारी प्रदर्शित करने के लिए कह सकते हैं, चाहे उसमें अनप्रिंटेबल वर्ण शामिल हों। हम इसे -a फ्लैग के साथ कर सकते हैं:

journalctl -a

journalctl आउटपुट में पेजर को कैसे अक्षम करें

डिफ़ॉल्ट रूप से, journalctl आसान खपत के लिए आउटपुट को पेजर में प्रदर्शित करता है। यदि आप टेक्स्ट हेरफेर टूल के साथ डेटा प्रोसेस करने की योजना बना रहे हैं, हालांकि, आप शायद मानक आउटपुट में आउटपुट करने में सक्षम होना चाहेंगे।

आप इसे --no-pager विकल्प के साथ कर सकते हैं:

journalctl --no-pager

इसे तुरंत प्रोसेसिंग यूटिलिटी में पाइप किया जा सकता है या आपकी आवश्यकताओं के आधार पर डिस्क पर फ़ाइल में रीडायरेक्ट किया जा सकता है।

journalctl में विभिन्न आउटपुट प्रारूप

यदि आप जर्नल प्रविष्टियों को प्रोसेस कर रहे हैं, जैसा कि ऊपर उल्लेख किया गया है, तो यदि डेटा अधिक उपभोग योग्य प्रारूप में है तो आपको इसे पार्स करना आसान होगा। सौभाग्य से, जर्नल को आवश्यकतानुसार विभिन्न प्रारूपों में प्रदर्शित किया जा सकता है। आप इसे एक प्रारूप विशिष्टकर्ता के साथ -o विकल्प का उपयोग करके कर सकते हैं।

उदाहरण के लिए, आप जर्नल प्रविष्टियों को JSON में आउटपुट कर सकते हैं:

journalctl -b -u nginx -o json

{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" } . . . 

यह यूटिलिटी के साथ पार्सिंग के लिए उपयोगी है। आप डेटा संरचना पर बेहतर पकड़ पाने के लिए JSON कंज्यूमर को पास करने से पहले json-pretty प्रारूप का उपयोग कर सकते हैं:

journalctl -b -u nginx -o json-pretty

{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" } . . . 

निम्नलिखित प्रारूप प्रदर्शन के लिए उपयोग किए जा सकते हैं:

• cat: केवल संदेश फ़ील्ड को ही प्रदर्शित करता है।
• export: ट्रांसफर या बैकअप के लिए उपयुक्त बाइनरी प्रारूप।
• json: प्रति पंक्ति एक प्रविष्टि के साथ मानक JSON।
• json-pretty: बेहतर मानव-पठनीयता के लिए फ़ॉर्मेट किया गया JSON।
• json-sse: सर्वर-सेंट इवेंट संगत बनाने के लिए लपेटा गया JSON फ़ॉर्मेट आउटपुट।
• short: डिफ़ॉल्ट syslog शैली आउटपुट।
• short-iso: ISO 8601 वॉलक्लॉक टाइमस्टैम्प दिखाने के लिए संवर्धित डिफ़ॉल्ट प्रारूप।
• short-monotonic: मोनोटोनिक टाइमस्टैम्प के साथ डिफ़ॉल्ट प्रारूप।
• short-precise: माइक्रोसेकंड परिशुद्धता के साथ डिफ़ॉल्ट प्रारूप।
• verbose: प्रविष्टि के लिए उपलब्ध हर जर्नल फ़ील्ड दिखाता है, जिसमें आमतौर पर आंतरिक रूप से छिपे हुए शामिल हैं।

ये विकल्प आपको जर्नल प्रविष्टियों को किसी भी प्रारूप में प्रदर्शित करने की अनुमति देते हैं जो आपकी वर्तमान आवश्यकताओं के लिए सबसे उपयुक्त है।

journalctl के साथ लाइव systemd लॉग मॉनिटर करें

journalctl कमांड इस बात की नकल करता है कि कई प्रशासक सक्रिय या हालिया गतिविधि की निगरानी के लिए tail का उपयोग करते हैं। यह कार्यक्षमता journalctl में अंतर्निहित है, जिससे आप किसी अन्य टूल में पाइप किए बिना इन सुविधाओं तक पहुंच सकते हैं।

journalctl -n के साथ हालिया लॉग प्रविष्टियां दिखाएं

रिकॉर्ड की एक निर्धारित राशि प्रदर्शित करने के लिए, आप -n विकल्प का उपयोग कर सकते हैं, जो बिल्कुल tail -n की तरह काम करता है।

डिफ़ॉल्ट रूप से, यह सबसे हालिया 10 प्रविष्टियों को प्रदर्शित करेगा:

journalctl -n

आप -n के बाद एक संख्या के साथ देखना चाहते हैं प्रविष्टियों की संख्या निर्दिष्ट कर सकते हैं:

journalctl -n 20

journalctl -f के साथ रीयल-टाइम लॉग का पालन करें

लॉग का सक्रिय रूप से पालन करने के लिए जैसे ही वे लिखे जा रहे हैं, आप -f फ्लैग का उपयोग कर सकते हैं। फिर से, यह वैसे ही काम करता है जैसा आप उम्मीद कर सकते हैं अगर आपके पास tail -f का उपयोग करने का अनुभव है:

journalctl -f

इस कमांड से बाहर निकलने के लिए, CTRL+C टाइप करें।

systemd जर्नल लॉग को कैसे प्रबंधित और साफ़ करें

आप अब तक देखे गए सभी डेटा को संग्रहीत करने की लागत के बारे में सोच रहे होंगे। इसके अलावा, आप कुछ पुराने लॉग को साफ़ करने और जगह खाली करने में रुचि ले सकते हैं।

journalctl --disk-usage के साथ systemd लॉग के डिस्क उपयोग की जांच करें

आप --disk-usage फ्लैग का उपयोग करके जर्नल द्वारा वर्तमान में डिस्क पर घेरे गए स्थान की मात्रा का पता लगा सकते हैं:

journalctl --disk-usage

Archived and active journals take up 8.0M in the file system.

journalctl --vacuum-size और --vacuum-time के साथ पुराने लॉग हटाएं

यदि आप अपने जर्नल को छोटा करना चाहते हैं, तो आप इसे दो अलग-अलग तरीकों से कर सकते हैं (systemd वर्जन 218 और बाद के साथ उपलब्ध)।

यदि आप --vacuum-size विकल्प का उपयोग करते हैं, तो आप एक आकार दर्शाकर अपने जर्नल को छोटा कर सकते हैं। यह पुरानी प्रविष्टियों को तब तक हटा देगा जब तक कि डिस्क पर जर्नल द्वारा लिया गया कुल स्थान अनुरोधित आकार पर न हो:

sudo journalctl --vacuum-size=1G

जर्नल को छोटा करने का एक और तरीका --vacuum-time विकल्प के साथ कटऑफ समय प्रदान करना है। उस समय से परे की किसी भी प्रविष्टि को हटा दिया जाता है। यह आपको एक विशिष्ट समय के बाद बनाई गई प्रविष्टियों को रखने की अनुमति देता है।

उदाहरण के लिए, पिछले वर्ष से प्रविष्टियों को रखने के लिए, आप टाइप कर सकते हैं:

sudo journalctl --vacuum-time=1years

Journald लॉग के लिए डिस्क स्पेस सीमा कॉन्फ़िगर करें

आप अपने सर्वर को कॉन्फ़िगर कर सकते हैं कि जर्नल कितना स्थान ले सकता है, इस पर सीमाएं लगाएं। यह /etc/systemd/journald.conf फ़ाइल को संपादित करके किया जा सकता है।

निम्नलिखित आइटम जर्नल वृद्धि को सीमित करने के लिए उपयोग किए जा सकते हैं:

• SystemMaxUse=: लगातार स्टोरेज में जर्नल द्वारा उपयोग किए जा सकने वाले अधिकतम डिस्क स्थान को निर्दिष्ट करता है।
• SystemKeepFree=: लगातार स्टोरेज में जर्नल प्रविष्टियों को जोड़ते समय जर्नल द्वारा मुक्त छोड़े जाने वाले स्थान की मात्रा निर्दिष्ट करता है।
• SystemMaxFileSize=: नियंत्रित करता है कि व्यक्तिगत जर्नल फ़ाइलें रोटेट होने से पहले लगातार स्टोरेज में कितनी बड़ी हो सकती हैं।
• RuntimeMaxUse=: अस्थिर स्टोरेज ( /run फाइल सिस्टम के भीतर) में उपयोग किए जा सकने वाले अधिकतम डिस्क स्थान को निर्दिष्ट करता है।
• RuntimeKeepFree=: अस्थिर स्टोरेज ( /run फाइल सिस्टम के भीतर) में डेटा लिखते समय अन्य उपयोगों के लिए अलग रखे जाने वाले स्थान की मात्रा निर्दिष्ट करता है।
• RuntimeMaxFileSize=: अस्थिर स्टोरेज ( /run फाइल सिस्टम के भीतर) में एक व्यक्तिगत जर्नल फ़ाइल द्वारा लिए जा सकने वाले स्थान की मात्रा को निर्दिष्ट करता है, रोटेट होने से पहले।

इन मूल्यों को सेट करके, आप नियंत्रित कर सकते हैं कि journald आपके सर्वर पर स्थान का उपभोग और संरक्षण कैसे करता है। ध्यान रखें कि SystemMaxFileSize और RuntimeMaxFileSize आर्काइव्ड फ़ाइलों को बताए गए सीमा तक पहुंचने के लिए लक्षित करेंगे। वैक्यूम ऑपरेशन के बाद फ़ाइल काउंट की व्याख्या करते समय यह याद रखना महत्वपूर्ण है।

सामान्य journalctl और systemd जर्नल समस्याओं का निवारण

1. journalctl लॉग क्यों नहीं दिखा रहा है?

कुछ मामलों में, आप लॉग आउटपुट देखने की उम्मीद में journalctl कमांड चला सकते हैं, केवल एक खाली स्क्रीन या कोई सार्थक परिणाम नहीं मिलने पर। यह स्थिति भ्रमित करने वाली हो सकती है, खासकर यदि आप किसी समस्या का निवारण कर रहे हैं या हालिया सिस्टम गतिविधि की तलाश कर रहे हैं। सौभाग्य से, कई सामान्य व्याख्याएं हैं जो यह समझाने में मदद करती हैं कि journalctl लॉग क्यों नहीं दिखा रहा है।

जर्नल डेटाबेस खाली या गायब है

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

ls /var/log/journal

यदि यह निर्देशिका मौजूद नहीं है, या यदि यह खाली है, तो इसका मतलब है कि आपके लॉग बूट के बीच सहेजे नहीं जा रहे हैं। आप निर्देशिका बनाकर और journald सेवा को पुनरारंभ करके इसे हल कर सकते हैं:

sudo mkdir -p /var/log/journal sudo systemd-tmpfiles --create --prefix /var/log/journal sudo systemctl restart systemd-journald

एक बार लगातार लॉगिंग सक्षम हो जाने पर, भविष्य के लॉग डिस्क पर लिखे जाएंगे और रीबूट में बने रहेंगे।

लॉगिंग सेवा चल नहीं रही हो सकती है

एक और संभावना यह है कि लॉगिंग सेवा को ही कोई त्रुटि आई हो या वह शुरू न हो पाई हो। systemd-journald सेवा लॉग डेटा एकत्र करने और प्रबंधित करने के लिए जिम्मेदार है। यदि यह नहीं चल रही है, तो जर्नल स्वाभाविक रूप से खाली होगा। आप इसकी स्थिति के साथ जांच सकते हैं:

systemctl status systemd-journald

यदि सेवा निष्क्रिय है या विफल हो गई है, तो इसे पुनरारंभ करने से लॉग संग्रह कार्यक्षमता बहाल होनी चाहिए।

फ़िल्टर बहुत संकीर्ण हो सकते हैं

कभी-कभी, समस्या लॉग के साथ नहीं होती, बल्कि इस बात से होती है कि आप उन्हें कैसे एक्सेस करने का प्रयास कर रहे हैं। संकीर्ण फ़िल्टर का उपयोग करना, जैसे कि एक गैर-मौजूद यूनिट नाम या अत्यधिक विशिष्ट समय सीमा, कोई परिणाम नहीं दे सकती है भले ही प्रासंगिक डेटा मौजूद हो। journalctl को बिना किसी फ्लैग के चलाकर यह पुष्टि करना अक्सर सहायक होता है कि लॉग एकत्र किए जा रहे हैं, और फिर आवश्यकतानुसार उत्तरोत्तर फ़िल्टर लागू करें।

लॉग रोटेट या डिलीट हो गए होंगे

अंत में, ध्यान रखें कि जर्नल लॉग आकार और समय-आधारित प्रतिधारण नीतियों के अधीन हैं। यदि पुराने लॉग systemd-journald द्वारा वैक्यूम किए गए हैं, तो वे अब एक्सेस योग्य नहीं होंगे। आप इस साथ जांच सकते हैं कि जर्नल वर्तमान में कितना स्थान उपयोग कर रहा है:

journalctl --disk-usage

यदि आपने अपने सिस्टम को जर्नल आकार को आक्रामक रूप से सीमित करने के लिए कॉन्फ़िगर किया है, या यदि आपने हाल ही में मैन्युअली वैक्यूम कमांड चलाया है, तो लॉग डेटाबेस से हटा दिए गए हो सकते हैं।

2. journalctl का उपयोग करते समय अनुमति अस्वीकृत

यदि आप एक नियमित उपयोगकर्ता के रूप में journalctl चलाने का प्रयास करते हैं और "अनुमति अस्वीकृत" संदेश प्राप्त करते हैं, तो आप अकेले नहीं हैं। डिफ़ॉल्ट रूप से, सिस्टम लॉग तक पहुंच root उपयोगकर्ता और systemd-journal समूह के सदस्यों तक सीमित है। यह प्रतिबंध संभावित रूप से संवेदनशील लॉग डेटा की रक्षा के लिए डिज़ाइन किया गया है, जिसमें उपयोगकर्ता गतिविधि, सिस्टम प्रक्रियाओं, और सेवा विफलताओं के बारे में जानकारी शामिल हो सकती है।

journalctl को उन्नत विशेषाधिकारों के साथ चलाना

सबसे सरल और सबसे आम समाधान कमांड को sudo के साथ चलाना है। यह कमांड की अवधि के लिए आपके विशेषाधिकारों को बढ़ाता है और आपको सभी सिस्टम लॉग देखने की अनुमति देता है:

sudo journalctl

यदि आप स्क्रिप्टिंग कर रहे हैं या अक्सर लॉग इंस्पेक्ट कर रहे हैं, तो हर बार sudo टाइप करना थकाऊ हो सकता है। ऐसे मामलों में, अपने उपयोगकर्ता को जर्नल तक स्थायी पहुंच देना अधिक व्यावहारिक हो सकता है।

समूह सदस्यता के माध्यम से अपने उपयोगकर्ता को पहुंच प्रदान करना

sudo की आवश्यकता से बचने के लिए, आप अपने उपयोगकर्ता को systemd-journal समूह में जोड़ सकते हैं। यह समूह गैर-रूट उपयोगकर्ताओं को जर्नल लॉग पढ़ने की अनुमति देने के लिए विशेष रूप से डिज़ाइन किया गया है। आप निम्न कमांड के साथ अपने उपयोगकर्ता को समूह में जोड़ सकते हैं:

sudo usermod -aG systemd-journal yourusername

yourusername को अपने वास्तविक लॉगिन नाम से बदलना सुनिश्चित करें। उपयोगकर्ता को समूह में जोड़ने के बाद, आपको परिवर्तन प्रभावी होने के लिए लॉग आउट और वापस लॉग इन करना होगा। एक बार यह हो जाने पर, आपको उन्नत विशेषाधिकारों की आवश्यकता के बिना journalctl चलाने में सक्षम होना चाहिए।

जर्नल अनुमतियों की पुष्टि करना

यदि समूह सदस्यता समस्या का समाधान नहीं करती है, तो फ़ाइल या निर्देशिका अनुमतियों के साथ कोई समस्या हो सकती है। /var/log/journal निर्देशिका root के स्वामित्व में होनी चाहिए और systemd-journal के तहत समूहीकृत होनी चाहिए। समूह पढ़ने की अनुमतियां सही ढंग से सेट होनी चाहिए, या पहुंच से अभी भी इनकार किया जाएगा भले ही आप सही समूह में हों। आप इसे इसके साथ ठीक कर सकते हैं:

sudo chown root:systemd-journal /var/log/journal sudo chmod 2755 /var/log/journal

इन अनुमतियों और उचित समूह सदस्यता के साथ, गैर-रूट उपयोगकर्ता सुरक्षित रूप से लॉग एक्सेस कर सकते हैं।

3. रीबूट के बाद लॉग बने नहीं रहते

यदि आप देखते हैं कि हर बार आपके सर्वर के रीबूट होने पर लॉग गायब हो जाते हैं, तो आपका सिस्टम लॉग को केवल अस्थिर मेमोरी में संग्रहीत करने के लिए कॉन्फ़िगर किया गया है, जो मशीन के पावर ऑफ होने पर खो जाता है। यह कई लिनक्स वितरणों और कंटेनर वातावरण में एक सामान्य डिफ़ॉल्ट है, विशेष रूप से वे जो कम डिस्क उपयोग के लिए अनुकूलित हैं।

लगातार लॉगिंग सक्षम करना

रीबूट में लॉग बनाए रखने के लिए, आपको journald को लगातार स्टोरेज का उपयोग करने के लिए कॉन्फ़िगर करने की आवश्यकता है। इसके लिए उपयुक्त निर्देशिका बनाने की आवश्यकता होती है जहां जर्नल डिस्क पर लॉग लिख सके। पथ /var/log/journal इस उद्देश्य के लिए उपयोग किया जाता है। यदि यह मौजूद नहीं है, तो इसे बनाएं और लॉगिंग डेमॉन को पुनरारंभ करें:

sudo mkdir -p /var/log/journal sudo systemd-tmpfiles --create --prefix /var/log/journal sudo systemctl restart systemd-journald

इसके पूरा होने के बाद, सभी भविष्य के लॉग डिस्क पर लिखे जाएंगे और सिस्टम रीबूट से बचे रहेंगे।

journald कॉन्फ़िगरेशन की पुष्टि करना

यदि निर्देशिका मौजूद है लेकिन लॉग अभी भी बने नहीं रहते, तो journald कॉन्फ़िगरेशन फ़ाइल का निरीक्षण करना उचित है:

sudo nano /etc/systemd/journald.conf

इस फ़ाइल में, [Journal] अनुभाग के तहत Storage= निर्देश देखें। यदि यह volatile पर सेट है, तो इसे persistent पर बदलें:

[Journal] Storage=persistent

फ़ाइल सहेजें और परिवर्तन लागू करने के लिए सेवा को पुनरारंभ करें। यह सुनिश्चित करता है कि सिस्टम अब RAM के बजाय डिस्क पर लॉग लिखेगा।

4. विफल systemd सेवा को डीबग करना

जब एक systemd-प्रबंधित सेवा शुरू करने में विफल होती है या अप्रत्याशित रूप से क्रैश होती है, तो journalctl मूल कारण की पहचान करने के लिए एक आवश्यक उपकरण बन जाता है। कई लॉग फ़ाइलों के माध्यम से खोज करने के बजाय, जर्नल एक सेवा से संबंधित सभी संदेशों को एक स्थान पर एकत्र करता है, मेटाडेटा, टाइमस्टैम्प, और प्राथमिकता स्तरों के साथ पूर्ण।

सेवा स्थिति की समीक्षा करना

समस्या निवारण का पहला कदम सेवा स्थिति की जांच करना है। systemctl status कमांड सेवा की वर्तमान स्थिति का एक स्नैपशॉट प्रदान करता है, जिसमें सबसे हालिया लॉग प्रविष्टियां शामिल हैं। उदाहरण के लिए:

systemctl status nginx.service

यह आउटपुट अक्सर तत्काल मुद्दों को प्रकट करता है जैसे गलत कॉन्फ़िगर पथ, अनुमति समस्याएं, या निकास कोड। यदि मौजूद है तो निकास कोड और सिग्नल जानकारी यह निर्धारित करने के लिए विशेष रूप से सहायक हो सकती है कि सेवा अपने आप विफल हुई या सिस्टम द्वारा मारी गई।

पूर्ण लॉग इतिहास देखना

विफल सेवा से संबंधित सभी लॉग देखने के लिए, journalctl का उपयोग -u फ्लैग के साथ करें:

journalctl -u nginx.service

यह सेवा द्वारा उत्पन्न संदेशों का कालानुक्रमिक दृश्य प्रदान करता है। यदि आप अंतिम सिस्टम बूट के दौरान हुई विफलता का निदान करने का प्रयास कर रहे हैं, तो आउटपुट को केवल उस सत्र तक सीमित करना सहायक होता है:

journalctl -u nginx.service -b

विफलता संदर्भ की जांच करना

आप विफलता से कुछ मिनट पहले और बाद की लॉग प्रविष्टियों को पढ़कर अक्सर समस्या के核心 तक पहुंच सकते हैं। अपना फोकस संकीर्ण करने के लिए समय-आधारित फ़िल्टर का उपयोग करें:

journalctl -u nginx.service --since "10 minutes ago"

यह पहचानने में मदद कर सकता है कि समस्या अलग थी या बड़े सिस्टम मुद्दे का हिस्सा थी।

गहन विश्लेषण के लिए, आप वर्बोज़ आउटपुट सक्षम कर सकते हैं या उपयोग करके विस्तारित त्रुटि संदेश देख सकते हैं:

journalctl -xe

यह कमांड प्राथमिकता संदेशों और हालिया विफलताओं को हाइलाइट करता है, जो उपयोगी हो सकता है जब कोई सेवा मानक आउटपुट में स्पष्ट सुराग नहीं छोड़ती।

5. SSH लॉगिन प्रयासों की निगरानी करना

SSH अधिकांश लिनक्स सर्वर के लिए एक प्राथमिक एक्सेस विधि है, जो इसे ब्रूट-फोर्स हमलों, अनधिकृत पहुंच प्रयासों, या सामान्य ऑडिटिंग के लिए एक सामान्य वेक्टर भी बनाता है। सौभाग्य से, journalctl आपको सभी SSH-संबंधित गतिविधि को आसानी से मॉनिटर करने की अनुमति देता है।

SSH लॉग देखना

Systemd आपके वितरण के आधार पर sshd या ssh यूनिट के तहत SSH गतिविधि को ट्रैक करता है। SSH से संबंधित सभी प्रविष्टियों को देखने के लिए:

journalctl -u ssh.service

या, कुछ सिस्टम पर:

journalctl -u sshd.service

इन लॉग में लॉगिन प्रयास, प्रमाणीकरण विफलताएं, सत्र समाप्ति, और कुंजी वार्ता संदेश शामिल हैं। यह सत्यापित करते समय एक उत्कृष्ट पहला कदम है कि सर्वर तक किसने और कब पहुंचा।

रीयल-टाइम में SSH गतिविधि का पालन करना

रीयल-टाइम निगरानी के लिए, आप journalctl को फॉलो मोड में उपयोग कर सकते हैं। यह विशेष रूप से उपयोगी है यदि आपको घुसपैठ का संदेह है या सक्रिय लॉगिन प्रयासों पर नजर रखना चाहते हैं:

journalctl -f -u ssh.service

प्रत्येक नया लॉगिन इवेंट लाइव प्रिंट किया जाएगा जैसे ही यह होता है, जिससे असफल लॉगिन या तेज़ कनेक्शन प्रयासों को पहचानना आसान हो जाता है जो दुर्भावनापूर्ण व्यवहार का संकेत दे सकते हैं।

लॉगिन इवेंट द्वारा फ़िल्टर करना

यदि आप विशिष्ट लॉगिन संदेशों की तलाश कर रहे हैं, जैसे असफल पासवर्ड या स्वीकृत कनेक्शन, तो आप कीवर्ड मिलान का उपयोग करके जर्नल आउटपुट फ़िल्टर कर सकते हैं:

journalctl -u ssh.service | grep "Failed password" journalctl -u ssh.service | grep "Accepted password"

ये संदेश इंगित करते हैं कि लॉगिन सफल रहा या नहीं और किस उपयोगकर्ता ने प्रयास किया। आप इन्हें समय फ़िल्टर के साथ जोड़कर खोज को एक विशिष्ट विंडो तक सीमित कर सकते हैं:

journalctl -u ssh.service --since "1 hour ago"

यह सुरक्षा ऑडिट या फोरेंसिक जांच के दौरान अत्यधिक सहायक हो सकता है।

अक्सर पूछे जाने वाले प्रश्न (FAQ)

1. journalctl को रूट एक्सेस की आवश्यकता क्यों है?

डिफ़ॉल्ट रूप से, journalctl को रूट एक्सेस की आवश्यकता होती है क्योंकि यह सिस्टम सेवाओं, कर्नेल संदेशों, उपयोगकर्ता सत्रों, और पृष्ठभूमि डेमॉन से एकत्र की गई संवेदनशील जानकारी को उजागर कर सकता है। इन लॉग में उपयोगकर्ता नाम, पर्यावरण चर, त्रुटि ट्रेस, प्रमाणीकरण प्रयास, और अन्य विवरण शामिल हो सकते हैं जो अनधिकृत उपयोगकर्ताओं द्वारा एक्सेस किए जाने पर सुरक्षा जोखिम पैदा कर सकते हैं।

इस डेटा की सुरक्षा के लिए, systemd सिस्टम जर्नल तक पहुंच को प्रतिबंधित करता है। हालांकि, आपको हमेशा sudo का उपयोग करने की आवश्यकता नहीं है। गैर-रूट उपयोगकर्ता लॉग पढ़ सकते हैं यदि वे systemd-journal समूह का हिस्सा हैं। आप अपने उपयोगकर्ता को इस समूह में इसके साथ जोड़ सकते हैं:

sudo usermod -aG systemd-journal yourusername

लॉग आउट और वापस लॉग इन करने के बाद, आप उन्नत विशेषाधिकारों के बिना लॉग एक्सेस करने में सक्षम होना चाहिए, जब तक कि जर्नल निर्देशिकाओं पर फ़ाइल अनुमतियां सही ढंग से कॉन्फ़िगर की गई हों।

2. लॉग को रीबूट में लगातार कैसे बनाएं?

रीबूट के बाद लॉग संरक्षित करने के लिए, आपको systemd-journald को अस्थिर मेमोरी के बजाय लगातार स्टोरेज का उपयोग करने के लिए कॉन्फ़िगर करने की आवश्यकता है। डिफ़ॉल्ट रूप से, कुछ वितरण /run/log/journal में लॉग संग्रहीत करते हैं, एक अस्थायी निर्देशिका जो शटडाउन पर साफ़ हो जाती है। लगातार लॉगिंग सक्षम करने के लिए:

1. लगातार जर्नल निर्देशिका बनाएं:

   sudo mkdir -p /var/log/journal

2. आवश्यकता होने पर अनुमतियां सेट करें:

   sudo systemd-tmpfiles --create --prefix /var/log/journal

3. जर्नल डेमॉन को पुनरारंभ करें:

   sudo systemctl restart systemd-journald

4. वैकल्पिक: कॉन्फ़िगरेशन सत्यापित या संपादित करें:

   /etc/systemd/journald.conf खोलें और सुनिश्चित करें कि निम्न लाइन सेट है:

   Storage=persistent

यह कॉन्फ़िगरेशन सुनिश्चित करता है कि आपका सिस्टम रीबूट में लॉग डेटा को बरकरार रखता है, जिससे ऐतिहासिक मुद्दों का ऑडिट और डीबग करना आसान हो जाता है।

3. क्या मैं journalctl लॉग साफ़ कर सकता हूँ?

हां, journalctl आपको systemd-journald द्वारा प्रदान किए गए --vacuum-* विकल्पों का उपयोग करके लॉग साफ़ करने की अनुमति देता है। ये कमांड पुराने या अतिरिक्त लॉग डेटा को हटाकर डिस्क उपयोग को कम करने में मदद करते हैं।

जर्नल लॉग को साफ़ या छोटा करने के सामान्य तरीके यहां दिए गए हैं:

• एक विशिष्ट समय से पुराने लॉग हटाएं:

  sudo journalctl --vacuum-time=2weeks

• सभी लॉग के लिए कुल डिस्क उपयोग सीमित करें:

  sudo journalctl --vacuum-size=500M

• रखी गई जर्नल फ़ाइलों की संख्या सीमित करें:

  sudo journalctl --vacuum-files=10

ये कमांड वर्तमान या हालिया लॉग को नहीं मिटाते जब तक कि वे परिभाषित सीमा से अधिक न हों। सभी लॉग को पूरी तरह से हटाने के लिए, आप /var/log/journal से जर्नल फ़ाइलों को मैन्युअली हटा सकते हैं, लेकिन यह शायद ही कभी आवश्यक है और आमतौर पर उत्पादन सिस्टम के लिए अनुशंसित नहीं है।

4. systemd लॉग कैसे एक्सेस करें?

आप journalctl कमांड का उपयोग करके systemd लॉग एक्सेस कर सकते हैं, जो सीधे systemd जर्नल के साथ इंटरफेस करता है। systemd द्वारा प्रबंधित सेवाओं से संबंधित सभी लॉग, जैसे बूट संदेश, यूनिट विफलताएं, और रनटाइम त्रुटियां, जर्नल में संग्रहीत हैं।

सामान्य पहुंच के लिए:

journalctl

किसी विशिष्ट systemd सेवा के लॉग देखने के लिए, जैसे nginx, उपयोग करें:

journalctl -u nginx.service

आप बूट सत्र, प्राथमिकता स्तर, समय सीमा, या कई सेवाओं को संयोजित करके गहरी अंतर्दृष्टि प्राप्त करने के लिए भी फ़िल्टर कर सकते हैं। पारंपरिक लॉग फ़ाइलों के विपरीत, journalctl कई स्रोतों से लॉग संदेशों का एक एकीकृत, अनुक्रमित दृश्य प्रदान करता है।

5. systemd लॉग देखने के लिए किस कमांड का उपयोग किया जाता है?

systemd लॉग देखने के लिए प्राथमिक कमांड है:

journalctl

यह टूल systemd के साथ शामिल है और systemd-journald सेवा द्वारा एकत्र किए गए सभी लॉग तक पहुंच प्रदान करता है, जिसमें कर्नेल संदेश, प्रारंभिक बूट लॉग, सिस्टम सेवाएं, और उपयोगकर्ता सत्र शामिल हैं।

आप विभिन्न विकल्पों के साथ कमांड को अनुकूलित कर सकते हैं:

• किसी विशिष्ट सेवा के लॉग देखें:

  journalctl -u ssh.service

• प्राथमिकता द्वारा लॉग फ़िल्टर करें:

  journalctl -p err

• लॉग को रीयल-टाइम में प्रदर्शित करें:

  journalctl -f

यह journalctl को systemd-संबंधित लॉग देखने के लिए सबसे बहुमुखी और व्यापक यूटिलिटी बनाता है।

6. journalctl के माध्यम से कर्नेल लॉग कैसे देखें?

कर्नेल संदेश, जैसे कि पारंपरिक रूप से dmesg का उपयोग करके देखे जाते हैं, systemd जर्नल के माध्यम से भी उपलब्ध हैं। journalctl का उपयोग करके केवल कर्नेल संदेश प्रदर्शित करने के लिए, -k फ्लैग का उपयोग करें:

journalctl -k

यह कमांड आउटपुट को केवल कर्नेल से उत्पन्न संदेशों को शामिल करने के लिए फ़िल्टर करता है। यह हार्डवेयर मुद्दों, कर्नेल मॉड्यूल समस्याओं, या बूट-टाइम त्रुटियों का निदान करने के लिए विशेष रूप से उपयोगी है। आप वर्तमान या पिछले बूट से संदेश दिखाने के लिए -b विकल्प का भी उपयोग कर सकते हैं:

journalctl -k -b -1

यह अन्य सेवाओं के लॉग के साथ एकीकृत, बेहतर प्रासंगिक समझ के लिए कर्नेल लॉग तक सुसंगत पहुंच प्रदान करता है।

7. dmesg और journalctl में क्या अंतर है?

जबकि दोनों dmesg और journalctl कर्नेल लॉग दिखा सकते हैं, वे विभिन्न उद्देश्यों की पूर्ति करते हैं और विभिन्न तंत्रों के तहत काम करते हैं।

संक्षेप में, dmesg रीयल-टाइम में केवल निम्न-स्तरीय कर्नेल लॉग तक सीमित है, जबकि journalctl एक अधिक पूर्ण, संरचित, और लगातार लॉगिंग इंटरफ़ेस प्रदान करता है जो पूरे सिस्टम को शामिल करता है।

निष्कर्ष

जैसा कि आप देख सकते हैं, systemd जर्नल आपके सिस्टम और एप्लिकेशन डेटा को एकत्र और प्रबंधित करने के लिए अविश्वसनीय रूप से उपयोगी है। अधिकांश लचीलापन स्वचालित रूप से रिकॉर्ड किए गए व्यापक मेटाडेटा और लॉग की केंद्रीकृत प्रकृति से आता है।

इस गाइड में, हमने बुनियादी लॉग देखने, समय-आधारित और फ़ील्ड-आधारित फ़िल्टरिंग, कर्नेल और सेवा लॉग की निगरानी, आउटपुट फ़ॉर्मेटिंग, और रीयल-टाइम लॉग ट्रैकिंग को कवर किया। हमने जर्नल रखरखाव, स्टोरेज सीमा, और लापता लॉग या अनुमति त्रुटियों जैसे सामान्य मुद्दों के निवारण पर भी चर्चा की।

journalctl कमांड जर्नल की उन्नत सुविधाओं का लाभ उठाना और विभिन्न एप्लिकेशन घटकों का व्यापक विश्लेषण और संबंधपरक डीबगिंग करना आसान बनाता है। journalctl में महारत हासिल करके, आप अपने पूरे सिस्टम में डीबगिंग, निगरानी, और ऑडिटिंग के लिए एक बहुमुखी, एकीकृत लॉगिंग इंटरफ़ेस प्राप्त करते हैं।

लिनक्स सिस्टम पर लॉगिंग और समस्या निवारण में अधिक विस्तृत अंतर्दृष्टि के लिए, निम्नलिखित संबंधित ट्यूटोरियल देखें:

• सामान्य Apache त्रुटियों का निवारण कैसे करें
• Debian 10 पर Journald के साथ लॉग को केंद्रीकृत कैसे करें
• Ubuntu 20.04 पर Journald के साथ लॉग को केंद्रीकृत कैसे करें

यह कार्य क्रिएटिव कॉमन्स एट्रिब्यूशन-नॉनकमर्शियल-शेयरअलाइक 4.0 इंटरनेशनल लाइसेंस के तहत लाइसेंस प्राप्त है।