journalctl चीट शीट: Linux logs को tail, filter और लाइव follow करें

journalctl एक लाइन में: journalctl -u <service> -f किसी सर्विस का log लाइव दिखाता है, journalctl -u <service> -n 100 आख़िरी 100 लाइनें देता है, और journalctl --since "1 hour ago" हाल की सारी entries दिखाता है। “यह सर्विस क्यों डाउन है” वाले 90% मामले इतने में ही कवर हो जाते हैं। इस चीट शीट का बाक़ी हिस्सा वही copy-paste patterns हैं जो आपको रात 2 बजे man page दोबारा पढ़ने से बचाते हैं — unit, समय, priority और boot से फ़िल्टरिंग, साथ में वे cleanup कमांड जो journal को आपकी disk खाने से रोकती हैं। नीचे की हर कमांड किसी भी systemd distro (Ubuntu, Debian, Fedora, Arch) पर जस की तस चलती है।

journalctl क्या है, और सीधे /var/log/syslog क्यों नहीं पढ़ें?

पुराने ज़माने की Linux logging /var/log के नीचे plain text फ़ाइलें लिखती थी — syslog, auth.log, messages। systemd ने इन सबकी जगह the journal ले लिया: systemd-journald से चलने वाला binary, indexed log। सीधा grep इसे नहीं पढ़ सकता; journalctl ही एकमात्र दरवाज़ा है, और बदले में आपको सर्विस, समय, boot और severity से फ़िल्टर करने की ताक़त मिलती है — regex के खेल दिखाए बिना।

मॉडल आसान है: journal सब कुछ स्टोर करता है, और journalctl उस पर सवाल पूछने का औज़ार है। सर्विस को अपनी log फ़ाइल की ज़रूरत नहीं होती — systemd के नीचे चलते हुए stdout/stderr पर लिखा गया हर बात अपने आप journal में पहुँच जाती है। इसीलिए journalctl -u nginx तब भी काम करता है जब आपको नहीं पता कि nginx ने अपना error log कहाँ कॉन्फ़िगर किया है।

एक बात का ध्यान रखें: कुछ minimal installs पर journal volatile होता है (/run में स्टोर, reboot पर मिट जाता है), क्योंकि /var/log/journal मौजूद नहीं होता। इलाज एक बार का है:

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

किसी log की आख़िरी 100 लाइनें कैसे देखें?

-n आउटपुट को सबसे नई N लाइनों तक सीमित करता है (डिफ़ॉल्ट 10):

journalctl -n 100                      # सब कुछ की आख़िरी 100 लाइनें
journalctl -u nginx -n 100             # एक unit की आख़िरी 100 लाइनें
journalctl -n 100 --no-pager           # छापो और निकलो — pipe के लिए बिल्कुल सही

--no-pager दिखने से कहीं ज़्यादा अहम है: इसके बिना journalctl less खोल लेता है और आपकी script, pipe या ssh वाली one-liner कीस्प्रेस का इंतज़ार करती अटक जाती है। जो कमांड आगे pipe होती है, उसमें यह लगाना चाहिए।

tail -f की तरह logs लाइव कैसे follow करें?

-f flag journalctl का tail -f है — नई entries जैसे ही बनती हैं, बहती चली आती हैं:

journalctl -f                    # सब कुछ, लाइव
journalctl -u sshd -f            # सिर्फ़ SSH daemon, लाइव
journalctl -u ollama -f -n 50    # लाइव, पर आख़िरी 50 लाइनों से शुरू

सर्विस रीस्टार्ट करते समय दूसरे टर्मिनल में यही कमांड चलाएँ: एक पैनल में systemctl restart nginx, दूसरे में journalctl -u nginx -f — और क्रैश की वजह आमतौर पर कुछ सेकंड में ख़ुद सामने आ जाती है। मेरे homelab पर मैं यही लूप चलाता हूँ, जब भी कोई container या सर्विस शरारत करने लगती है।

किसी ख़ास सर्विस के logs कैसे देखें?

-u systemd unit से फ़िल्टर करता है:

journalctl -u nginx                    # एक unit, पूरा इतिहास
journalctl -u nginx -u redis           # कई units एक साथ
journalctl _SYSTEMD_UNIT=nginx.service # exact-match वाला विकल्प

Units सहायक units बना सकती हैं और दिलचस्प आउटपुट अक्सर उन्हीं में रह जाता है — कोई फेल होती web app कभी-कभी असली error किसी दूसरी unit के नीचे log करती है। अगर -u <service> कुछ नहीं दिखाता पर सर्विस साफ़ चल रही है, तो पहले असली unit का नाम ढूँढें:

systemctl list-units --type=service | grep -i <guess>

यही -u pattern timers पर भी चलता है (नाम systemctl list-timers दिखाता है) और user services पर भी — systemd --user के नीचे चलने वाली हर चीज़ के लिए --user जोड़ें:

journalctl --user -u pipewire -n 50

समय के हिसाब से logs कैसे फ़िल्टर करें?

--since और --until timestamps लेते हैं, पर relative समय की ढीली अदाएँ भी समझते हैं:

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

समय की एक खिड़की को unit से जोड़ दें, और incident triage एक लाइन में तैयार: “09:00 और API के गिरने के बीच उसने क्या log किया?” अकेली machine के लिए यह किसी भी log aggregator से तेज़ है।

सिर्फ़ errors (या warnings) कैसे देखें?

-p priority से फ़िल्टर करता है, syslog के severity नामों के साथ:

journalctl -p err -b              # सिर्फ़ errors, इस boot से
journalctl -p warning..alert -u nginx   # severity की एक रेंज

Priorities घटते क्रम में: emerg, alert, crit, err, warning, notice, info, debug। जब कोई machine “अजीब हरकतें” करने लगे, तो journalctl -p err -b --since today सबसे तेज़ sanity check है — यह सीधा जवाब देता है कि “असल में कुछ फेल हो रहा है या नहीं”, रूटीन की info लाइनों के शोर के बिना।

पिछले boot के logs कैसे देखें?

स्टार्टअप पर क्रैश होने वाली सर्विसेज़ log लाइनें आपके मौजूदा boot से पहले की छोड़ जाती हैं, और journalctl चुपचाप सिर्फ़ मौजूदा boot दिखाता है। -b boot चुनता है:

journalctl -b                 # सिर्फ़ मौजूदा boot
journalctl -b -1              # पिछला boot
journalctl -b -1 -u sshd      # पिछली बार SSH क्यों गिरा
journalctl --list-boots       # सेव किए गए boots का index

“टूट गया था, रीबूट कर दिया, अब error नहीं दिख रहा” — इस हालत के लिए यह एकमात्र सबसे काम का flag है: error वहीं पड़ा है, एक boot पीछे।

क्विक रेफ़रेंस: याद रखने लायक़ flags

मक़सद	कमांड
एक सर्विस लाइव follow करना	journalctl -u <svc> -f
आख़िरी 100 लाइनें	journalctl -n 100
एक घंटे पहले से	journalctl --since "1 hour ago"
इस boot के errors	journalctl -p err -b
पिछला boot	journalctl -b -1
journal का disk इस्तेमाल	journalctl --disk-usage
machine-readable आउटपुट	journalctl -o json-pretty
सिर्फ़ kernel मैसेज	journalctl -k

journal को disk भरने से कैसे रोकें?

पहले कितना घेर रहा है देखें, फिर लगाम लगाएँ:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # नया 500 MB रखें
sudo journalctl --vacuum-time=30d      # नए 30 दिन रखें

सीमा स्थायी करने के लिए /etc/systemd/journald.conf के [Journal] सेक्शन में SystemMaxUse=500M लिखें, फिर sudo systemctl restart systemd-journald। साइज़ की लगाम और ऊपर वाले boot फ़िल्टर के बीच, journal एक धीमी disk leak बनने की बजाय एक औज़ार बना रहता है।

journalctl vs dmesg vs /var/log — पहले कहाँ देखें?

• journalctl — applications और सर्विसेज़ का व्यवहार। systemd जो भी चलाता है वह यहीं है — indexed और filterable। पहला ठिकाना।
• journalctl -k / dmesg — kernel और हार्डवेयर: OOM kills, USB resets, disk errors। कोई process रहस्यमय ढंग से मर गया हो, तो app को दोष देने से पहले OOM killer यहीं ढूँढें।
• /var/log/<app>/ — सिर्फ़ उन apps के लिए जो अपनी file logging ख़ुद करती हैं (nginx access logs, PostgreSQL)। तब भी startup errors आमतौर पर journal में ही गिरते हैं।

यही workflow लोकल AI services पर भी चलता है — जब ollama serve unit अटक जाए, तो journalctl -u ollama -n 100 model load की नाकामी फ़ौरन दिखा देता है, जैसा कि Ollama vs LM Studio comparison में बताया गया है।

बस, यही पूरी चीट शीट है: unit के लिए -u, follow के लिए -f, लाइनों के लिए -n, समय के लिए --since, severity के लिए -p, boots के लिए -b। छह flags लगभग हर log सवाल का जवाब दे देते हैं जो एक Linux machine आपसे पूछ सकती है।