اگر لاگ‌های systemd-journald فضای دیسک سرور لینوکس را اشغال کرده‌اند، ابتدا با journalctl --disk-usage حجم واقعی Journal را بررسی کنید؛ سپس با journalctl --rotate --vacuum-size=500M فایل‌های آرشیوشده را به‌صورت کنترل‌شده کاهش دهید و برای جلوگیری از تکرار مشکل، محدودیت SystemMaxUse= را در پیکربندی journald تنظیم کنید. این روش برخلاف حذف دستی فایل‌های .journal، سازوکار رسمی systemd را به کار می‌گیرد. مقدار ۵۰۰ مگابایت صرفاً نمونه است؛ برای سرور خود براساس فضای دیسک و نیاز نگهداری لاگ تصمیم بگیرید.
چه زمانی باید Journal را پاک‌سازی کنیم؟
در Ubuntu، Debian و دیگر توزیع‌های مبتنی بر systemd، سرویس systemd-journald پیام‌های Kernel و سرویس‌ها را جمع‌آوری می‌کند. اگر برنامه‌ای دائماً خطا تولید کند یا محدودیت نگهداری متناسب با ظرفیت دیسک نباشد، لاگ‌ها می‌توانند رشد کنند. پیش از حذف تاریخچه، از پیام‌های مهم برای تحلیل حادثه و الزامات نگهداری نسخه پشتیبان بگیرید.
df -hT
df -i
sudo journalctl --disk-usage
sudo du -sh /var/log/journal /run/log/journal 2>/dev/nullاگر df -h پرشدن پارتیشن را نشان می‌دهد ولی Journal کوچک است، علت را در مسیرهای دیگر جست‌وجو کنید. برای تفاوت پرشدن inode و فضای بلوکی، راهنمای رفع خطای No space left on device و بررسی inode مفید است. اگر مصرف اصلی زیر /var/lib/docker است، سراغ مدیریت لاگ Docker و Log Rotation بروید، نه پاک‌کردن Journal.
تفاوت فایل فعال و آرشیوشده در journalctl
دستور --disk-usage حجم مجموع فایل‌های فعال و آرشیوشده Journal را نشان می‌دهد؛ اما گزینه‌های --vacuum-size، --vacuum-time و --vacuum-files فقط فایل‌های آرشیوشده را حذف می‌کنند. بنابراین ممکن است بعد از vacuum، مقدار گزارش‌شده همچنان از سقف تعیین‌شده بیشتر باشد. گزینه --rotate ابتدا فایل‌های فعال را آرشیو می‌کند و فایل فعال تازه‌ای می‌سازد تا پاک‌سازی مؤثرتر شود.
مرحله اول: بررسی لاگ‌های ضروری پیش از پاک‌سازی
قبل از کاهش تاریخچه، خطاهای اخیر سرویس‌ها و Boot فعلی را بخوانید. نام example.service را با سرویس واقعی جایگزین کنید:
sudo journalctl -p err -b --no-pager -n 100
sudo journalctl -u example.service -b --no-pager -n 100
sudo journalctl --list-bootsاگر برای عیب‌یابی خطای systemd به این سوابق نیاز دارید، قبل از پاک‌سازی از آن‌ها خروجی بگیرید. برای نمونه، در راهنمای رفع خطای status=217/USER در systemd بررسی Journal یکی از گام‌های اصلی تشخیص است.
sudo journalctl -b --no-pager -o short-iso > "$HOME/journal-current-boot.txt"
sudo chmod 600 "$HOME/journal-current-boot.txt"فایل خروجی ممکن است اطلاعات حساس مانند IP، نام کاربر یا Token داشته باشد؛ آن را عمومی نکنید و برای آرشیو بلندمدت، ذخیره‌سازی امن و خارج از همان دیسکِ در معرض پرشدن را در نظر بگیرید.
مرحله دوم: پاک‌سازی کنترل‌شده با vacuum-size
برای محدودکردن حجم فایل‌های آرشیوشده به حدود ۵۰۰ مگابایت، ابتدا گردش فایل‌ها را انجام دهید و سپس vacuum کنید:
sudo journalctl --rotate --vacuum-size=500M
sudo journalctl --disk-usage
df -hTاین دستور قدیمی‌ترین فایل‌های آرشیوشده را حذف می‌کند؛ روی فایل‌های فعال، تضمین سقف دقیق ۵۰۰ مگابایت ندارد. اگر نگهداری زمانی مهم‌تر است، می‌توانید به‌جای حجم، فایل‌های آرشیوشده قدیمی‌تر از ۱۴ روز را پاک کنید:
sudo journalctl --rotate --vacuum-time=14daysاین دو سیاست قابل ترکیب‌اند، ولی برای جلوگیری از حذف ناخواسته تاریخچه، قبل از اجرا حداقل مدت نگهداری لازم برای عملیات و امنیت را مشخص کنید. از اجرای rm -rf /var/log/journal یا پاک‌کردن فایل فعال در حال نوشتن خودداری کنید.
مرحله سوم: محدودکردن دائمی حجم Journal
برای Journal پایدار در /var/log/journal، گزینه SystemMaxUse= حداکثر فضای مجاز را تعیین می‌کند. برای Journal موقت در /run/log/journal گزینه متناظر RuntimeMaxUse= است. در سیستم‌های پشتیبانی‌کننده از Drop-in، یک فایل پیکربندی جداگانه بسازید تا تنظیمات بسته اصلی دست‌نخورده بمانند. قبل از اجرای دستور tee بررسی کنید آیا فایل /etc/systemd/journald.conf.d/90-journal-size.conf از قبل وجود دارد؛ این دستور فایل هم‌نام را بازنویسی می‌کند. اگر فایل موجود است، ابتدا از آن نسخه پشتیبان زمان‌دار تهیه کنید و فقط پس از بررسی محتوا و سیاست نگهداری لاگ آن را تغییر دهید.
sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/90-journal-size.conf >/dev/null <<'EOF'
[Journal]
SystemMaxUse=500M
RuntimeMaxUse=200M
EOFاگر systemd-analyze cat-config در نسخه نصب‌شده موجود است، پیکربندی ترکیبی را بررسی کنید:
systemd-analyze cat-config systemd/journald.confسپس در یک بازه نگهداری مناسب، تنظیمات را با راه‌اندازی مجدد journald اعمال کنید. این کار را در سرور حساس با آگاهی از پیامدهای احتمالی وقفه کوتاه در ثبت لاگ انجام دهید:
sudo systemctl restart systemd-journald
sudo systemctl status systemd-journald --no-pagerاین تنظیمات از رشد بی‌رویه در آینده جلوگیری می‌کنند، اما جایگزین تشخیص سرویس پرخطا نیستند. اگر با وجود کاهش Journal هنوز دیسک VPS کوچک است، پس از اندازه‌گیری واقعی مصرف و بررسی فایل‌های کاربردی، می‌توانید ظرفیت ذخیره‌سازی را با پلن‌های سرور مجازی وان‌سرور مقایسه کنید؛ ارتقای سرویس به‌تنهایی علت تولید لاگ غیرعادی را رفع نمی‌کند.
مرحله چهارم: صحت‌سنجی (Verify)
بعد از تغییرات، هم فضای دیسک و هم ثبت‌شدن لاگ‌های جدید را بررسی کنید:
sudo journalctl --disk-usage
df -hT
sudo systemctl is-active systemd-journald
logger -t journal-check "journald verification test"
sudo journalctl -t journal-check --since "5 minutes ago" --no-pagerانتظار می‌رود سرویس active باشد، پیام تست در Journal دیده شود و مصرف فایل‌ها نسبت به قبل کاهش یافته باشد؛ مقدار دقیق آزادشده به فایل‌های فعال، اندازه فایل‌ها و سیاست نگهداری بستگی دارد. اگر پیام تست دیده نشد، تنظیمات و مسیر ذخیره Journal را بررسی کنید و بدون بررسی نتیجه را موفق اعلام نکنید.
Rollback و بازیابی تنظیمات
پاک‌سازی تاریخچه Journal قابل Undo نیست؛ برای همین پیش از آن خروجی ضروری را ذخیره کنید. اما محدودیت حجمی ایجادشده را می‌توان برگرداند:
sudo rm /etc/systemd/journald.conf.d/90-journal-size.conf
sudo systemctl restart systemd-journald
sudo systemctl is-active systemd-journaldدستور حذف بالا فقط برای فایلی است که در همین راهنما ساخته شده؛ اگر پیش‌تر فایلی با همین نام داشته‌اید، باید نسخه پشتیبان آن را بازگردانید، نه اینکه حذفش کنید. بازگرداندن تنظیمات، لاگ‌های حذف‌شده با vacuum را بازیابی نمی‌کند.
خطاهای رایج و نکات امنیتی
- حجم پس از vacuum هنوز زیاد است: فایل‌های فعال در خروجی
--disk-usageمحاسبه می‌شوند؛ از--rotateاستفاده کنید و مقدار واقعی را دوباره بخوانید. - مسیر /var/log/journal وجود ندارد: ممکن است Journal فقط در
/run/log/journalنگهداری شود؛ با تغییرات شتاب‌زده، ذخیره پایدار را ناخواسته فعال نکنید. - فضا آزاد نشد: با
df -hTوduبررسی کنید Journal واقعاً مصرف‌کننده اصلی بوده یا نه؛ فایل‌های بازِ حذف‌شده و سایر لاگ‌ها هم ممکن است مؤثر باشند. - حذف بیش‌ازحد تاریخچه: نگهداری لاگ می‌تواند برای امنیت، ممیزی و تشخیص رخداد ضروری باشد؛ سقف زمانی یا حجمی را مطابق سیاست سازمان تعیین کنید.
مرجع فنی این روش: راهنمای رسمی journalctl و مستندات رسمی journald.conf.