تدوير سجلات Tinyproxy: لماذا لا يمثل maxsize 100M حدًا صارمًا

المدخل maxsize 100M محفّز للتدوير، وليس حدًا فوريًا لحجم ملف سجل Tinyproxy. إذا كان logrotate يعمل مرة واحدة يوميًا، فقد ينمو الملف إلى ما يتجاوز 100 ميغابايت قبل الفحص التالي.

إذا كان Tinyproxy يكتب إلى LogFile مباشرة، فادمج سياسة كهذه في مقطع logrotate الموجود لديه:

daily
maxsize 100M
rotate 7
compress
delaycompress

أبقِ على المسار الصحيح والملكية وأذونات create ومعالجة postrotate الخاصة بالخدمة في المقطع المثبت. هذا المقتطف يوفر سياسة الاحتفاظ، لا التكامل الكامل مع الخدمة.

رتّب تشغيل logrotate بوتيرة أعلى إذا كانت الفحوص اليومية تترك نموًا كبيرًا. كل تشغيل يقيّم القواعد، لكنه لا يدوّر بالضرورة. مع التدوير المبني على الحجم، يعني rotate 7 سبعة ملفات مدوّرة وقد يمثل أقل من سبعة أيام.

إعادة الفتح تُكمل التدوير

بعد إعادة تسمية الملف، يحتاج Tinyproxy إلى إعادة فتح سجله. تُوثّق Tinyproxy أن SIGUSR1 يعيد تحميل الإعدادات ويغلق ملف السجل ويعيد فتحه، كما يعيد تحميل إعدادات التصفية. احتفظ بمساعد مُحزَّم يقوم بالفعل الصحيح بدلًا من تخمين إشارة أو موقع ملف PID.

حذف الملف النشط لا ينسّق عملية إعادة الفتح تلك. يتجنب copytruncate ترتيب إعادة التسمية وإعادة الفتح، لكن له فترة موثّقة يمكن أن تُفقد فيها البيانات أثناء النسخ والاقتطاع.

إذا كان الوسيط يرسل السجلات إلى Syslog، فطبّق الاحتفاظ في نظام السجلات المتلقي بدلًا من إضافة قاعدة لملف لا تكتبه Tinyproxy.