סבב יומני 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 נמנע מסידור של שינוי שם ופתיחה מחדש, אך יש לו מרווח מתועד שבו נתונים עלולים ללכת לאיבוד בזמן העתקה וקיטוע.
אם ה-proxy שולח יומנים אל Syslog, החילו את השמירה במערכת היומן המקבלת במקום להוסיף כלל לקובץ ש-Tinyproxy אינו כותב.