آموزش بررسی فایل‌های لاگ در /var/log لینوکس

دایرکتوری Linux(لینوکس) /var/log یکی از اولین مکان‌هایی است که هنگام عیب‌یابی سرور، Service یا Application در لینوکس باید بررسی شود.

اطلاعات مربوط به مواردی مانند:

• Login و Authentication
• SSH
• Kernel
• Boot
• Cron Jobs
• Mail Server
• Web Server
• Database
• Firewall
• System Services

ممکن است در فایل‌ها یا Subdirectoryهای مختلف داخل:

/var/log

ذخیره شوند.

طبق ساختار استاندارد Filesystem در لینوکس، /var برای اطلاعاتی استفاده می‌شود که در طول کار سیستم تغییر می‌کنند و /var/log محل متداول نگهداری فایل‌های Log است.

با این حال، در سیستم‌های جدید مبتنی بر systemd تمام Logها الزاماً به شکل فایل ASCII Text جداگانه در /var/log قرار ندارند. بخشی از Logها توسط:

systemd-journald

جمع‌آوری شده و از طریق:

journalctl

قابل مشاهده هستند.

در این مقاله ساختار /var/log، فایل‌های مهم در Distribution(توزیع)های مختلف و روش بررسی آن‌ها را توضیح می‌دهیم.

دایرکتوری /var/log چیست؟

برای مشاهده محتوای آن اجرا کنید:

ls -lah /var/log

خروجی بسته به Distribution و Serviceهای نصب‌شده متفاوت است و ممکن است مشابه زیر باشد:

auth.log
boot.log
btmp
cron
journal/
kern.log
lastlog
mail.log
messages
secure
syslog
wtmp

apache2/
httpd/
nginx/
mysql/

وجود تمام این فایل‌ها روی یک Server الزامی نیست.

برای مثال Ubuntu و AlmaLinux ممکن است اطلاعات مشابهی را در فایل‌هایی با نام متفاوت ذخیره کنند.

همچنین Applicationهای نصب‌شده می‌توانند Subdirectoryهای مخصوص خودشان را در /var/log ایجاد کنند. Red Hat نیز تأکید می‌کند که لیست واقعی Logهای موجود به Serviceها و Applicationهای نصب‌شده بستگی دارد.

مشاهده سریع Logهای موجود

برای مشاهده فایل‌ها:

ls -lh /var/log

برای مشاهده Subdirectoryها نیز:

tree /var/log/

اگر تعداد فایل‌ها زیاد است:

ls -lah /var/log | less

برای مرتب‌سازی بر اساس زمان تغییر:

ls -lht /var/log

در این حالت جدیدترین فایل‌های تغییرکرده در ابتدای خروجی قرار می‌گیرند.

این روش هنگام Troubleshooting بسیار مفید است؛ چون می‌توان دید کدام Log دقیقاً در زمان رخ دادن مشکل تغییر کرده است.

تفاوت Logها در Ubuntu/Debian و RHEL

یکی از مهم‌ترین نکات این است که نام فایل‌های Log بین Distributionها یکسان نیست.

به‌صورت کلی:

Ubuntu به‌طور سنتی از:

/var/log/syslog

برای System Log و:

/var/log/auth.log

برای Authentication استفاده می‌کند.

در RHEL و Distributionهای مرتبط، Red Hat فایل‌های زیر را از Logهای اصلی معرفی می‌کند:

/var/log/messages
/var/log/secure
/var/log/maillog
/var/log/cron
/var/log/boot.log

بنابراین اگر دستور زیر:

tail /var/log/auth.log

روی AlmaLinux خطای:

No such file or directory

داد، نباید نتیجه گرفت Logging غیرفعال است.

در این Distribution باید احتمالاً:

tail /var/log/secure

یا Journal را بررسی کنید.

نمایی از محتویات /var/log در ubuntu:

نمایی از محتویات /var/log در Almalinux:

فایل /var/log/syslog

در Ubuntu و Debian یکی از مهم‌ترین فایل‌های System Log است:

/var/log/syslog

این فایل می‌تواند Eventهای عمومی مربوط به System و Serviceهای مختلف را نگهداری کند.

برای مشاهده آخرین خطوط:

sudo tail /var/log/syslog

مثلاً:

Sep 07 09:14:15 server systemd[1]: Started example.service
Sep 07 09:14:19 server cron[1240]: ...
Sep 07 09:14:21 server kernel: ...

برای مشاهده 100 خط آخر:

sudo tail -n 100 /var/log/syslog

برای مشاهده Live:

sudo tail -f /var/log/syslog

tail -f هنگام بازتولید یک مشکل بسیار کاربردی است.

برای مثال:

sudo tail -f /var/log/syslog

را اجرا می‌کنید و سپس Service یا Application مشکل‌دار را دوباره بررسی می‌کنید.

فایل /var/log/messages

در RHEL، AlmaLinux و Rocky Linux معمولاً System Messageهای عمومی در:

/var/log/messages

ذخیره می‌شوند.

برای مثال:

sudo tail -n 100 /var/log/messages

Red Hat این فایل را محل عمومی بسیاری از Syslog Messageها معرفی می‌کند و Logهای Authentication، Mail، Cron و Boot را در فایل‌های جداگانه دسته‌بندی می‌کند.

برای دنبال کردن Log:

sudo tail -f /var/log/messages

فایل /var/log/auth.log

در Ubuntu و Debian:

/var/log/auth.log

برای Eventهای Authentication مهم است.

مواردی مانند:

SSH Login
Failed SSH Login
sudo
PAM
User Authentication

می‌توانند در این فایل ثبت شوند.

برای مثال:

sudo tail -n 100 /var/log/auth.log

برای مشاهده SSH Eventها:

sudo grep sshd /var/log/auth.log

Ubuntu نیز auth.log را محل متداول Logهای SSH و Authentication معرفی می‌کند.

برای مثال ممکن است ببینید:

Failed password for root from 203.0.113.10 port 48122 ssh2

یا:

Accepted publickey for admin from 198.51.100.20 port 51244 ssh2

این Log هنگام بررسی Attemptهای Login یا مشکل SSH بسیار مهم است.

فایل /var/log/secure

معادل رایج Authentication Log در RHEL-family:

/var/log/secure

است.

برای مشاهده:

sudo tail -n 100 /var/log/secure

برای SSH:

sudo grep sshd /var/log/secure

Red Hat این فایل را برای Security و Authentication Messageها در نظر می‌گیرد.

بنابراین:

Ubuntu / Debian
/var/log/auth.log

تقریباً همان نقشی را دارد که:

RHEL / AlmaLinux / Rocky Linux
/var/log/secure

دارد.

فایل /var/log/kern.log

در بعضی Debian/Ubuntu Systemها Kernel Messageها در:

/var/log/kern.log

ذخیره می‌شوند.

برای مشاهده:

sudo tail /var/log/kern.log

این فایل می‌تواند هنگام بررسی مواردی مانند:

Disk errors
NIC problems
Kernel warnings
Driver errors
OOM
Hardware events

مفید باشد.

Ubuntu این فایل را یکی از محل‌های Log مربوط به Linux Kernel معرفی می‌کند.

در سیستم‌های جدید ممکن است بخش زیادی از همین اطلاعات را از Journal نیز دریافت کنید:

journalctl -k

یا:

dmesg

بررسی Logهای Boot

بسته به Distribution ممکن است فایل:

/var/log/boot.log

وجود داشته باشد.

برای مثال:

sudo less /var/log/boot.log

اما در سیستم‌های جدید مبتنی بر systemd، برای بررسی Boot معمولاً Journal اطلاعات کامل‌تری ارائه می‌کند.

مثلاً:

journalctl -b

برای Boot فعلی.

یا:

journalctl -b -1

برای Boot قبلی.

از آنجا که این موضوع مقاله جداگانه دارد، در اینجا وارد جزئیات نمی‌شویم:

آموزش بررسی خطاهای Boot در لینوکس با journalctl -b

برای آموزش عمومی journalctl نیز:

آموزش کامل journalctl در لینوکس

Logهای Cron

در Distributionهای RHEL-family ممکن است:

/var/log/cron

وجود داشته باشد.

برای مثال:

sudo tail -n 100 /var/log/cron

در Ubuntu/Debian اطلاعات Cron معمولاً در:

/var/log/syslog

قابل مشاهده است.

برای مثال:

grep CRON /var/log/syslog

مستندات Ubuntu نیز اشاره می‌کنند که اجرای Cron Jobها به‌صورت پیش‌فرض در syslog ثبت می‌شود.

برای آموزش کامل Cron:

آموزش کامل cron

Logهای Mail

روی Mail Server ممکن است فایل‌هایی مانند:

/var/log/mail.log

در Debian/Ubuntu یا:

/var/log/maillog

در RHEL-family وجود داشته باشند.

برای مثال:

sudo tail -f /var/log/maillog

یا:

sudo tail -f /var/log/mail.log

این فایل‌ها هنگام بررسی:

SMTP Connection
Mail Delivery
Authentication
Rejected Message
Mail Queue
Remote Server Error

کاربرد دارند.

البته نوع Mail Server نیز مهم است.

Exim، Postfix و سایر MTAها ممکن است مسیر ذخیره‌سازی Log متفاوتی داشته باشند.

Logهای Web Server

Applicationها معمولاً می‌توانند Subdirectory مخصوص خودشان را داخل /var/log داشته باشند.

مثلاً Apache در Ubuntu:

/var/log/apache2/

ممکن است شامل:

access.log
error.log

باشد. Ubuntu نیز این ساختار را برای Apache مستند کرده است.

برای مثال:

sudo tail -f /var/log/apache2/error.log

در RHEL-family مسیر Apache معمولاً:

/var/log/httpd/

است.

Red Hat نیز /var/log/httpd/ را نمونه‌ای از Subdirectory اختصاصی یک Service در /var/log معرفی می‌کند.

برای Nginx معمولاً:

/var/log/nginx/

را بررسی می‌کنیم.

برای مثال:

sudo tail -f /var/log/nginx/error.log

Logهای Database

بسته به Database Server و (تنظیمات)Configuration ممکن است Directoryهایی مانند:

/var/log/mysql/
/var/log/mariadb/

وجود داشته باشند.

اما نباید فرض کنید MySQL یا MariaDB همیشه در همین مسیر Log می‌نویسد.

برای پیدا کردن مسیر واقعی Log باید تنظیمات همان Database Server را نیز بررسی کنید.

برای مثال ممکن است Error Log از طریق:

journalctl -u mariadb

یا:

journalctl -u mysql

در دسترس باشد.

همه Logها الزاماً داخل /var/log نیستند

این نکته در Hosting Environment اهمیت زیادی دارد.

ممکن است یک Application Log در مسیری مانند:

/home/user/application/logs/

یا:

/opt/application/log/

یا داخل Directory مربوط به کنترل پنل ذخیره شود.

همچنین Serviceهای مبتنی بر systemd ممکن است اصلاً Text Log اختصاصی ایجاد نکنند و Output آن‌ها مستقیماً توسط:

systemd-journald

جمع‌آوری شود.

بنابراین عدم وجود فایل log در /var/log به معنای عدم وجود log نیست.

نقش systemd-journald

در توزیع‌های لینوکسی جدید، Service زیر:

systemd-journald

بخش مهمی از Logging سیستم را مدیریت می‌کند.

journald می‌تواند پیام‌های:

• Kernel
• Boot
• Service stdout/stderr
• Syslog

را جمع‌آوری کند. Red Hat نیز توضیح می‌دهد که systemd-journald این اطلاعات را جمع‌آوری کرده و در سیستم‌های دارای rsyslog می‌تواند آن‌ها را برای پردازش بیشتر به rsyslog منتقل کند.

بنابراین ممکن است یک Log هم از:

journalctl

و هم از یک فایل داخل:

/var/log

قابل مشاهده باشد.

/var/log/journal چیست؟

اگر Persistent Journal فعال باشد، systemd می‌تواند Journal را در:

/var/log/journal/

ذخیره کند.

اگر Journal به‌صورت Volatile باشد، Logها معمولاً در:

/run/log/journal/

قرار می‌گیرند و بعد از Reboot از بین می‌روند.

مستندات systemd همین تفاوت را برای Persistent و Volatile Storage توضیح می‌دهند.

به صورت کلی داده volatile وضعیتی مشابه ram دارد. پس از reboot شدن سیستم اطلاعات رم از بین می‌رود ولی اطلاعات disk اصلی که یک نوع داده persistent است باقی می‌ماند.

برای بررسی:

ls -lah /var/log/journal

اگر Directory وجود نداشت، به معنی از کار افتادن Journal نیست.

ممکن است داده‌ها در:

/run/log/journal

باشند.

برای بررسی اینکه شیوه تنظیم logging در journal چگونه است می‌توانید فایل /etc/systemd/journal.conf را بررسی کنید و مقدار storage را بخوانید.

یا می‌توانید از دستور زیر استفاده کنید:

systemd-analyze cat-config systemd/journald.conf | grep -i Storage

۳ حالت برای Storage تعریف شده است:

• Storage=auto: بر اساس وضعیت disk تصمیم‌گیری نوع ذخیره سازی انجام می‌شود
• Storage=persistent: محتویات log ثبت شده توسط journal در /var/log/journal قرار می‌گیرد
• Storage=persistent: محتویات log ثبت شده پس از reboot سیستم از بین می‌روند

ب

فایل‌های .journal را با cat باز نکنید

فایل‌های داخل:

/var/log/journal/

مانند بقیه Logها ascii Text معمولی نیستند.

با دستور file می‌توانید نوع این فایل‌ها را مقایسه کنید.

برای .journal خروجی مشابه زیر خواهد بود:

در حالی که بقیه فایل‌های .log و دیگر فایل‌ها خروجی مانند این است:

بنابراین نباید انتظار داشته باشید:

cat /var/log/journal/.../*.journal

خروجی قابل خواندن ایجاد کند.

برای مشاهده آن‌ها از:

journalctl

استفاده کنید.

برای مثال برای Service مشخص:

journalctl -u sshd

مشاهده Log با less

برای فایل‌های بزرگ معمولاً:

cat

گزینه مناسبی نیست.

مثلاً اجرای:

cat /var/log/syslog

روی یک Log چندصد مگابایتی حجم زیادی Output تولید می‌کند.

بهتر است از:

less /var/log/syslog

استفاده کنید.

داخل less:

Space       صفحه بعد
b           صفحه قبل
/word       جستجو
n           نتیجه بعدی
q           خروج

برای مثال:

sudo less /var/log/auth.log

سپس داخل less:

/Failed

را وارد کنید در نتیجه جستجو ورودهای ناموفق و هر خط دیگری که کلمه Failed در آن وجود داشته باشد نمایش داده می‌شود.

مشاهده ابتدای Log با head

برای مشاهده اولین خطوط:

head /var/log/syslog

یا:

head -n 50 /var/log/syslog

این دستور در بررسی File Format یا قدیمی‌ترین Eventهای موجود مفید است.

مشاهده آخر Log با tail

در Troubleshooting معمولاً جدیدترین Eventها اهمیت بیشتری دارند.

برای مشاهده 50 خط آخر:

tail -n 50 /var/log/syslog

یا:

tail -n 100 /var/log/messages

مشاهده Live Log

برای مشاهده Entryهای جدید:

tail -f /var/log/syslog

یا:

tail -f /var/log/nginx/error.log

سپس مشکل را دوباره ایجاد کنید.

برای مثال:

Terminal 1:
tail -f /var/log/nginx/error.log

Terminal 2:
curl https://example.com

اگر Web Server هنگام Request خطا تولید کند، معمولاً می‌توانید آن را همان لحظه مشاهده کنید.

برای خروج:

Ctrl + C

جستجو داخل Log

برای جستجوی یک عبارت:

grep "error" /var/log/syslog

برای Case-insensitive Search:

grep -i "error" /var/log/syslog

برای چند Pattern:

grep -Ei "error|failed|critical|warning" /var/log/syslog

از آنجا که جستجوی حرفه‌ای Logها با grep مقاله مستقل دارد، در اینجا فقط مثال ساده ارائه شد.

آموزش جستجوی خطا در لاگ‌های لینوکس با grep

Logهای قدیمی و Rotate شده

بعد از مدتی ممکن است فایل‌هایی مشابه زیر مشاهده کنید:

syslog
syslog.1
syslog.2.gz
syslog.3.gz

یا:

messages
messages-20260901

این فایل‌ها معمولاً نتیجه Log Rotation هستند.

دستور ‌ls -lh /var/log/*log*[1-9]* تمام فایل‌هایی که در آن‌ها کلمه log و بعد از آن یک شماره از ۱ تا ۹ آمده است را نشان می‌دهد. این دستور برای مشاهده فایل‌های حاصل از log rotationای که فرمت .log دارند مناسب است.

هدف Rotation جلوگیری از رشد نامحدود Log Fileها است.

برای فایل Text معمولی:

less /var/log/syslog.1

و برای فایل فشرده:

zless /var/log/syslog.2.gz

می‌توان استفاده کرد.

برای جستجو داخل فایل فشرده:

zgrep -i error /var/log/syslog.2.gz

در مقاله جداگانه نحوه تنظیم این فرآیند را بررسی خواهیم کرد:

آموزش مدیریت و چرخش لاگ‌ها در لینوکس با logrotate

فایل‌های wtmp، btmp و lastlog

تمام Fileهای داخل /var/log فایل متنی ساده نیستند.

برای مثال ممکن است ببینید:

/var/log/wtmp
/var/log/btmp
/var/log/lastlog

نباید این فایل‌ها را با:

cat

بررسی کنید.

بررسی wtmp

wtmp اطلاعات Login Sessionها را نگهداری می‌کند.

برای خواندن آن:

last

استفاده کنید.

مثلاً:

admin    pts/0    192.0.2.15    Sun Sep 7 09:20
root     pts/1    198.51.100.5  Sun Sep 7 08:55

بررسی btmp

btmp معمولاً اطلاعات Login Failure را ثبت می‌کند.

برای مشاهده:

sudo lastb

این Command هنگام بررسی Attemptهای ناموفق Login کاربرد دارد.

بررسی lastlog

برای مشاهده آخرین Login هر User:

lastlog

استفاده کنید.

بنابراین:

wtmp    → last
btmp    → lastb
lastlog → lastlog

Permission فایل‌های Log

بعضی Logها اطلاعات حساس دارند و فقط توسط:

root

یا Groupهای خاص قابل مشاهده هستند.

مثلاً:

cat /var/log/secure

ممکن است:

Permission denied

نمایش دهد.

در این حالت:

sudo less /var/log/secure

استفاده کنید.

نباید برای خواندن Log، دسترسی آن را به شکل ناامن تغییر دهید.

مثلاً:

chmod 777 /var/log/secure

راه‌حل صحیح نیست.

بررسی Permission یک Log

برای مشاهده Owner و Permission:

ls -l /var/log/auth.log

یا:

stat /var/log/auth.log

برای مثال:

-rw-r----- 1 syslog adm 124K Sep 7 10:22 /var/log/auth.log

از این خروجی می‌توان:

Owner
Group
Permissions
Size
Modification Time

را بررسی کرد.

پیدا کردن Logهای حجیم

گاهی خود Logها علت پر شدن Disk هستند.

ابتدا:

du -sh /var/log

اجرا کنید.

برای بررسی Subdirectoryها:

du -h --max-depth=1 /var/log | sort -h

یا:

sudo du -ah /var/log | sort -rh | head -20

می‌تواند فایل‌های حجیم را مشخص کند.

همچنین:

ls -lhS /var/log

فایل‌های همان Directory را بر اساس Size مرتب می‌کند.

برای راهکارهای عمومی‌تر:

پیدا کردن فایل‌های حجیم در لینوکس

قبل از حذف یک Log بزرگ چه کار کنیم؟

فرض کنید:

du -sh /var/log/*

نشان می‌دهد:

15G /var/log/example.log

فوراً فایل را حذف نکنید.

ابتدا مشخص کنید:

1. چه Serviceای فایل را ایجاد کرده است؟
2. چرا Log با این سرعت رشد کرده؟
3. آیا یک خطا دائماً تکرار می‌شود؟
4. آیا logrotate برای آن تنظیم شده؟
5. آیا Application بعد از حذف فایل می‌تواند Log File جدید ایجاد کند؟

برای مشاهده آخر فایل:

tail -n 100 /var/log/example.log

اگر یک Error میلیون‌ها بار تکرار شده باشد، علت اصلی باید برطرف شود.

صرفاً حذف Log ممکن است چند ساعت بعد دوباره Disk را پر کند.

حذف فایل Log در حال استفاده همیشه بهترین راه نیست

اگر یک Process فایل Log را باز نگه داشته باشد، حذف فایل ممکن است فوراً فضای Disk را آزاد نکند.

Process همچنان File Descriptor باز را نگه می‌دارد.

در چنین شرایطی ابزار:

lsof

می‌تواند مفید باشد:

sudo lsof +L1

این دستور می‌تواند فایل‌هایی را نشان دهد که Delete شده‌اند ولی Process هنوز آن‌ها را باز نگه داشته است.

پس هنگام بررسی Disk فقط به خروجی:

ls

اکتفا نکنید.

چگونه بفهمیم کدام Log را باید بررسی کنیم؟

بهتر است از نوع مشکل شروع کنیم.

این جدول نقطه شروع است و مسیر واقعی Log به Distribution و تنظیمات بستگی دارد.

مثال عملی: SSH Login کار نمی‌کند

فرض کنید کاربر نمی‌تواند به Ubuntu Server متصل شود.

ابتدا (از طریق console یا یک session متصل):

sudo tail -f /var/log/auth.log

را اجرا کنید.

سپس از Client دوباره Login کنید.

ممکن است ببینید:

Failed password for user from 203.0.113.15

یا:

User test not allowed because account is locked

در AlmaLinux/Rocky Linux همین بررسی معمولاً از:

sudo tail -f /var/log/secure

انجام می‌شود.

این روش بسیار بهتر از تغییر تصادفی تنظیمات است، چون ابتدا Error واقعی را مشاهده می‌کنیم.

مثال عملی: Service بالا نمی‌آید

فرض کنید:

systemctl start example.service

ناموفق است.

ابتدا:

systemctl status example.service

را بررسی کنید.

سپس:

journalctl -u example.service

و در صورت وجود Application Log:

tail -n 100 /var/log/example/example.log

را بررسی کنید.

همیشه ممکن است اطلاعات مهم فقط در Journal یا فقط در Application Log موجود باشد.

برای آموزش مدیریت Serviceها:

آموزش کامل systemctl

و برای Journal:

آموزش کامل journalctl در لینوکس

مثال عملی: Server بعد از Reboot مشکل دارد

در چنین حالتی معمولاً بررسی تصادفی Fileهای /var/log بهترین نقطه شروع نیست.

ابتدا:

journalctl -b

را بررسی کنید.

برای Errorهای Boot:

journalctl -b -p err

و برای Boot قبلی در صورت وجود Persistent Journal:

journalctl -b -1

این Scenario به‌صورت کامل در مقاله زیر بررسی می‌شود:

آموزش بررسی خطاهای Boot در لینوکس با journalctl -b

مثال عملی: Disk پر شده است

ابتدا:

df -h

را اجرا کنید.

اگر Partition مربوط به /var یا / پر است:

sudo du -h --max-depth=1 /var | sort -h

و سپس:

sudo du -h --max-depth=1 /var/log | sort -h

را بررسی کنید.

اگر Logها مشکل هستند، باید مشخص شود:

• کدام Log؟
• کدام Service؟
• چرا در حال افزایش حجم است؟
• آیا logrotate تنظیم شده است؟

برای دستورهای مرتبط:

• آموزش کامل دستور df در لینوکس
• آموزش کامل دستور du در لینوکس

تفاوت File Log و Journal

به شکل ساده:

این دو سیستم می‌توانند همزمان نیز وجود داشته باشند.

برای مثال یک Server ممکن است هم:

/var/log/messages

داشته باشد و هم:

journalctl

اطلاعات همان Service را نمایش دهد.

/var/log و Filesystem Hierarchy

برای درک بهتر دلیل وجود /var/log باید ساختار کلی Linux Filesystem را نیز شناخت.

/var برای Variable Data مانند Logها، Cacheها و سایر اطلاعاتی استفاده می‌شود که در طول کار سیستم تغییر می‌کنند. استاندارد Filesystem Hierarchy نیز /var/log را برای Log Fileها تعریف می‌کند.

برای توضیح کامل ساختار Linux:

FHS؛ آشنایی با ساختار فایل‌ و پوشه‌های لینوکسی

اشتباهات رایج هنگام بررسی /var/log

فرض کردن اینکه همه Distributionها syslog دارند

روی RHEL-family معمولاً:

/var/log/messages

را بررسی می‌کنیم.

فرض کردن اینکه همه Distributionها auth.log دارند

در RHEL-family معمولاً:

/var/log/secure

است.

استفاده از cat برای Log بسیار بزرگ

به‌جای:

cat huge.log

از:

less huge.log

یا:

tail -n 100 huge.log

استفاده کنید.

تلاش برای خواندن فایل .journal با cat

برای Journal از:

journalctl

استفاده کنید.

پاک کردن Log قبل از پیدا کردن علت رشد آن

ممکن است همان Error دوباره میلیون‌ها Entry ایجاد کند.

Permission برابر 777 برای خواندن Log

از:

sudo

استفاده کنید و Permission امنیتی Log را تغییر ندهید.

تصور اینکه Log Rotation باعث حذف Error اصلی می‌شود

فایل قبلی ممکن است با نام:

.log.1

یا به‌صورت:

.gz

هنوز موجود باشد.

بررسی نکردن زمان دقیق بروز مشکل

هنگام Troubleshooting ابتدا زمان وقوع مشکل را مشخص کنید.

برای مثال:

Problem occurred around:
2026-09-07 10:30

سپس همان بازه را داخل Log بررسی کنید.

این کار بسیار سریع‌تر از خواندن چندصد هزار خط Log است.

Workflow پیشنهادی برای بررسی Logها

برای یک مشکل Linux Server می‌توان از Workflow زیر استفاده کرد:

Identify the problem
        ↓
Determine exact time
        ↓
Identify affected service
        ↓
Check /var/log
        ↓
Check distribution-specific log
        ↓
Check journalctl
        ↓
Search error / failed / warning
        ↓
Reproduce the problem
        ↓
Watch log in real time
        ↓
Fix root cause

برای مثال اگر SSH مشکل دارد:

Ubuntu/Debian
      ↓
/var/log/auth.log

RHEL-family
      ↓
/var/log/secure

اگر یک systemd Service مشکل دارد:

systemctl status
      ↓
journalctl -u service
      ↓
Application-specific log

دستورات سریع بررسی /var/log

مطالعه بیشتر

مقالات مرتبط در دانشنامه:

• آموزش کامل journalctl در لینوکس
• آموزش کامل systemctl
• آموزش کامل cron
• آموزش کامل دستور df در لینوکس
• آموزش کامل دستور du در لینوکس
• FHS؛ آشنایی با ساختار فایل‌ و پوشه‌های لینوکسی
• آموزش جستجوی خطا در لاگ‌های لینوکس با grep
• آموزش مدیریت و چرخش لاگ‌ها در لینوکس با logrotate
• آموزش بررسی خطاهای Boot در لینوکس با journalctl -b

منابع:

• Linux filesystem hierarchy manual
• systemd-journald documentation
• Red Hat – Troubleshooting problems by using log files
• Ubuntu – Linux Log Files

جمع‌بندی

پوشه:

/var/log

محل اصلی بسیاری از Logهای System و Application در Linux است، اما نام فایل‌ها بسته به Distribution و تنظیمات سیستم متفاوت است.

برای مثال در Ubuntu/Debian معمولاً:

/var/log/syslog
/var/log/auth.log

را مشاهده می‌کنیم، در حالی که در RHEL، AlmaLinux و Rocky Linux فایل‌های:

/var/log/messages
/var/log/secure

رایج‌تر هستند.

در سیستم‌های جدید نیز باید در کنار /var/log، سیستم:

systemd-journald

و دستور:

journalctl

را در نظر گرفت؛ زیرا بعضی Serviceها Log مستقل Text ایجاد نمی‌کنند.

هنگام Troubleshooting بهتر است ابتدا زمان دقیق مشکل، Service مربوطه و Distribution سرور مشخص شود و سپس Log مناسب با ابزارهایی مانند:

less
tail
grep
journalctl

بررسی شود.

در مقالات بعدی این مجموعه، جستجوی Errorها با grep، بررسی Boot با journalctl -b و مدیریت Log Rotation با logrotate را به‌صورت جداگانه بررسی خواهیم کرد.