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

فایل‌های Log در یک سرور لینوکسی می‌توانند به‌مرور زمان بسیار بزرگ شوند. اگر سرویسی دائماً اطلاعاتی مانند Requestها، Errorها یا Eventهای سیستم را ثبت کند، ممکن است یک فایل Log طی چند روز یا چند هفته چندین گیگابایت فضا اشغال کند.

ابزار Linux logrotate برای مدیریت همین وضعیت طراحی شده است. logrotate می‌تواند فایل‌های Log را به‌صورت خودکار:

Rotate کند.
نسخه‌های قدیمی را نگهداری یا حذف کند.
Logهای قدیمی را فشرده کند.
فایل Log جدید ایجاد کند.
بر اساس زمان یا حجم فایل Rotation انجام دهد.
بعد از Rotation یک Command یا Script اجرا کند.

طبق Manual رسمی، logrotate برای مدیریت تعداد زیادی فایل Log و انجام خودکار Rotation، فشرده‌سازی و حذف Logهای قدیمی طراحی شده است.

در این مقاله ساختار تنظیمات logrotate، مقادیر مهم، روش ساخت Rule سفارشی و نحوه تست تنظیمات را بررسی می‌کنیم.

Log Rotation چیست؟

فرض کنید Application زیر فایل:

/var/log/myapp/app.log

را ایجاد می‌کند.

بعد از مدتی حجم فایل ممکن است به چند گیگابایت برسد.

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

app.log
app.log.1
app.log.2.gz
app.log.3.gz
app.log.4.gz

در این ساختار:

app.log

فایل فعال است.

نسخه قبلی:

app.log.1

و نسخه‌های قدیمی‌تر ممکن است فشرده شده باشند:

app.log.2.gz
app.log.3.gz

بعد از رسیدن به تعداد مشخصی نسخه، قدیمی‌ترین Log حذف می‌شود.

چرا Log Rotation اهمیت دارد؟

بدون Rotation ممکن است Logها به شکل زیر رشد کنند:

500 MB
2 GB
8 GB
20 GB
...

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

/
/var

پر شود.

در این شرایط Serviceها ممکن است دیگر نتوانند فایل ایجاد کنند یا حتی Database و Applicationها با خطا مواجه شوند.

بنابراین Log Rotation فقط برای مرتب نگه داشتن فایل‌ها نیست؛ بخشی از مدیریت فضای Disk سرور محسوب می‌شود.

برای بررسی فضای Disk:

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

و برای پیدا کردن مصرف فضای Directoryها:

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

بررسی نصب بودن logrotate

ابتدا اجرا کنید:

Bash

logrotate --version

Copy

logrotate --version

Bash

اگر نصب باشد، نسخه برنامه نمایش داده می‌شود.

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

همچنین می‌توانید مسیر Binary را بررسی کنید:

Bash

which logrotate

Copy

which logrotate

Bash

معمولاً:

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

نصب logrotate

در بسیاری از Distributionهای Server، logrotate به‌صورت پیش‌فرض نصب است.

در Ubuntu و Debian:

Bash

sudo apt install logrotate

Copy

sudo apt install logrotate

Bash

در AlmaLinux، Rocky Linux و RHEL:

Bash

sudo dnf install logrotate

Copy

sudo dnf install logrotate

Bash

فایل‌های اصلی logrotate

دو مسیر مهم در بیشتر Distributionها عبارت‌اند از:

/etc/logrotate.conf

و:

/etc/logrotate.d/

فایل /etc/logrotate.conf معمولاً تنظیمات عمومی را نگهداری می‌کند. پوشه /etc/logrotate.d/ برای Ruleهای مربوط به Service یا Applicationهای مختلف استفاده می‌شود.

بررسی فایل اصلی logrotate.conf

برای مشاهده:

Bash

sudo less /etc/logrotate.conf

Copy

sudo less /etc/logrotate.conf

Bash

ممکن است محتوا مشابه زیر باشد:

این تنظیمات می‌توانند به‌عنوان Default برای Ruleهای دیگر استفاده شوند.

دستور include

خط:

include /etc/logrotate.d

به logrotate می‌گوید فایل‌های تنظیمات موجود در این Directory را نیز بخواند.

بنابراین معمولاً برای اضافه کردن Rule مربوط به Application جدید، فایل اصلی:

/etc/logrotate.conf

را تغییر نمی‌دهیم.

بهتر است یک فایل جداگانه مانند:

/etc/logrotate.d/myapp

ایجاد کنیم.

این ساختار configuration در توزیع‌های لینوکسی برای جلوگیری از تنظیمات اشتباه در فایل اصلی کانفیگ بسیار متداول است.

مشاهده Ruleهای موجود

اجرا کنید:

Bash

ls -lah /etc/logrotate.d/

Copy

ls -lah /etc/logrotate.d/

Bash

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

apache2
nginx
rsyslog
mysql
php
dnf

محتوای یکی از آن‌ها را می‌توانید بررسی کنید:

Bash

sudo less /etc/logrotate.d/nginx

Copy

sudo less /etc/logrotate.d/nginx

Bash

وجود فایل دقیق به Distribution و Packageهای نصب‌شده بستگی دارد.

ساختار یک Rule ساده

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

Bash

/var/log/myapp/app.log {
    daily<br>    rotate 7
    compress
    missingok
    notifempty
}

Copy

/var/log/myapp/app.log {
    daily<br>    rotate 7
    compress
    missingok
    notifempty
}

Bash

در این مثال daily یعنی Log روزانه بررسی و در صورت رسیدن زمان Rotation چرخانده شود.

rotate 7 یعنی ۷ نسخه قدیمی نگهداری شود.

compress نسخه‌های قدیمی را فشرده می‌کند.

missingok اگر فایل وجود نداشت، Error ایجاد نمی‌کند.

و notifempty از Rotate شدن فایل خالی جلوگیری می‌کند.

Directive مربوط به زمان Rotation

logrotate از چند بازه زمانی چرخش اصلی پشتیبانی می‌کند.

daily
weekly
monthly
yearly

rotate چه کاری انجام می‌دهد؟

تنظیم rotate 7 تعداد نسخه‌های قدیمی نگهداری‌شده را مشخص می‌کند.

مثلاً rotate 4 می‌تواند چیزی شبیه زیر ایجاد کند:

app.log
app.log.1
app.log.2
app.log.3
app.log.4

وقتی Rotation جدید انجام شود، قدیمی‌ترین نسخه حذف می‌شود.

Manual رسمی مشخص می‌کند که rotate 0 باعث می‌شود نسخه قدیمی نگهداری نشود.

فشرده‌سازی Logهای قدیمی با compress

برای کاهش مصرف فضای Disk:

compress

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

در این حالت Logهای قدیمی معمولاً با gzip فشرده می‌شوند:

app.log.2.gz
app.log.3.gz

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

Bash

zless /var/log/myapp/app.log.2.gz

Copy

zless /var/log/myapp/app.log.2.gz

Bash

و برای جستجو:

Bash

zgrep -i "error" /var/log/myapp/app.log.2.gz

Copy

zgrep -i "error" /var/log/myapp/app.log.2.gz

Bash

مقاله مرتبط:

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

delaycompress چیست؟

گاهی بهتر است آخرین Log Rotate شده بلافاصله Compress نشود.

در این حالت delaycompress استفاده می‌شود.

مثلاً:

app.log
app.log.1
app.log.2.gz
app.log.3.gz

نسخه app.log.1 هنوز Compress نشده و در Rotation بعدی فشرده می‌شود.

delaycompress مخصوصاً زمانی مفید است که Application برای مدت کوتاهی هنوز به فایل Rotate شده نیاز داشته باشد.

جلوگیری از Rotate شدن فایل خالی

تنظیم notifempty باعث می‌شود اگر Log حجم صفر داشته باشد، Rotation انجام نشود.

در مقابل حالت Default مربوط به ifempty اجازه Rotation فایل خالی را می‌دهد.

missingok چیست؟

اگر Rule به فایلی اشاره کند که وجود ندارد، logrotate به‌صورت پیش‌فرض می‌تواند Error گزارش کند.

با missingok نبودن فایل مشکلی ایجاد نمی‌کند و logrotate سراغ Rule بعدی می‌رود.

برای Applicationهایی که همیشه Log File را ایجاد نمی‌کنند، این Directive مفید است.

Rotation بر اساس حجم فایل

گاهی نمی‌خواهیم منتظر Daily یا Weekly Rotation بمانیم.

مثلاً اگر Log به 500M رسید، باید Rotate شود.

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

size 500M

مثلاً:

Bash

/var/log/myapp/app.log {
    size 500M
    rotate 5
    compress
}

Copy

/var/log/myapp/app.log {
    size 500M
    rotate 5
    compress
}

Bash

در این حالت فایل زمانی Rotate می‌شود که از حجم تعیین‌شده عبور کند.

Manual رسمی اندازه‌هایی مانند k، M و G را برای Directive size پشتیبانی می‌کند.

تفاوت size و minsize

size عملاً معیار Rotation را بر اساس حجم فایل قرار می‌دهد.

اما minsize 100M معمولاً همراه با یک Interval زمانی استفاده می‌شود.

مثلاً:

daily
minsize 100M

یعنی Log فقط در بازه روزانه Rotation و در صورتی Rotate شود که حداقل 100MB حجم داشته باشد.

maxsize چیست؟

تنظیم maxsize برای شرایطی مفید است که Rotation زمانی داریم، اما نمی‌خواهیم Log پیش از رسیدن زمان بعدی بیش از حد بزرگ شود.

مثلاً:

weekly
maxsize 500M

در این حالت Log طبق برنامه هفتگی Rotate می‌شود، اما اگر قبل از آن از 500MB عبور کند می‌تواند زودتر Rotate شود.

نکته مهم درباره size و Interval زمانی

هنگام استفاده از:

size

در کنار:

daily
weekly
monthly

باید دقت کنید.

طبق Manual، size با Intervalهای زمانی حالت متقابل دارد و ترتیب Directiveها می‌تواند روی نتیجه اثر بگذارد.

اگر هدف شما ترکیب زمان و حجم است، معمولاً minsize یا maxsize انتخاب واضح‌تری است.

ایجاد فایل Log جدید با create

بعد از Rename شدن Log قدیمی، ممکن است Application به فایل جدید نیاز داشته باشد.

تنظیم create فایل جدید ایجاد می‌کند.

مثلاً:

create 0640 myapp adm

به معنی ایجاد Log جدید با:

Permission: 0640
Owner: myapp
Group: adm

است.

نمونه کامل:

Bash

/var/log/myapp/app.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0640 myapp adm
}

Copy

/var/log/myapp/app.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0640 myapp adm
}

Bash

User و Group باید مطابق Application واقعی تنظیم شوند.

چرا Owner و Group فایل Log اهمیت دارند؟

اگر بعد از Rotation فایل جدید با Owner اشتباه ساخته شود، ممکن است Application دیگر نتواند داخل آن Log بنویسد.

برای مثال اگر Service با کاربر myapp اجرا شود اما Log جدید:

root:root

باشد، ممکن است با:

Permission denied

مواجه شود.

برای بررسی فایل فعلی:

Bash

ls -l /var/log/myapp/app.log

Copy

ls -l /var/log/myapp/app.log

Bash

یا:

Bash

stat /var/log/myapp/app.log

Copy

stat /var/log/myapp/app.log

Bash

را اجرا کنید.

قبل از تنظیم create بهتر است Owner و Permission فایل فعلی را بررسی کنید.

چرا بعضی Serviceها بعد از Rotation هنوز در فایل قدیمی می‌نویسند؟

در Linux یک Process می‌تواند File Descriptor فایل Log را باز نگه دارد.

اگر logrotate فایل app.log را Rename کند

app.log.1

Process ممکن است همچنان همان File Descriptor قبلی را داشته باشد.

در نتیجه Logها همچنان وارد app.log.1 می‌شوند.

برای حل این موضوع معمولاً Service باید به شکلی مطلع شود که Log File را دوباره باز کند.

اینجاست که:

postrotate

کاربرد پیدا می‌کند.

اجرای Command بعد از Rotation با postrotate

ساختار:

Bash

postrotate
    COMMAND
endscript

Copy

postrotate
    COMMAND
endscript

Bash

است.

مثلاً:

Bash

/var/log/myapp/app.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0640 myapp adm

    postrotate
        systemctl reload myapp.service >/dev/null 2>&1 || true
    endscript
}

Copy

/var/log/myapp/app.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0640 myapp adm

    postrotate
        systemctl reload myapp.service >/dev/null 2>&1 || true
    endscript
}

Bash

در این مثال بعد از چرخش لاگ،Service مجددا اجرا می‌شود.

اما این Command فقط زمانی صحیح است که Application شما:

systemctl reload

را پشتیبانی کند.

برای هر Service باید روش مناسب Reopen کردن Logها از Documentation همان Application بررسی شود.

prerotate چیست؟

اگر لازم باشد قبل از Rotation یک Command اجرا شود:

Bash

prerotate
    COMMAND
endscript

Copy

prerotate
    COMMAND
endscript

Bash

استفاده می‌شود.

مثلاً ممکن است Application نیاز داشته باشد قبل از Rotation یک عملیات خاص انجام دهد.

در بیشتر Ruleهای معمولی نیازی به prerotate نیست.

sharedscripts چیست؟

فرض کنید Rule چند Log را پوشش می‌دهد:

/var/log/myapp/*.log

بدون تنظیم خاص، Scriptهای postrotate ممکن است برای هر Log اجرا شوند.

با:

sharedscripts

Script یک‌بار برای کل مجموعه اجرا می‌شود.

مثلاً:

Bash

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    sharedscripts

    postrotate
        systemctl reload myapp.service >/dev/null 2>&1 || true
    endscript
}

Copy

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    sharedscripts

    postrotate
        systemctl reload myapp.service >/dev/null 2>&1 || true
    endscript
}

Bash

copytruncate چیست؟

بعضی Applicationها امکان باز کردن مجدد فایل Log بعد از تغییر نام را ندارند.

در این شرایط ممکن است از:

copytruncate

استفاده شود.

مثلاً:

Bash

/var/log/legacy-app/app.log {
    daily
    rotate 7
    compress
    copytruncate
}

Copy

/var/log/legacy-app/app.log {
    daily
    rotate 7
    compress
    copytruncate
}

Bash

در این روش logrotate ابتدا محتویات فایل را Copy کرده و سپس فایل اصلی را خالی می‌کند.

بنابراین Application همچنان همان فایل را باز نگه می‌دارد.

آیا copytruncate بهترین روش است؟

خیر.

copytruncate معمولاً یک روش جایگزین برای Applicationهایی است که نمی‌توانند Log را مجددا باز کنند.

بین مرحله Copy و Truncate یک بازه زمانی کوتاه وجود دارد و ممکن است بعضی Log Entryها در این فاصله از دست بروند. این محدودیت در Manual رسمی logrotate نیز ذکر شده است.

اگر Application از Signal یا Reload برای Reopen کردن Log پشتیبانی می‌کند، معمولاً همان روش انتخاب بهتری است.

نمونه Rule پیشنهادی برای یک Application

فرض کنیم Application این فایل را ایجاد می‌کند:

/var/log/myapp/app.log

یک Rule مناسب می‌تواند باشد:

Bash

/var/log/myapp/app.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp adm

    postrotate
        systemctl reload myapp.service >/dev/null 2>&1 || true
    endscript
}

Copy

/var/log/myapp/app.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp adm

    postrotate
        systemctl reload myapp.service >/dev/null 2>&1 || true
    endscript
}

Bash

این تنظیم:

هر روز Rotation را بررسی می‌کند.
14 نسخه قدیمی نگه می‌دارد.
Logهای قدیمی را Compress می‌کند.
آخرین Log Rotate شده را تا Rotation بعدی Compress نمی‌کند.
فایل خالی را Rotate نمی‌کند.
نبودن Log را Error در نظر نمی‌گیرد.
فایل جدید با Permission مشخص می‌سازد.
بعد از Rotation سرویس را Reload می‌کند.

User، Group و Command مربوط به postrotate باید متناسب با Application واقعی تغییر کنند.

ایجاد فایل تنظیمات سفارشی

فایل جدید ایجاد کنید:

Bash

sudo nano /etc/logrotate.d/myapp

Copy

sudo nano /etc/logrotate.d/myapp

Bash

و مثلاً قرار دهید:

Bash

/var/log/myapp/app.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp adm
}

Copy

/var/log/myapp/app.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp adm
}

Bash

سپس فایل را ذخیره کنید.

قبل از اجرای واقعی تنظیمات را تست کنید

یکی از مهم‌ترین Commandها:

Bash

sudo logrotate -d /etc/logrotate.conf

Copy

sudo logrotate -d /etc/logrotate.conf

Bash

است.

گزینه -d یا --debug تنظیمات را بررسی می‌کند، اما تغییری در Logها ایجاد نمی‌کند و State File را نیز Update نمی‌کند.

این Command قبل از اعمال Rule جدید بسیار مهم است.

تست فقط یک Rule

اگر فقط فایل جدید:

/etc/logrotate.d/myapp

را می‌خواهید بررسی کنید:

Bash

sudo logrotate -d /etc/logrotate.d/myapp

Copy

sudo logrotate -d /etc/logrotate.d/myapp

Bash

این روش برای پیدا کردن Syntax Error بسیار مناسب است.

مشاهده خروجی بیشتر با verbose

برای نمایش جزئیات بیشتر:

Bash

sudo logrotate -v /etc/logrotate.conf

Copy

sudo logrotate -v /etc/logrotate.conf

Bash

یا:

Bash

sudo logrotate -v /etc/logrotate.d/myapp

Copy

sudo logrotate -v /etc/logrotate.d/myapp

Bash

گزینه -v اطلاعات بیشتری درباره logrotate نمایش می‌دهد.

اجرای اجباری Rotation

برای Force کردن Rotation:

Bash

sudo logrotate -f /etc/logrotate.conf

Copy

sudo logrotate -f /etc/logrotate.conf

Bash

یا فقط Rule موردنظر:

Bash

sudo logrotate -f /etc/logrotate.d/myapp

Copy

sudo logrotate -f /etc/logrotate.d/myapp

Bash

گزینه -fباعث می‌شود Rotation انجام شود حتی اگر logrotate تشخیص دهد هنوز زمان آن نرسیده انجام شود.

مراقب logrotate -f باشید

روی Production Server بدون دلیل از logrotate -f برای تمام Configuration استفاده نکنید.

این دستور می‌تواند تمام Ruleهای واجد شرایط را به‌صورت اجباری Rotate کند.

برای تست Rule جدید بهتر است ابتدا logrotate -d و در صورت نیاز فقط همان فایل:

Bash

sudo logrotate -f /etc/logrotate.d/myapp

Copy

sudo logrotate -f /etc/logrotate.d/myapp

Bash

را اجرا کنید.

State File چیست؟

logrotate باید بداند هر Log آخرین بار چه زمانی Rotate شده است.

این اطلاعات معمولاً در State File ذخیره می‌شوند.

مسیر رایج:

/var/lib/logrotate/status

برای مشاهده:

Bash

sudo cat /var/lib/logrotate/status

Copy

sudo cat /var/lib/logrotate/status

Bash

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

"/var/log/syslog" 2026-9-7-0:0:0
"/var/log/nginx/access.log" 2026-9-7-0:0:0

چرا Rule من Rotate نمی‌شود؟

یکی از علت‌های رایج این است که طبق State File هنوز زمان Rotation بعدی نرسیده است.

مثلاً daily است اما همان روز قبلاً اجرا شده.

برای بررسی:

Bash

sudo logrotate -d /etc/logrotate.d/myapp

Copy

sudo logrotate -d /etc/logrotate.d/myapp

Bash

معمولاً logrotate دلیل Rotate نکردن را نمایش می‌دهد.

logrotate چه زمانی اجرا می‌شود؟

خود logrotate یک Daemon دائماً در حال اجرا نیست.

معمولاً یک Scheduler آن را به‌صورت دوره‌ای اجرا می‌کند.

بسته به Distribution ممکن است این کار توسط:

systemd timer

یا:

cron

انجام شود.

Manual فعلی نیز اشاره می‌کند که logrotate معمولاً توسط Cron Job روزانه یا logrotate.timer در سیستم‌های systemd اجرا می‌شود.

بررسی logrotate.timer

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

Bash

systemctl status logrotate.timer

Copy

systemctl status logrotate.timer

Bash

را اجرا کنید.

بررسی Service مربوط به logrotate

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

Bash

systemctl status logrotate.service

Copy

systemctl status logrotate.service

Bash

یا:

Bash

journalctl -u logrotate.service

Copy

journalctl -u logrotate.service

Bash

این Log هنگام عیب‌یابی خطای خود logrotate مفید است.

اگر logrotate.timer وجود نداشت

ممکن است Distribution از Cron استفاده کند.

مسیرهای متداول:

/etc/cron.daily/logrotate

یا Configuration مشابه در Cron هستند.

بررسی کنید:

Bash

ls -l /etc/cron.daily/ | grep logrotate

Copy

ls -l /etc/cron.daily/ | grep logrotate

Bash

بنابراین نبودن logrotate.timer الزاماً به معنی غیرفعال بودن Rotation نیست.

Rotation ساعتی

تنظیم hourly وجود دارد، اما یک نکته مهم دارد. اگر خود logrotate فقط روزی یک بار اجرا شود، قرار دادن hourly داخل Rule باعث اجرای واقعی Rotation در هر ساعت نمی‌شود.

Scheduler نیز باید logrotate را حداقل هر ساعت اجرا کند. Manual رسمی روی همین نکته تأکید می‌کند.

استفاده از Wildcard

می‌توان چند Log را با یک Rule مدیریت کرد:

Bash

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}

Copy

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}

Bash

اما در استفاده از * باید دقت کرد.

اگر Pattern بیش از حد عمومی باشد، ممکن است فایل‌های Rotateشده قبلی نیز Match شوند.

*.log معمولاً از * امن‌تر و دقیق‌تر است.

استفاده از su

اگر Log داخل Directoryای قرار دارد که توسط User غیر Root کنترل می‌شود، تنظیم su می‌تواند اهمیت داشته باشد.

مثلاً:

su myapp myapp

نمونه:

Bash

/home/myapp/logs/*.log {
    daily
    rotate 7
    compress
    su myapp myapp
}

Copy

/home/myapp/logs/*.log {
    daily
    rotate 7
    compress
    su myapp myapp
}

Bash

بررسی فایل‌های Rotate شده

بعد از اجرای Rotation:

Bash

ls -lh /var/log/myapp/

Copy

ls -lh /var/log/myapp/

Bash

را اجرا کنید.

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

app.log
app.log.1
app.log.2.gz
app.log.3.gz

همچنین باید بررسی کنید Application همچنان داخل:

app.log

Log جدید می‌نویسد.

پیدا کردن Processی که فایل Log را باز نگه داشته است

می‌توانید از:

Bash

sudo lsof /var/log/myapp/app.log

Copy

sudo lsof /var/log/myapp/app.log

Bash

یا برای نسخه Rotateشده از:

Bash

sudo lsof /var/log/myapp/app.log.1

Copy

sudo lsof /var/log/myapp/app.log.1

Bash

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

اگر Process همچنان فایل قدیمی را باز نگه داشته باشد، در خروجی مشخص می‌شود.

آیا باید Logهای بزرگ را دستی حذف کنیم؟

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

Bash

rm /var/log/example.log

Copy

rm /var/log/example.log

Bash

باشد.

ابتدا بررسی کنید چرا Log رشد کرده است:

Bash

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

Copy

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

Bash

یا:

Bash

grep -Ei "error|failed|warning" /var/log/example.log | tail

Copy

grep -Ei "error|failed|warning" /var/log/example.log | tail

Bash

ممکن است یک Error دائماً تکرار شود.

در این شرایط logrotate فقط مصرف Disk را مدیریت می‌کند؛ علت اصلی رشد Log همچنان باید برطرف شود.

logrotate جایگزین رفع خطا نیست

فرض کنید Application هر ثانیه این پیام را ثبت می‌کند:

Database connection failed
Database connection failed
Database connection failed

Log Rotation می‌تواند فایل را کوچک‌تر نگه دارد، اما مشکل اصلی یعنی Database Connection همچنان وجود دارد.

بنابراین:

Large log
    ↓
Find repeating message
    ↓
Fix the cause
    ↓
Configure proper rotation

رویکرد صحیح‌تری است.

تفاوت logrotate و systemd Journal Rotation

logrotate عمدتاً برای File Logهای معمولی استفاده می‌شود:

/var/log/nginx/error.log
/var/log/myapp/app.log
/var/log/messages

اما فایل‌های Binary مربوط به:

systemd-journald

با مکانیزم داخلی Journal مدیریت می‌شوند.

برای مثال محدودیت‌های Journal از طریق:

/etc/systemd/journald.conf

کنترل می‌شوند.

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

/var/log/journal/

را نباید مانند یک Log معمولی با Rule سفارشی logrotate مدیریت کرد.

برای آموزش Journal:

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

مثال: نگهداری 30 روز Log

اگر روزانه Rotation انجام شود و:

rotate 30

تنظیم شود:

Bash

/var/log/myapp/app.log {
    daily
    rotate 30
    compress
    missingok
    notifempty
}

Copy

/var/log/myapp/app.log {
    daily
    rotate 30
    compress
    missingok
    notifempty
}

Bash

تقریباً 30 نسخه Daily نگهداری می‌شود.

البته مدت واقعی نگهداری به Frequency اجرای logrotate و شرایط Rotation بستگی دارد.

مثال: Rotation با حجم 1GB

برای Log بسیار پرحجم:

Bash

/var/log/myapp/app.log {
    size 1G
    rotate 5
    compress
    missingok
    notifempty
}

Copy

/var/log/myapp/app.log {
    size 1G
    rotate 5
    compress
    missingok
    notifempty
}

Bash

وقتی Log از 1GB عبور کند و logrotate اجرا شود، امکان Rotation وجود دارد.

نکته مهم این است که logrotate فایل را لحظه‌ای Monitor نمی‌کند.

اگر Scheduler فقط روزی یک‌بار اجرا شود، ممکن است Log مدت زیادی بالاتر از 1GB باقی بماند.

مثال: Daily Rotation با سقف 500MB

برای ترکیب زمان و حداکثر حجم:

Bash

/var/log/myapp/app.log {
    daily
    maxsize 500M
    rotate 14
    compress
    missingok
    notifempty
}

Copy

/var/log/myapp/app.log {
    daily
    maxsize 500M
    rotate 14
    compress
    missingok
    notifempty
}

Bash

این مدل برای Applicationهایی مناسب است که معمولاً Daily Rotation کافی است اما گاهی Log به‌سرعت رشد می‌کند.

خطای Permission denied در logrotate

اگر هنگام اجرا خطایی مشابه:

Permission denied

مشاهده کردید، موارد زیر را بررسی کنید:

Owner و Group فایل Log
Permission Directory
Directive create
Directive su
User مربوط به Application
SELinux در Distributionهای دارای SELinux

فقط با اجرای:

chmod 777

مشکل را حل نکنید.

Permissionهای باز می‌توانند یک ایراد امنیتی ایجاد کنند.

خطای bad rotation count یا Syntax Error

اگر Configuration اشتباه باشد، logrotate -d معمولاً Error را نشان می‌دهد.

مثلاً:

Bash

sudo logrotate -d /etc/logrotate.d/myapp

Copy

sudo logrotate -d /etc/logrotate.d/myapp

Bash

قبل از قرار دادن Rule در Production، همین Command را اجرا کنید.

بعد از تغییر Rule چه کنیم؟

یک Workflow مناسب:

Edit rule
   ↓
logrotate -d
   ↓
Check for errors
   ↓
logrotate -f on that rule if needed
   ↓
Check rotated files
   ↓
Check application still writes logs

Workflow پیشنهادی برای ساخت Rule جدید

فرض کنیم Application فایل زیر را تولید می‌کند:

/var/log/myapp/app.log

1. بررسی فایل

Bash

ls -lh /var/log/myapp/app.log

Copy

ls -lh /var/log/myapp/app.log

Bash

2. بررسی Owner

Bash

stat /var/log/myapp/app.log

Copy

stat /var/log/myapp/app.log

Bash

3. ایجاد Rule

Bash

sudo nano /etc/logrotate.d/myapp

Copy

sudo nano /etc/logrotate.d/myapp

Bash

4. اضافه کردن تنظیمات

Bash

/var/log/myapp/app.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp adm
}

Copy

/var/log/myapp/app.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp adm
}

Bash

5. بررسی Syntax

Bash

sudo logrotate -d /etc/logrotate.d/myapp

Copy

sudo logrotate -d /etc/logrotate.d/myapp

Bash

6. اجرای تست در صورت نیاز

Bash

sudo logrotate -f /etc/logrotate.d/myapp

Copy

sudo logrotate -f /etc/logrotate.d/myapp

Bash

7. بررسی نتیجه

Bash

ls -lh /var/log/myapp/

Copy

ls -lh /var/log/myapp/

Bash

8. بررسی ادامه Logging

Bash

tail -f /var/log/myapp/app.log

Copy

tail -f /var/log/myapp/app.log

Bash

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

حذف دستی Logهای بزرگ بدون بررسی علت

ممکن است Log چند ساعت بعد دوباره پر شود.

استفاده از copytruncate برای همه Applicationها

اگر Application قابلیت Reopen کردن Log دارد، معمولاً روش Rename + Signal/Reload مناسب‌تر است.

تنظیم create با Owner اشتباه

ممکن است Service بعد از Rotation دیگر نتواند Log بنویسد.

استفاده از hourly بدون Scheduler ساعتی

اگر logrotate فقط روزی یک بار اجرا شود، Rule ساعتی نیز روزی یک بار بررسی می‌شود.

استفاده بی‌احتیاط از Wildcard

Rule زیر:

/var/log/myapp/*

می‌تواند فایل‌های بیشتری از چیزی که انتظار دارید Match کند.

اجرای `logrotate -f /etc/logrotate.conf` برای یک تست کوچک

این Command ممکن است Ruleهای متعدد سیستم را Force کند.

بهتر است Rule خودتان را جداگانه تست کنید.

عدم بررسی Log بعد از Rotation

ممکن است Rotation انجام شده باشد ولی Application همچنان داخل فایل قدیمی بنویسد.

استفاده از Permission برابر 777

مشکل Owner یا Access را با Permission ناامن پنهان نکنید.

دستورات سریع logrotate

هدف	دستور
نمایش نسخه	`logrotate --version`
بررسی تنظیمات اصلی	`logrotate -d /etc/logrotate.conf`
بررسی یک Rule	`logrotate -d /etc/logrotate.d/myapp`
اجرای Verbose	`logrotate -v /etc/logrotate.conf`
Force یک Rule	`logrotate -f /etc/logrotate.d/myapp`
مشاهده State	`cat /var/lib/logrotate/status`
بررسی Timer	`systemctl status logrotate.timer`
مشاهده Timerها	`systemctl list-timers \| grep logrotate`
بررسی Service	`systemctl status logrotate.service`
Log اجرای logrotate	`journalctl -u logrotate.service`

مطالعه بیشتر

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

منابع خارجی:

جمع‌بندی

ابزار logrotate برای جلوگیری از رشد بدون کنترل فایل‌های Log و مدیریت نسخه‌های قدیمی استفاده می‌شود.

تنظیمات اصلی معمولاً در:

/etc/logrotate.conf

و Ruleهای مربوط به Applicationها در:

/etc/logrotate.d/

قرار دارند.

یک Rule ساده می‌تواند شامل:

daily
rotate 7
compress
missingok
notifempty

باشد.

قبل از اعمال Rule جدید بهتر است همیشه از:

Bash

logrotate -d

Copy

logrotate -d

Bash

استفاده شود، زیرا Debug Mode بدون تغییر فایل‌ها و State File نتیجه Configuration را بررسی می‌کند.

در صورت نیاز می‌توان یک Rule را با:

Bash

logrotate -f

Copy

logrotate -f

Bash

به‌صورت اجباری اجرا کرد، اما بهتر است این کار فقط روی Configuration موردنظر انجام شود.

همچنین هنگام انتخاب بین:

create + postrotate

و:

copytruncate

باید رفتار Application را در نظر گرفت. copytruncate برای بعضی Applicationهای قدیمی کاربرد دارد، اما به دلیل فاصله کوتاه میان Copy و Truncate احتمال از دست رفتن بخشی از Log وجود دارد.

در نهایت logrotate فقط حجم و نگهداری Log را مدیریت می‌کند؛ اگر یک Error دائماً باعث رشد فایل شود، علت اصلی آن خطا نیز باید جداگانه پیدا و رفع شود.

ش	ی	د	س	چ	پ	ج
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30

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

Log Rotation چیست؟

چرا Log Rotation اهمیت دارد؟

بررسی نصب بودن logrotate

نصب logrotate

فایل‌های اصلی logrotate

بررسی فایل اصلی logrotate.conf

دستور include

مشاهده Ruleهای موجود

ساختار یک Rule ساده

Directive مربوط به زمان Rotation

rotate چه کاری انجام می‌دهد؟

فشرده‌سازی Logهای قدیمی با compress

delaycompress چیست؟

جلوگیری از Rotate شدن فایل خالی

missingok چیست؟

Rotation بر اساس حجم فایل

تفاوت size و minsize

maxsize چیست؟

نکته مهم درباره size و Interval زمانی

ایجاد فایل Log جدید با create

چرا Owner و Group فایل Log اهمیت دارند؟

چرا بعضی Serviceها بعد از Rotation هنوز در فایل قدیمی می‌نویسند؟

اجرای Command بعد از Rotation با postrotate

prerotate چیست؟

sharedscripts چیست؟

copytruncate چیست؟

آیا copytruncate بهترین روش است؟

نمونه Rule پیشنهادی برای یک Application

ایجاد فایل تنظیمات سفارشی

قبل از اجرای واقعی تنظیمات را تست کنید

تست فقط یک Rule

مشاهده خروجی بیشتر با verbose

اجرای اجباری Rotation

مراقب logrotate -f باشید

State File چیست؟

چرا Rule من Rotate نمی‌شود؟

logrotate چه زمانی اجرا می‌شود؟

بررسی logrotate.timer

بررسی Service مربوط به logrotate

اگر logrotate.timer وجود نداشت

Rotation ساعتی

استفاده از Wildcard

استفاده از su

بررسی فایل‌های Rotate شده

پیدا کردن Processی که فایل Log را باز نگه داشته است

آیا باید Logهای بزرگ را دستی حذف کنیم؟

logrotate جایگزین رفع خطا نیست

تفاوت logrotate و systemd Journal Rotation

مثال: نگهداری 30 روز Log

مثال: Rotation با حجم 1GB

مثال: Daily Rotation با سقف 500MB

خطای Permission denied در logrotate

خطای bad rotation count یا Syntax Error

بعد از تغییر Rule چه کنیم؟

Workflow پیشنهادی برای ساخت Rule جدید

1. بررسی فایل

2. بررسی Owner

3. ایجاد Rule

4. اضافه کردن تنظیمات

5. بررسی Syntax

6. اجرای تست در صورت نیاز

7. بررسی نتیجه

8. بررسی ادامه Logging

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

حذف دستی Logهای بزرگ بدون بررسی علت

استفاده از copytruncate برای همه Applicationها

تنظیم create با Owner اشتباه

استفاده از hourly بدون Scheduler ساعتی

استفاده بی‌احتیاط از Wildcard

اجرای logrotate -f /etc/logrotate.conf برای یک تست کوچک

عدم بررسی Log بعد از Rotation

استفاده از Permission برابر 777

دستورات سریع logrotate

مطالعه بیشتر

جمع‌بندی

نظرات خود را بنویسید... لغو پاسخ

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

جدیدترین مقالات

آموزش نصب و راه‌اندازی RustDesk Server با Docker

اجرای `logrotate -f /etc/logrotate.conf` برای یک تست کوچک