Re: [squid-users] Did logrotation code change between 3.1.9 and 3.1.12?

2011-06-04 Thread Amos Jeffries

On 04/06/11 07:17, Rich Rauenzahn wrote:

My logrotating done by logrotated doesn't work anymore...

/var/log/squid/*.log {
 weekly
 rotate 52
 size 100M
 compress
 notifempty
 missingok
 sharedscripts
 postrotate
   # Asks squid to reopen its logs. (logfile_rotate 0 is set in squid.conf)
   # errors redirected to make it silent if squid is not running
   /usr/sbin/squid -k rotate 2/dev/null
   # Wait a little to allow Squid to catch up before the logs is compressed
   sleep 60
 endscript
}

I end up with an access.log that has the wrong number and logrotate
can't compress it.

I think what is happening is logrotate renames access.log to
access.log.0, and then squid -k rotate renames it to access.log.1, and
then logrotate tries to compress logrotate.0, which it now can't find.
  Or something like that.  My uncompressed store.log is actually at .2


store.log i rarely useful. You may want to remove it from the config.



I've worked around it by setting logfile_rotate to 0, but I'm
wondering if this is a recent change with unexpected side effects when
working with logrotate.


That would be the problem. logfile_rotate 0 is a requirement when 
doing log rotation outside of Squid. Such as with logrotate.


It has been that way since Squid-2.6. The mystery is why it worked for 
you before. Or why the squid.conf changed during the upgrade.



Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.12
  Beta testers wanted for 3.2.0.8 and 3.1.12.2


[squid-users] Did logrotation code change between 3.1.9 and 3.1.12?

2011-06-03 Thread Rich Rauenzahn
My logrotating done by logrotated doesn't work anymore...

/var/log/squid/*.log {
weekly
rotate 52
size 100M
compress
notifempty
missingok
sharedscripts
postrotate
  # Asks squid to reopen its logs. (logfile_rotate 0 is set in squid.conf)
  # errors redirected to make it silent if squid is not running
  /usr/sbin/squid -k rotate 2/dev/null
  # Wait a little to allow Squid to catch up before the logs is compressed
  sleep 60
endscript
}

I end up with an access.log that has the wrong number and logrotate
can't compress it.

I think what is happening is logrotate renames access.log to
access.log.0, and then squid -k rotate renames it to access.log.1, and
then logrotate tries to compress logrotate.0, which it now can't find.
 Or something like that.  My uncompressed store.log is actually at .2

I've worked around it by setting logfile_rotate to 0, but I'm
wondering if this is a recent change with unexpected side effects when
working with logrotate.

Rich