چرخش گزارش Tinyproxy: چرا maxsize 100M سقف سختی نیست
logrotate فقط هنگام اجرا maxsize را بررسی میکند. بسامد بررسی و نحوه بازگشایی دوباره گزارش را همراه با آستانه تنظیم کنید.
ورودی maxsize 100M یک محرک چرخش است، نه سقف زنده روی فایل گزارش Tinyproxy. اگر logrotate روزی یک بار اجرا شود، فایل میتواند پیش از بررسی بعدی از 100 MB فراتر برود.
اگر Tinyproxy مستقیماً در LogFile مینویسد، سیاستی مانند این را در بلوک logrotate موجودش ادغام کنید:
daily
maxsize 100M
rotate 7
compress
delaycompressمسیر درست بلوک نصبشده، مالکیت، مجوزهای create و مدیریت postrotate مخصوص سرویس را حفظ کنید. این قطعه سیاست نگهداری را فراهم میکند، نه یکپارچهسازی کامل سرویس را.
اگر بررسیهای روزانه رشد بیش از حد باقی میگذارند، اجرای مکررتر logrotate را ترتیب دهید. هر اجرا قواعد را ارزیابی میکند، اما لزوماً چرخش نمیدهد. در چرخش مبتنی بر اندازه، rotate 7 یعنی هفت فایل چرخیده و ممکن است کمتر از هفت روز را نشان دهد.
بازگشایی دوباره چرخش را کامل میکند
پس از تغییر نام فایل، Tinyproxy باید گزارش خود را دوباره باز کند. Tinyproxy مستند میکند که SIGUSR1 پیکربندی را دوباره بارگذاری و فایل گزارش را میبندد و دوباره باز میکند، و پیکربندی فیلترها را هم دوباره بارگذاری میکند. یک کمککننده بستهبندیشده را که از پیش کار درست را انجام میدهد حفظ کنید، بهجای حدس زدن سیگنال یا محل فایل PID.
حذف فایل فعال آن بازگشایی را هماهنگ نمیکند. copytruncate از ترتیب تغییر نام و بازگشایی دوباره پرهیز میکند، اما بازه مستندی دارد که در آن دادهها هنگام کپی و برش میتوانند از دست بروند.
اگر پروکسی گزارشها را به Syslog میفرستد، نگهداری را در سیستم گزارشگیری دریافتکننده اعمال کنید، نه با افزودن قاعدهای برای فایلی که Tinyproxy نمینویسد.