Tinyproxy-loggrotasjon: hvorfor maxsize 100M ikke er en hard grense
logrotate sjekker maxsize bare når det kjører. Sett sjekkfrekvensen og håndteringen av gjenåpning av loggen sammen med terskelen.
En maxsize 100M-oppføring er en rotasjonstrigger, ikke en løpende grense for Tinyproxys loggfil. Hvis logrotate kjører én gang i døgnet, kan filen vokse forbi 100 MB før neste sjekk.
For Tinyproxy som skriver direkte til LogFile, føy en slik policy inn i den eksisterende logrotate-stanzaen:
daily
maxsize 100M
rotate 7
compress
delaycompressBehold den installerte stanzaens riktige sti, eierskap, create-tillatelser og tjenestespesifikk postrotate-håndtering. Dette fragmentet gir oppbevaringspolicyen, ikke den fullstendige tjenesteintegrasjonen.
Sørg for hyppigere logrotate-kjøringer hvis daglige sjekker gir for mye vekst. Hver kjøring vurderer reglene; den roterer ikke nødvendigvis. Med størrelsesstyrt rotasjon betyr rotate 7 sju roterte filer og kan utgjøre færre enn sju dager.
Gjenåpningen fullfører rotasjonen
Etter at filen er gitt nytt navn, må Tinyproxy gjenåpne loggen sin. Tinyproxy dokumenterer SIGUSR1 som å laste konfigurasjonen på nytt og lukke og gjenåpne loggfilen; den laster også filterkonfigurasjonen på nytt. Behold en pakket hjelper som allerede utfører riktig handling i stedet for å gjette et signal eller en PID-filplassering.
Sletting av den aktive filen koordinerer ikke den gjenåpningen. copytruncate unngår ordningen med nytt navn og gjenåpning, men har et dokumentert intervall der data kan gå tapt under kopiering og trunkering.
Hvis proxyen sender logger til Syslog, bruk oppbevaring i det mottakende loggesystemet i stedet for å legge til en regel for en fil Tinyproxy ikke skriver.