آموزش بررسی Logهای لینوکس با Journalctl و فایل‌های لاگ
مقدمه:
آموزش بررسی Logهای لینوکس با Journalctl و فایل‌های لاگ به شما کمک می‌کند علت توقف سرویس‌ها، خطاهای ورود، مشکلات شبکه و اختلال برنامه‌ها را بدون حدس‌زدن پیدا کنید. در توزیع‌های مبتنی بر systemd، دستور journalctl ابزار اصلی مشاهده رویدادهای ثبت‌شده در Journal است. در کنار آن، بسیاری از سرویس‌ها همچنان گزارش‌های خود را به‌صورت فایل متنی در مسیر /var/log نگه می‌دارند. برای عیب‌یابی دقیق باید نحوه استفاده از هر دو منبع را بدانید.
فهرست مطالب
- لاگ لینوکس چیست و چه اطلاعاتی دارد؟
- تفاوت Journal با فایل‌های متنی لاگ
- پیش‌نیازها و نکات امنیتی بررسی گزارش‌ها
- دستورات اصلی Journalctl
- فیلتر لاگ‌ها بر اساس سرویس، زمان و اولویت
- بررسی فایل‌های موجود در
/var/log - مدیریت فضای اشغال‌شده توسط Journal
- سناریوهای عملی عیب‌یابی
- اشتباهات رایج هنگام تحلیل لاگ
- چک‌لیست بررسی گزارش‌های سرور
- جمع‌بندی و سؤالات متداول
لاگ لینوکس چیست و چرا باید آن را بررسی کنیم؟
لاگ مجموعه‌ای از رویدادهایی است که سیستم‌عامل، کرنل، سرویس‌ها و برنامه‌ها ثبت می‌کنند. این رویدادها می‌توانند شامل زمان شروع یا توقف سرویس، خطای احراز هویت، هشدار کمبود منابع، درخواست‌های وب و پیام‌های مربوط به سخت‌افزار باشند.
هنگامی که یک سرویس اجرا نمی‌شود، مشاهده وضعیت آن تنها اولین مرحله است. علت دقیق مشکل معمولاً در پیام‌های قبل و بعد از توقف سرویس قرار دارد. به همین دلیل، بررسی ترتیب زمانی رویدادها اهمیت زیادی دارد.
لاگ‌ها برای این موارد کاربرد دارند:
- پیداکردن دلیل اجرا نشدن یک سرویس
- بررسی تلاش‌های ورود موفق یا ناموفق
- تحلیل خطاهای وب‌سرور و برنامه
- شناسایی اختلال‌های کرنل، دیسک یا شبکه
- بررسی رویدادهای قبل از راه‌اندازی مجدد سرور
- پیگیری تغییرات و اقدامات مدیریتی
مطالعه بیشتر: آموزش مدیریت سرویس‌ها با systemctl
اگر پیام‌های سرور برای شما مبهم است یا یک سرویس بدون علت مشخص متوقف می‌شود، کارشناسان شرکت تجارت الکترونیک نوژن می‌توانند وضعیت سرویس، منابع و لاگ‌های مرتبط را بررسی کرده و برای عیب‌یابی فنی پروژه راهنمایی ارائه دهند.
تفاوت Journalctl با فایل‌های لاگ لینوکس
در سیستم‌های مبتنی بر systemd، سرویس systemd-journald رویدادهای سیستم و سرویس‌ها را جمع‌آوری می‌کند. دستور journalctl رابط جست‌وجو و نمایش این اطلاعات است و می‌تواند گزارش‌ها را با معیارهایی مانند سرویس، زمان، بوت و اولویت فیلتر کند. freedesktop.org
فایل‌های متنی لاگ معمولاً در /var/log قرار می‌گیرند. تولید و محل ذخیره این فایل‌ها به توزیع لینوکس، پیکربندی rsyslog و تنظیمات خود برنامه بستگی دارد. بنابراین وجود یک فایل مشخص را نباید در تمام سرورها قطعی فرض کرد.
| ویژگی | Systemd Journal | فایل متنی لاگ |
|---|---|---|
| ابزار اصلی مشاهده | journalctl |
less، tail، grep و ابزارهای مشابه |
| نوع داده | گزارش ساختاریافته همراه با فیلدهای سیستمی | معمولاً متن خط‌به‌خط |
| فیلتر بر اساس سرویس | با گزینه -u |
وابسته به نام و ساختار فایل |
| فیلتر بر اساس Boot | با گزینه -b |
معمولاً نیازمند تحلیل زمان یا فایل‌های چرخش‌یافته |
| مشاهده زنده | journalctl -f |
tail -f |
| محل متداول | /run/log/journal یا /var/log/journal |
مسیر /var/log و زیرشاخه‌های آن |
| مدیریت نگهداری | تنظیمات journald و گزینه‌های Vacuum | معمولاً Logrotate یا تنظیمات برنامه |
در عمل، انتخاب یکی از این دو روش کافی نیست. ممکن است گزارش اجرای سرویس در Journal ثبت شود، اما جزئیات درخواست‌ها و خطاهای برنامه در فایل اختصاصی همان برنامه قرار داشته باشد.
نوع سرویس، میزان ترافیک و نیاز به نگهداری گزارش‌ها روی انتخاب زیرساخت اثر می‌گذارد. برای مشاهده سرویس‌های میزبانی و سرور متناسب با این نیازها می‌توانید خدمات شرکت تجارت الکترونیک نوژن را بررسی کنید.
مطالعه بیشتر: خرید سرور مجازی لینوکس
پیش‌نیازها و نکات امنیتی بررسی لاگ‌ها
برای مشاهده همه گزارش‌های سیستمی معمولاً به حسابی با دسترسی sudo نیاز دارید. کاربران عادی فقط بخشی از Journal را می‌بینند و ممکن است به فایل‌هایی مانند گزارش‌های احراز هویت دسترسی نداشته باشند.
قبل از اجرای دستورات مدیریتی، این نکات را رعایت کنید:
- برای مشاهده گزارش‌ها از حساب کاربری دارای دسترسی کنترل‌شده استفاده کنید.
- پیش از حذف یا پاکسازی لاگ، سیاست نگهداری و نیازهای عیب‌یابی را بررسی کنید.
- از اجرای مستقیم
rmروی فایل‌های فعال Journal یا گزارش‌های در حال استفاده خودداری کنید. - لاگ‌ها را بدون بازبینی در کانال عمومی منتشر نکنید.
- پیش از ارسال گزارش برای پشتیبانی، اطلاعاتی مانند IP، نام کاربری، دامنه، مسیر داخلی و Token را بررسی کنید.
- هنگام تحلیل زمان رویدادها، منطقه زمانی سرور را با دستور
timedatectlکنترل کنید.
اگر قصد تغییر تنظیمات journald، rsyslog یا Logrotate را دارید، ابتدا از فایل پیکربندی مربوطه نسخه پشتیبان تهیه کنید. یک خطای کوچک در پیکربندی ممکن است باعث توقف ثبت بعضی رویدادها شود.
مطالعه بیشتر: آموزش ساخت کاربر و دادن دسترسی Sudo در Ubuntu
آموزش بررسی Logهای لینوکس با Journalctl و فایل‌های لاگ
نمایش تمام گزارش‌های Journal
برای مشاهده گزارش‌های در دسترس کاربر فعلی، دستور زیر را اجرا کنید:
sudo journalctlخروجی از قدیمی‌ترین پیام قابل دسترس شروع می‌شود و معمولاً در محیطی مانند less نمایش داده خواهد شد. با کلیدهای جهت‌نما جابه‌جا شوید، با / جست‌وجو کنید و برای خروج کلید q را فشار دهید.
برای نمایش جدیدترین پیام‌ها در ابتدای خروجی از گزینه Reverse استفاده کنید:
sudo journalctl -rاگر فقط به چند رویداد آخر نیاز دارید، تعداد خطوط را محدود کنید:
sudo journalctl -n 100
مشاهده زنده لاگ‌ها
برای دنبال‌کردن رویدادهای جدید به‌صورت زنده از دستور زیر استفاده کنید:
sudo journalctl -fاین حالت هنگام بازتولید یک خطا مفید است. برای مثال می‌توانید دستور را اجرا کنید و سپس در پنجره دیگری سرویس یا برنامه موردنظر را آزمایش کنید. گزینه -f پیام‌های جدید را هم‌زمان با اضافه‌شدن به Journal نمایش می‌دهد. freedesktop.org
برای خروج از حالت زنده کلیدهای Ctrl+C را فشار دهید.
فیلترکردن گزارش‌ها در Journalctl
نمایش همه رویدادهای سرور معمولاً خروجی بسیار گسترده‌ای ایجاد می‌کند. فیلترکردن صحیح گزارش‌ها سرعت عیب‌یابی را افزایش می‌دهد.
فیلتر بر اساس سرویس
برای مشاهده گزارش‌های یک واحد systemd از گزینه -u استفاده کنید:
sudo journalctl -u nginx.serviceبرای مشاهده صد پیام آخر همان سرویس:
sudo journalctl -u nginx.service -n 100و برای دنبال‌کردن زنده گزارش آن:
sudo journalctl -u nginx.service -fنام واحد ممکن است با نامی که انتظار دارید تفاوت داشته باشد. پیش از اجرای دستور می‌توانید نام صحیح را با systemctl status یا systemctl list-units --type=service پیدا کنید.
فیلتر بر اساس Boot
برای دیدن گزارش‌های بوت فعلی از دستور زیر استفاده کنید:
sudo journalctl -bگزارش‌های بوت قبلی، در صورت نگهداری‌شدن، با این دستور نمایش داده می‌شوند:
sudo journalctl -b -1برای مشاهده فهرست بوت‌های قابل دسترس:
sudo journalctl --list-bootsاین روش زمانی مفید است که سرور پس از اختلال راه‌اندازی مجدد شده و می‌خواهید پیام‌های قبل از Restart را بررسی کنید.
فیلتر بر اساس بازه زمانی
برای نمایش رویدادهای امروز:
sudo journalctl --since "today"برای مشاهده گزارش‌های یک ساعت گذشته:
sudo journalctl --since "1 hour ago"می‌توانید ابتدا و انتهای بازه را هم‌زمان مشخص کنید:
sudo journalctl --since "today 08:00" --until "today 10:00"ترکیب بازه زمانی با نام سرویس معمولاً نتیجه دقیق‌تری می‌دهد:
sudo journalctl -u ssh.service --since "30 minutes ago"فیلتر بر اساس سطح اهمیت
برای نمایش خطاها و پیام‌های مهم‌تر از سطح err از دستور زیر استفاده کنید:
sudo journalctl -p errسطوح متداول شامل emerg، alert، crit، err، warning، notice، info و debug هستند. نمایش پیام‌های Debug ممکن است به فعال‌بودن سطح گزارش‌گیری مربوط در برنامه نیاز داشته باشد.
برای مشاهده هشدارها و خطاهای بوت جاری:
sudo journalctl -b -p warningنمایش پیام‌های کرنل
برای مشاهده گزارش‌های کرنل از گزینه -k استفاده کنید:
sudo journalctl -kترکیب آن با بوت جاری و سطح هشدار برای بررسی مشکلات دیسک، درایور و شبکه کاربردی است:
sudo journalctl -k -b -p warningجدول دستورات پرکاربرد Journalctl
| دستور | کاربرد |
|---|---|
sudo journalctl -n 100 |
نمایش ۱۰۰ رویداد آخر |
sudo journalctl -r |
نمایش جدیدترین گزارش‌ها در ابتدا |
sudo journalctl -f |
دنبال‌کردن زنده رویدادها |
sudo journalctl -u nginx.service |
گزارش‌های یک سرویس مشخص |
sudo journalctl -b |
گزارش‌های بوت فعلی |
sudo journalctl -b -1 |
گزارش‌های بوت قبلی |
sudo journalctl -k |
مشاهده پیام‌های کرنل |
sudo journalctl -p err |
نمایش خطاها و پیام‌های مهم‌تر |
sudo journalctl --since "1 hour ago" |
گزارش‌های یک ساعت گذشته |
sudo journalctl --no-pager |
چاپ مستقیم خروجی بدون Pager |
sudo journalctl -o short-iso |
نمایش زمان با قالب خواناتر ISO |
sudo journalctl --grep="failed" |
جست‌وجوی الگو در پیام‌ها، در نسخه‌های پشتیبانی‌شده |
بررسی فایل‌های لاگ در مسیر /var/log
برای مشاهده فایل‌ها و پوشه‌های موجود ابتدا این دستور را اجرا کنید:
sudo ls -lah /var/logنام فایل‌ها به توزیع و سرویس‌های نصب‌شده وابسته است. در بعضی سیستم‌های Debian و Ubuntu ممکن است فایل‌هایی مانند /var/log/syslog، /var/log/auth.log و /var/log/kern.log وجود داشته باشند؛ اما اگر گزارش‌گیری متنی یا rsyslog فعال نباشد، برخی از آن‌ها ایجاد نمی‌شوند.
سرویس‌هایی مانند Nginx و Apache نیز معمولاً زیرشاخه اختصاصی دارند. مسیر دقیق باید از پیکربندی همان برنامه بررسی شود.
مشاهده فایل با less
برای مطالعه یک فایل بزرگ بدون بارگذاری کامل آن در ویرایشگر:
sudo less /var/log/syslogدر less می‌توانید با Shift+G به انتهای فایل بروید یا عبارت موردنظر را با /error جست‌وجو کنید.
مشاهده خطوط آخر با tail
برای نمایش ۱۰۰ خط آخر:
sudo tail -n 100 /var/log/auth.logبرای مشاهده زنده خطاهای Nginx:
sudo tail -f /var/log/nginx/error.logاگر فایل یا مسیر وجود نداشت، تنظیمات سرویس و مقصد گزارش‌های آن را بررسی کنید؛ ایجاد دستی یک فایل خالی لزوماً باعث نمی‌شود برنامه در آن گزارش بنویسد.
جست‌وجوی متن با grep
برای پیداکردن پیام‌هایی که شامل عبارت failed هستند:
sudo grep -i "failed" /var/log/auth.logگزینه -i تفاوت حروف کوچک و بزرگ را نادیده می‌گیرد. برای نمایش شماره خط نیز می‌توانید -n را اضافه کنید:
sudo grep -in "failed" /var/log/auth.logگزارش‌های قدیمی ممکن است توسط Logrotate فشرده شده باشند. برای جست‌وجو در فایل‌های فشرده می‌توان از zgrep استفاده کرد:
sudo zgrep -i "failed" /var/log/auth.log*.gzمطالعه بیشتر: Fail2ban برای محافظت از SSH
مدیریت فضای Journal و فایل‌های لاگ
برای مشاهده فضای مصرف‌شده توسط Journal اجرا کنید:
sudo journalctl --disk-usageفایل‌های Journal می‌توانند در /run/log/journal یا /var/log/journal ذخیره شوند. استفاده از مسیر /run معمولاً به نگهداری موقت مربوط است، در حالی که /var/log/journal برای ذخیره پایدار استفاده می‌شود؛ رفتار دقیق با گزینه Storage در تنظیمات journald کنترل می‌شود. freedesktop.org
برای بررسی یکپارچگی فایل‌های Journal:
sudo journalctl --verifyپاکسازی کنترل‌شده گزارش‌های قدیمی
برای حذف Journalهای آرشیوی قدیمی‌تر از یک بازه مشخص می‌توان از Vacuum استفاده کرد:
sudo journalctl --vacuum-time=14dیا سقف تقریبی فضای نگهداری‌شده را تعیین کرد:
sudo journalctl --vacuum-size=1Gاین دستورات می‌توانند گزارش‌های قدیمی را حذف کنند. قبل از اجرا، نیازهای امنیتی، عیب‌یابی و سیاست نگهداری سازمان را بررسی کرده و در صورت لزوم از گزارش‌ها نسخه پشتیبان بگیرید.
برای سیاست دائمی بهتر است گزینه‌هایی مانند SystemMaxUse و MaxRetentionSec در فایل پیکربندی journald بررسی شوند. پس از هر تغییر، صحت پیکربندی و ادامه ثبت رویدادها را کنترل کنید.
تفاوت Vacuum و Logrotate
Vacuum برای فایل‌های آرشیوی Systemd Journal استفاده می‌شود. در مقابل، Logrotate فایل‌های متنی برنامه‌ها را براساس قواعد مشخص جابه‌جا، فشرده و نگهداری می‌کند.
به‌کاربردن Logrotate روی فایل‌های باینری Journal یا حذف مستقیم فایل‌های فعال روش مناسبی نیست. هر سازوکار باید برای نوع گزارش مربوط به خود استفاده شود.
مطالعه بیشتر: چک‌لیست امنیت سرور لینوکس
سناریوهای عملی عیب‌یابی با لاگ‌های لینوکس
سناریوی اول: یک سرویس اجرا نمی‌شود
ابتدا وضعیت سرویس را مشاهده کنید:
sudo systemctl status nginx.serviceسپس پیام‌های همان سرویس در بوت جاری را بررسی کنید:
sudo journalctl -u nginx.service -b -n 100 --no-pagerبه اولین پیام خطا توجه کنید. پیام‌های بعدی ممکن است تنها نتیجه همان خطای اولیه باشند؛ برای مثال، اشغال‌بودن پورت می‌تواند چند خطای وابسته ایجاد کند.
سناریوی دوم: اتصال SSH برقرار نمی‌شود
بسته به نام سرویس، یکی از دستورات زیر را بررسی کنید:
sudo journalctl -u ssh.service --since "30 minutes ago"sudo journalctl -u sshd.service --since "30 minutes ago"در سیستم‌هایی که گزارش متنی احراز هویت دارند، فایل زیر نیز مفید است:
sudo tail -n 100 /var/log/auth.logپیش از تغییر پورت، فایروال یا تنظیمات SSH، نشست فعلی را باز نگه دارید و اتصال جدید را در پنجره‌ای جداگانه آزمایش کنید.
مطالعه بیشتر: آموزش اتصال SSH به سرور لینوکس
سناریوی سوم: سرور پس از Restart مشکل دارد
ابتدا فهرست بوت‌ها را ببینید:
sudo journalctl --list-bootsسپس هشدارها و خطاهای بوت قبلی را بررسی کنید:
sudo journalctl -b -1 -p warningبرای تمرکز بر پیام‌های کرنل:
sudo journalctl -k -b -1اگر بوت قبلی در فهرست نیست، احتمال دارد Journal به‌صورت موقت نگهداری شده باشد یا گزارش‌های قدیمی طبق سیاست فضای ذخیره‌سازی حذف شده باشند.
سناریوی چهارم: وب‌سایت خطای سمت سرور دارد
بررسی را از چند لایه انجام دهید:
- وضعیت وب‌سرور و سرویس برنامه را با
systemctlکنترل کنید. - گزارش سرویس را با
journalctl -uبخوانید. - فایل Error Log وب‌سرور را بررسی کنید.
- لاگ اختصاصی برنامه یا Runtime را ببینید.
- وضعیت دیتابیس، فضای دیسک و حافظه را کنترل کنید.
این رویکرد از تمرکز اشتباه روی یک فایل جلوگیری می‌کند. گاهی وب‌سرور سالم است، اما برنامه به علت قطع ارتباط با دیتابیس پاسخ مناسب نمی‌دهد.
اشتباهات رایج هنگام تحلیل گزارش‌ها
توجه‌نکردن به زمان و منطقه زمانی
اگر زمان رایانه شخصی و سرور متفاوت باشد، ممکن است بازه اشتباهی را بررسی کنید. پیش از تحلیل، خروجی timedatectl و زمان درج‌شده در لاگ را مقایسه کنید.
بررسی‌کردن تنها آخرین فایل
خطای موردنظر ممکن است در فایل چرخش‌یافته مانند syslog.1 یا نسخه فشرده قرار داشته باشد. فایل‌های قدیمی و Journal بوت قبلی را نیز بررسی کنید.
حذف گزارش‌ها برای آزادکردن فضا
حذف دستی ممکن است روند عیب‌یابی را مختل کند یا با فرایند در حال نوشتن تداخل داشته باشد. ابتدا عامل رشد لاگ را پیدا کنید و سپس از ابزار نگهداری مناسب استفاده کنید.
انتشار کامل لاگ در فضای عمومی
گزارش‌ها ممکن است نشانی IP، نام دامنه، نام کاربری، مسیرهای داخلی، پارامتر درخواست یا اطلاعات حساس داشته باشند. فقط بخش مرتبط را با حذف داده‌های محرمانه به اشتراک بگذارید.
نتیجه‌گیری از یک پیام منفرد
یک پیام خطا همیشه علت اصلی نیست. چند دقیقه قبل و بعد از رویداد را بررسی کنید و ارتباط آن را با سرویس‌ها و منابع سیستم بسنجید.
چک‌لیست بررسی لاگ‌های لینوکس
- زمان وقوع مشکل و منطقه زمانی سرور را مشخص کنید.
- نام دقیق سرویس یا برنامه را پیدا کنید.
- وضعیت سرویس را با
systemctl statusببینید. - گزارش بوت جاری را با
journalctl -bبررسی کنید. - خروجی را با
-u،--sinceو-pمحدود کنید. - فایل اختصاصی برنامه را در
/var/logیا تنظیمات برنامه بیابید. - فایل‌های چرخش‌یافته و فشرده را فراموش نکنید.
- اولین خطای مرتبط را از پیام‌های پیامدی جدا کنید.
- فضای دیسک و میزان مصرف Journal را کنترل کنید.
- پیش از پاکسازی، نیاز به نگهداری یا تهیه نسخه پشتیبان را بسنجید.
- اطلاعات حساس را پیش از ارسال گزارش حذف کنید.
- پس از اعمال اصلاحات، لاگ زنده را هنگام تست مشاهده کنید.
جمع بندی
در آموزش بررسی Logهای لینوکس با Journalctl و فایل‌های لاگ دیدیم که journalctl برای تحلیل ساختاریافته رویدادهای systemd، سرویس‌ها و کرنل مناسب است. گزینه‌های -u، -b، --since، -p و -f کمک می‌کنند به‌جای مرور هزاران پیام، فقط رویدادهای مرتبط را ببینید.
فایل‌های موجود در /var/log نیز همچنان اهمیت دارند، به‌خصوص زمانی که وب‌سرور، دیتابیس یا برنامه گزارش اختصاصی تولید می‌کند. برای عیب‌یابی قابل‌اعتماد باید Journal، فایل برنامه، زمان رخداد و وضعیت منابع را کنار هم بررسی کنید.
پاکسازی گزارش‌ها نباید اولین واکنش به کمبود فضا باشد. ابتدا علت رشد لاگ را پیدا کنید، سپس با Vacuum، Logrotate یا تنظیم سیاست نگهداری، مصرف فضا را به‌شکل کنترل‌شده مدیریت کنید.
اگر برای یافتن علت خطا، تنظیم نگهداری لاگ یا پایش سرویس‌های سرور به همراهی فنی نیاز دارید، می‌توانید با شرکت تجارت الکترونیک نوژن تماس بگیرید و سرویس‌های زیرساختی یا مشاوره متناسب با وضعیت پروژه را بررسی کنید.
سؤالات متداول
۱. تفاوت Journalctl با فایل syslog چیست؟
journalctl اطلاعات جمع‌آوری‌شده توسط systemd-journald را نمایش می‌دهد و امکان فیلتر ساختاریافته دارد. syslog یک فایل متنی است که وجود و محتوای آن به توزیع و پیکربندی سرویس ثبت گزارش بستگی دارد.
۲. چگونه لاگ یک سرویس خاص را ببینیم؟
از دستور sudo journalctl -u service-name استفاده کنید. نام دقیق واحد را می‌توانید با systemctl status یا فهرست سرویس‌ها پیدا کنید.
۳. چگونه گزارش‌های زنده لینوکس را مشاهده کنیم؟
برای Journal از sudo journalctl -f و برای فایل متنی از sudo tail -f /path/to/log استفاده کنید. برای توقف نمایش زنده، Ctrl+C را فشار دهید.
۴. چرا Journalctl برای کاربر عادی همه گزارش‌ها را نشان نمی‌دهد؟
دسترسی به بعضی گزارش‌های سیستمی محدود است. اجرای دستور با sudo یا عضویت کنترل‌شده در گروه‌های مرتبط ممکن است لازم باشد؛ سطح دسترسی را بدون بررسی امنیتی گسترش ندهید.
۵. چگونه لاگ‌های قبل از Restart را ببینیم؟
ابتدا journalctl --list-boots را اجرا کنید و سپس با journalctl -b -1 گزارش بوت قبلی را ببینید. این اطلاعات فقط زمانی موجود است که گزارش‌های آن بوت همچنان نگهداری شده باشند.
۶. آیا حذف فایل‌های داخل /var/log امن است؟
حذف مستقیم فایل‌های فعال توصیه نمی‌شود. ابتدا سرویس مالک فایل و سیاست Logrotate را شناسایی کنید و در صورت نیاز از روش رسمی همان سرویس برای پاکسازی یا چرخش گزارش‌ها استفاده کنید.
۷. چرا فایل /var/log/syslog روی سرور وجود ندارد؟
ممکن است توزیع یا پیکربندی سرور فقط از Journal استفاده کند، rsyslog نصب یا فعال نباشد، یا گزارش‌ها در مسیر دیگری ذخیره شوند. ابتدا journalctl و تنظیمات سیستم گزارش‌گیری را بررسی کنید.