journalctl در لینوکس؛ آموزش بررسی لاگ‌ها و خطاها

journalctl چیست؟ راهنمای کامل و ساده

journalctl ابزار خط فرمان برای خواندن لاگ‌های systemd-journald است. در سرورهای لینوکسی جدید، بسیاری از سرویس‌ها مثل SSH، Nginx، Docker، systemd unitها و Kernel پیام‌هایشان را در Journal ثبت می‌کنند [citation:2][citation:12].

اگر با systemd کار کرده باشید، احتمالاً نام journalctl را شنیده‌اید اما شاید ندانید دقیقاً چه کاری انجام می‌دهد و چرا اینقدر مهم است. در دنیای لینوکس مدرن، journalctl عملاً جایگزین ابزارهای قدیمی مثل tail -f /var/log/messages شده است و راه استانداردی برای دسترسی به همه لاگ‌های سیستم فراهم می‌کند [citation:6].

برخلاف روش‌های سنتی که هر سرویس لاگ خودش را در یک فایل متنی جداگانه می‌نوشت، systemd-journald همه لاگ‌ها را در یک پایگاه داده باینری متمرکز ذخیره می‌کند. این یعنی دیگر لازم نیست بین ده‌ها فایل مختلف در /var/log/ جست‌وجو کنید. journalctl تمام این داده‌ها را یکپارچه کرده و به شما اجازه می‌دهد با فیلترهای قدرتمند، دقیقاً همان چیزی که می‌خواهید را پیدا کنید [citation:2].

نمایش آخرین لاگ‌ها

ساده‌ترین کاربرد journalctl، دیدن آخرین لاگ‌های سیستم است:

journalctl -n 100 journalctl -e

دستور اول ۱۰۰ خط آخر لاگ را نشان می‌دهد. دستور دوم شما را مستقیم به انتهای لاگ می‌برد؛ یعنی جایی که آخرین رویدادها ثبت شده‌اند [citation:2].

اگر بدون هیچ گزینه‌ای journalctl را اجرا کنید، همه لاگ‌ها از ابتدا نمایش داده می‌شوند. این ممکن است خیلی طولانی باشد، پس معمولاً از -n یا -e استفاده می‌کنید [citation:10].

لاگ زنده با Follow

برای دیدن لاگ‌ها به‌صورت زنده و لحظه‌ای، از گزینه -f استفاده کنید:

journalctl -f

این دستور معادل tail -f در فایل‌های متنی است. هر لاگ جدیدی که تولید شود، بلافاصله روی صفحه نمایش داده می‌شود. برای خروج، Ctrl+C را بزنید [citation:2].

ترکیب -f با فیلتر سرویس، یکی از پرکاربردترین دستورات برای عیب‌یابی زنده است:

journalctl -u nginx -f

این دستور فقط لاگ‌های Nginx را به‌صورت زنده نشان می‌دهد. اگر در حال دیباگ کردن یک مشکل هستید و می‌خواهید ببینید دقیقاً چه اتفاقی می‌افتد، این بهترین راه است.

لاگ یک سرویس خاص

یکی از قدرتمندترین قابلیت‌های journalctl، فیلتر بر اساس سرویس است. با گزینه -u می‌توانید فقط لاگ‌های یک unit خاص را ببینید:

journalctl -u ssh journalctl -u nginx journalctl -u docker

این دستور برای عیب‌یابی سرویس‌های خاص فوق‌العاده مفید است. به‌جای اینکه در دریای لاگ‌های سیستم غرق شوید، فقط پیام‌های مربوط به سرویسی که مشکل دارد را می‌بینید [citation:2][citation:12].

اگر مطمئن نیستید نام دقیق سرویس چیست، می‌توانید از این دستور استفاده کنید:

systemctl list-units --type=service

فیلتر زمانی

journalctl می‌تواند لاگ‌ها را بر اساس بازه زمانی فیلتر کند. این برای بررسی یک بازه خاص یا پیدا کردن رویدادهای یک روز خاص بسیار مفید است:

journalctl --since "today" journalctl --since "1 hour ago" journalctl --since "2026-10-13 08:00" --until "2026-10-13 10:00"

می‌توانید از عبارات طبیعی مثل today، yesterday، 1 hour ago یا تاریخ و ساعت دقیق استفاده کنید. گزینه --until هم بازه را از سمت دیگر محدود می‌کند [citation:2][citation:20].

اگر یک Incident رخ داده و می‌خواهید ببینید دقیقاً چه اتفاقی افتاده، این فیلتر زمانی نجات‌دهنده است:

journalctl --since "2026-10-13 14:00" --until "2026-10-13 15:00" -p err

این دستور فقط خطاهای یک ساعت خاص را نشان می‌دهد.

Priority، Boot و Kernel

journalctl می‌تواند لاگ‌ها را بر اساس سطح اهمیت (Priority) فیلتر کند:

journalctl -p err

سطوح Priority از مهم‌ترین به کم‌اهمیت‌ترین عبارتند از: emerg (۰)، alert (۱)، crit (۲)، err (۳)، warning (۴)، notice (۵)، info (۶) و debug (۷). وقتی -p err می‌زنید، همه لاگ‌های سطح err و بالاتر (crit, alert, emerg) را می‌بینید [citation:2][citation:12].

برای دیدن لاگ‌های Boot جاری:

journalctl -b

و برای دیدن Boot قبلی (مثلاً اگر سرور ری‌استارت شده و می‌خواهید ببینید چرا):

journalctl -b -1

عدد منفی یعنی چند Boot قبل‌تر. -b -2 یعنی دو Boot قبل، و به همین ترتیب. برای دیدن لیست همه Bootها:

journalctl --list-boots

برای لاگ‌های Kernel (مشابه dmesg):

journalctl -k

این دستور همه پیام‌های Kernel را نشان می‌دهد؛ از تشخیص سخت‌افزار تا خطاهای درایور [citation:2][citation:6].

جست‌وجو با Grep

یکی از قابلیت‌های کمتر شناخته‌شده اما بسیار کاربردی journalctl، جست‌وجوی متنی است. با --grep می‌توانید در لاگ‌ها جست‌وجو کنید:

journalctl --grep "error" journalctl --grep "failed" -i

گزینه -i برای جست‌وجوی بدون حساسیت به بزرگی و کوچکی حروف است. اگر عبارت جست‌وجو با حرف کوچک شروع شود، به‌صورت پیش‌فرض case-insensitive است [citation:2].

برای جست‌وجوی Regular Expression:

journalctl --grep "error|fail|timeout"

خروجی JSON برای پردازش

journalctl می‌تواند خروجی را به فرمت JSON بدهد. این برای پردازش با ابزارهای دیگر یا ذخیره ساختاریافته بسیار مفید است:

journalctl -o json journalctl -o json-pretty

گزینه json-pretty خروجی را با فرمت خوانا نمایش می‌دهد. این برای اشکال‌زدایی یا تحلیل با jq عالی است [citation:16].

برای ترکیب با ابزارهای دیگر:

journalctl -u nginx -o json | jq '.MESSAGE'

حجم Journal و پاک‌سازی کنترل‌شده

Journal به‌صورت پیش‌فرض می‌تواند فضای قابل توجهی از دیسک را اشغال کند. برای دیدن حجم فعلی:

journalctl --disk-usage

اگر دیدید که Journal فضای زیادی گرفته، می‌توانید به‌صورت کنترل‌شده پاک‌سازی کنید:

sudo journalctl --vacuum-time=14d sudo journalctl --vacuum-size=500M

دستور اول لاگ‌های قدیمی‌تر از ۱۴ روز را حذف می‌کند و دستور دوم حجم کل را به ۵۰۰ مگابایت محدود می‌کند [citation:2][citation:3].

برای پاک‌سازی بر اساس تعداد فایل:

sudo journalctl --vacuum-files=5

ذخیره‌سازی دائمی Journal

به‌صورت پیش‌فرض، journald لاگ‌ها را در /run/log/journal ذخیره می‌کند که یک فایل‌سیستم موقت در RAM است. این یعنی با هر ری‌استارت، همه لاگ‌ها از بین می‌روند. برای ذخیره دائمی، باید پوشه /var/log/journal را بسازید یا تنظیمات را تغییر دهید [citation:5][citation:15].

روش اول: ساخت پوشه

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

روش دوم: تغییر فایل تنظیمات

sudo mkdir -p /etc/systemd/journald.conf.d sudo tee /etc/systemd/journald.conf.d/99-storage.conf > /dev/null <<'EOF' [Journal] Storage=persistent EOF sudo systemctl restart systemd-journald

بعد از فعال‌سازی ذخیره‌سازی دائمی، می‌توانید لاگ‌های Bootهای قبلی را هم ببینید [citation:5][citation:15].

تنظیم Rate Limit برای جلوگیری از پر شدن دیسک

گاهی یک سرویس معیوب آنقدر سریع لاگ تولید می‌کند که دیسک پر می‌شود. journald به‌صورت پیش‌فرض Rate Limit دارد (۱۰۰۰ پیام در ۳۰ ثانیه) اما می‌توانید آن را تنظیم کنید:

sudo nano /etc/systemd/journald.conf

مقادیر زیر را تنظیم کنید:

[Journal] RateLimitInterval=30s RateLimitBurst=10000

یا برای غیرفعال کردن کامل Rate Limit (فقط در موارد خاص):

RateLimitInterval=0 RateLimitBurst=0

بعد از تغییر، سرویس را ری‌استارت کنید:

sudo systemctl restart systemd-journald

اگر در لاگ‌ها پیام Suppressed N messages دیدید، یعنی Rate Limit فعال شده و پیام‌ها در حال حذف شدن هستند [citation:8][citation:17].

محدود کردن فضای Journal

در فایل /etc/systemd/journald.conf می‌توانید محدودیت‌های فضایی تعیین کنید:

[Journal] SystemMaxUse=500M SystemKeepFree=1G SystemMaxFileSize=50M MaxRetentionSec=1month

معنی این پارامترها:

• SystemMaxUse: حداکثر فضایی که Journal می‌تواند اشغال کند.
• SystemKeepFree: حداقل فضای آزادی که باید روی دیسک باقی بماند.
• SystemMaxFileSize: حداکثر حجم هر فایل Journal.
• MaxRetentionSec: حداکثر مدت زمانی که لاگ‌ها نگهداری می‌شوند [citation:3].

بررسی سلامت فایل‌های Journal

اگر شک دارید که فایل‌های Journal خراب شده‌اند، می‌توانید بررسی کنید:

journalctl --verify

این دستور فایل‌های Journal را بررسی می‌کند و اگر مشکلی پیدا کند، گزارش می‌دهد [citation:1][citation:3].

اشتباهات رایج

• فراموش کردن sudo: برای دیدن همه لاگ‌ها (مخصوصاً لاگ‌های Kernel و سرویس‌ها) معمولاً به دسترسی root یا عضویت در گروه systemd-journal یا adm نیاز دارید [citation:10].
• نداشتن ذخیره‌سازی دائمی: اگر /var/log/journal را نسازید، با هر ری‌استارت همه لاگ‌ها از بین می‌روند و عیب‌یابی مشکل می‌شود [citation:13].
• ندیدن Rate Limit: اگر پیام Suppressed N messages در لاگ‌ها دیدید، یعنی Rate Limit فعال شده و برخی پیام‌ها ذخیره نشده‌اند. این می‌تواند عیب‌یابی را گمراه کند [citation:8].
• Vacuum بدون بررسی: پاک کردن لاگ‌ها قبل از اطمینان از اینکه به آن‌ها نیاز ندارید، می‌تواند اطلاعات حیاتی برای Audit یا عیب‌یابی را از بین ببرد [citation:3].

سؤالات متداول

منابع و مستندات