Ротација на дневникот на 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 не ја пишува.

Поврзани статии