Linux के लॉग: journalctl, /var/log, rsyslog और logrotate

रात में सेवा गिरी, तो जवाब लगभग हमेशा लॉग में होता है। सवाल सिर्फ़ इतना है कि उन्हें कहाँ ढूँढें। आधुनिक वितरण (Ubuntu, Debian, RHEL, Fedora, Arch) में घटनाएँ journald सेवा इकट्ठा करती है, और उन्हें journalctl कमांड से पढ़ा जाता है। साथ ही कई प्रोग्राम /var/log में सादी टेक्स्ट फ़ाइलें लिखते हैं, और उनके आकार पर logrotate नज़र रखता है। नीचे देखेंगे कि journalctl के साथ Linux लॉग व्यवहार में कैसे पढ़ें, बाक़ी लॉग कहाँ हैं, और रोटेशन में ज़रूरी चीज़ें कैसे न खोएँ।

Linux में लॉग कहाँ रहते हैं

स्रोत तीन हैं, और उन्हें एक नक़्शे की तरह याद रखना उपयोगी है:

• journald — systemd का बाइनरी लॉग। यह सभी सेवाओं का stdout और stderr, कर्नल के संदेश और syslog लेता है। यह /var/log/journal/ (स्थायी) या /run/log/journal/ (रीबूट तक) में रहता है।
• /var/log — टेक्स्ट फ़ाइलें। इन्हें rsyslog लिखता है (जैसे /var/log/syslog, /var/log/auth.log), या ऐप ख़ुद: nginx, PostgreSQL, MySQL।
• कर्नल का रिंग बफ़र — ड्राइवर और हार्डवेयर के संदेश, जिन्हें dmesg या journalctl -k दिखाते हैं।

/var/log की ज़्यादातर फ़ाइलें केवल root या adm समूह को पढ़ने दी जाती हैं, इसलिए पढ़ने की कमांड अक्सर sudo से चलानी पड़ती हैं।

journalctl: बुनियादी कमांड

बिना आर्गुमेंट के journalctl सबसे पुरानी प्रविष्टि से पूरा जर्नल less पेजर में दिखाता है। यह शायद ही कभी चाहिए: आम तौर पर पहले ही दायरा छोटा किया जाता है।

journalctl              # पूरा जर्नल, पुराने से नए की ओर
journalctl -e           # सीधे अंत पर खोलना
journalctl -n 50        # आख़िरी 50 लाइनें
journalctl -r           # उल्टे क्रम में, नए ऊपर
journalctl --no-pager   # less के बिना, स्क्रिप्ट और grep के लिए सुविधाजनक

पेजर के अंदर वही less की कुंजियाँ चलती हैं: / — खोज, G — अंत पर, q — बाहर। लंबी लाइनें स्क्रीन की चौड़ाई पर कटती हैं; बाएँ-दाएँ तीरों से उन्हें खिसकाया जा सकता है।

एक सेवा के लॉग: journalctl -u

सबसे आम काम है देखना कि एक systemd यूनिट ने क्या लिखा। फ़ाइल ढूँढकर grep करने की ज़रूरत नहीं:

$ sudo journalctl -u nginx -n 20
Oct 14 03:12:41 web1 systemd[1]: Starting nginx.service - A high performance web server...
Oct 14 03:12:41 web1 nginx[1834]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Oct 14 03:12:41 web1 systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Oct 14 03:12:41 web1 systemd[1]: nginx.service: Failed with result 'exit-code'.

-u कई बार दिया जा सकता है: journalctl -u nginx -u php8.2-fpm दोनों सेवाएँ समय के क्रम में मिलाकर दिखाएगा, जो तब काम आता है जब गलती दोनों के जोड़ पर हो। उपयोगकर्ता की यूनिट (systemctl --user) के लिए journalctl --user -u नाम।

रियल टाइम लॉग: journalctl -f

sudo journalctl -u nginx -f

यह tail -f जैसा है: आख़िरी 10 प्रविष्टियाँ दिखाकर नई का इंतज़ार करता है। सेवा रीस्टार्ट करते या गलती दोबारा पैदा करते समय इसे अलग टर्मिनल में खुला रखना उपयोगी है। बाहर निकलने के लिए Ctrl+C।

समय और बूट के फ़िल्टर

अगर पता है कि हादसा कब हुआ, तो --since और --until से समय तय करें। ये सटीक तारीख़ और सापेक्ष मान दोनों समझते हैं:

journalctl --since "2026-10-14 02:50" --until "2026-10-14 03:30"
journalctl --since "1 hour ago"
journalctl --since yesterday --until today
journalctl -u nginx --since "10 min ago"

दूसरा उपयोगी दायरा सिस्टम के बूट सत्र हैं। अगर सर्वर अपने-आप रीबूट हुआ, तो कारण पिछले सत्र के अंत में मिलता है:

$ journalctl --list-boots
 -2 8f1c...  Sat 2026-10-12 09:01:12 UTC  Sun 2026-10-13 22:47:03 UTC
 -1 a7d2...  Sun 2026-10-13 22:48:30 UTC  Tue 2026-10-14 03:05:51 UTC
  0 c3e9...  Tue 2026-10-14 03:07:02 UTC  Tue 2026-10-14 09:15:40 UTC

$ journalctl -b -1 -e      # पिछले बूट का अंत
$ journalctl -b            # केवल मौजूदा बूट

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

गंभीरता से फ़िल्टर: journalctl -p

हर प्रविष्टि की syslog प्राथमिकता 0 से 7 तक होती है। -p फ्लैग दिए गए स्तर और उससे ऊपर के सभी संदेश दिखाता है:

journalctl -p err -b              # बूट के बाद की सभी गलतियाँ
journalctl -p warning..err -u ssh # एक सेवा के लिए स्तरों की सीमा

journalctl -p err -b रीबूट या अपडेट के बाद पहली जाँच के लिए अच्छा है: कुछ ही सेकंड में दिखता है कि क्या गड़बड़ हुई।

खोज और दूसरे फ़िल्टर

journald हर प्रविष्टि के साथ संरचित फ़ील्ड रखता है, और उनसे grep के बिना फ़िल्टर किया जा सकता है:

journalctl _PID=1834                 # प्रोसेस नंबर से
journalctl _COMM=sshd                # प्रोग्राम के नाम से
journalctl _UID=1000                 # यूज़र से
journalctl /usr/sbin/sshd            # एक्ज़ीक्यूटेबल के पाथ से
journalctl -k                        # केवल कर्नल संदेश (dmesg जैसा)
journalctl -t CRON                   # syslog पहचानकर्ता से
journalctl -g "Out of memory"        # टेक्स्ट खोज, regular expression

-g (--grep) फ्लैग systemd 237 में आया; पुराने सिस्टम पर सादा पाइप journalctl --no-pager | grep ... इस्तेमाल करें। अलग-अलग फ़ील्ड के फ़िल्टर «और» से जुड़ते हैं, इसलिए journalctl -u nginx -p err --since today केवल आज की nginx गलतियाँ देता है।

आउटपुट के फ़ॉर्मेट

-o फ्लैग फ़ॉर्मेट बदलता है। सबसे उपयोगी:

• -o short-iso — ISO 8601 में समय, ऐप के लॉग से मिलाने के लिए।
• -o verbose — प्रविष्टि के सभी फ़ील्ड, जिनमें _SYSTEMD_UNIT, _PID, _BOOT_ID शामिल हैं।
• -o json या json-pretty — स्क्रिप्ट या jq से प्रोसेस करने के लिए।
• -o cat — केवल संदेश का टेक्स्ट, बिना तारीख़ और होस्ट के।

journalctl -u myapp -o json --since today | jq -r '.MESSAGE'

journald की सेटिंग: भंडारण और आकार

सेटिंग /etc/systemd/journald.conf में है (बदलाव बेहतर होता है /etc/systemd/journald.conf.d/*.conf में डालना)। मुख्य पैरामीटर Storage है:

• persistent — जर्नल /var/log/journal में डिस्क पर लिखा जाता है और रीबूट के बाद भी रहता है।
• volatile — केवल मेमोरी में, /run/log/journal में।
• auto (डिफ़ॉल्ट) — डिस्क पर, अगर /var/log/journal डायरेक्टरी मौजूद हो।

कुछ न्यूनतम इमेज में यह डायरेक्टरी नहीं होती, और रीबूट के बाद इतिहास ग़ायब हो जाता है। स्थायी भंडारण चालू करने के लिए:

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

ताकि जर्नल पूरी डिस्क न घेरे, सीमा तय करें:

# /etc/systemd/journald.conf.d/size.conf
[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month

डिफ़ॉल्ट रूप से SystemMaxUse फ़ाइल सिस्टम के आकार का 10% है, पर 4 GB से ज़्यादा नहीं।

journalctl लॉग कैसे साफ़ करें

$ journalctl --disk-usage
Archived and active journals take up 1.8G in the file system.

sudo journalctl --vacuum-size=300M   # 300 MB से ज़्यादा न रखें
sudo journalctl --vacuum-time=2weeks # दो हफ़्ते से पुरानी प्रविष्टियाँ हटाएँ
sudo journalctl --rotate             # सक्रिय फ़ाइलें बंद करें, ताकि उन्हें भी हटाया जा सके

/var/log/journal से rm से फ़ाइलें न हटाएँ: vacuum वही काम सलीक़े से करता है और चालू फ़ाइल को नहीं छूता।

rsyslog: क्लासिक टेक्स्ट लॉग

rsyslog एक डेमन है, जो syslog संदेश लेता है (journald से आगे भेजे गए भी) और नियमों के अनुसार फ़ाइलों में बाँटता है। सेटिंग /etc/rsyslog.conf और /etc/rsyslog.d/*.conf में है। नियम में एक चयनकर्ता स्रोत.स्तर और एक क्रिया होती है:

# /etc/rsyslog.d/50-default.conf (अंश)
auth,authpriv.*        /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
kern.*                 -/var/log/kern.log

पाथ से पहले का - चिह्न हर पंक्ति के बाद डिस्क पर सिंक किए बिना लिखने का मतलब है: यह तेज़ है, पर दुर्घटना में आख़िरी कुछ लाइनें खो सकती हैं। सेटिंग बदलने के बाद वाक्य-विन्यास जाँचें और सेवा रीस्टार्ट करें:

sudo rsyslogd -N1
sudo systemctl restart rsyslog

rsyslog को journald के साथ रखने का सबसे बड़ा कारण है लॉग को केंद्रीय सर्वर पर भेजना। एक पंक्ति में TCP पर सब कुछ भेजा जा सकता है:

# /etc/rsyslog.d/90-remote.conf
*.* @@logs.example.com:514

एक @ का मतलब UDP है, दो @@ का मतलब TCP। अगर पूरा सर्वर ही गिर जाए, तब भी लॉग की प्रति दूसरी मशीन पर बची रहती है। स्क्रिप्ट से अपना संदेश सिस्टम लॉग में लिखने के लिए logger इस्तेमाल करें:

logger -t backup -p user.err "बैकअप विफल रहा"
journalctl -t backup -n 5

logrotate: लॉग का रोटेशन

टेक्स्ट लॉग तब तक बढ़ते हैं जब तक कोई उन्हें काटे नहीं। यही काम logrotate करता है: रोज़ (cron या logrotate.timer से) वह मौजूदा फ़ाइल का नाम बदलता है, पुरानी फ़ाइलों को संकुचित करता है, और सबसे पुरानी हटाता है। सामान्य सेटिंग /etc/logrotate.conf में है, और प्रोग्राम के नियम /etc/logrotate.d/ में।

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp adm
    postrotate
        systemctl reload myapp > /dev/null 2>&1 || true
    endscript
}

नियम बिना बदलाव जाँचें और ज़बरदस्ती रोटेशन चलाएँ:

sudo logrotate -d /etc/logrotate.d/myapp   # सूखा रन, डीबग आउटपुट के साथ
sudo logrotate -f /etc/logrotate.d/myapp   # अभी रोटेट करें

आम गलती है postrotate या copytruncate भूल जाना। तब ऐप पुराने डिस्क्रिप्टर से नाम बदले गए app.log.1 में लिखता रहता है, और नया app.log खाली रहता है।

टेक्स्ट लॉग पढ़ना

/var/log की फ़ाइलों के लिए मानक यूटिलिटी काफ़ी हैं:

sudo tail -n 100 /var/log/syslog          # आख़िरी लाइनें
sudo tail -F /var/log/nginx/error.log     # देखते रहें, रोटेशन के बावजूद
sudo less +G /var/log/auth.log            # अंत पर खोलें
sudo zgrep "Failed password" /var/log/auth.log.*.gz   # संकुचित आर्काइव में खोज
sudo grep -c " 500 " /var/log/nginx/access.log        # कितने 500 जवाब गए

tail -F का बड़ा F ध्यान देने योग्य है: -f से अलग, यह फ़ाइल को दोबारा खोलता है जब logrotate उसे बदल दे।

रात की सेवा-गड़बड़ी का चरण-दर-चरण विश्लेषण

«सेवा रात में गिरी» वाली स्थिति को इस क्रम में खोलना आसान है:

1. systemctl status myapp — अभी की स्थिति और जर्नल की आख़िरी लाइनें।
2. journalctl -u myapp --since "03:00" --until "03:30" — गिरने के समय सेवा ने क्या लिखा।
3. journalctl -p err -b — उसी समय सिस्टम में और कोई गलती तो नहीं।
4. journalctl -k --since "03:00" -g "Out of memory|Killed process" — कहीं कर्नल के OOM killer ने प्रोसेस तो नहीं मारी।
5. ऐप के अपने लॉग /var/log/myapp/ में, .gz आर्काइव समेत।
6. अगर सर्वर रीबूट हुआ था — journalctl -b -1 -e।

निष्कर्ष

Linux लॉग के रोज़ के काम के लिए कुछ कमांड काफ़ी हैं: सेवा के लिए journalctl -u, धारा के लिए -f, दायरा छोटा करने के लिए --since और -p err, और रीबूट का विश्लेषण करने के लिए -b -1। टेक्स्ट लॉग /var/log में रहते हैं, rsyslog उन्हें बाँटता और भेजता है, और logrotate व journalctl --vacuum-* लॉग को डिस्क भरने नहीं देते। journalctl, रोटेशन और लोड की जाँच हमारे Linux कोर्स में व्यवहार में सिखाई जाती है।