On 07/18/2011 06:33 PM, Amos Jeffries wrote:
Sounds like the problem is in logrotate. The squid -k rotate with logfile_rotate 0 just closes the logs and reopens whatever is now using the filenames. logrotate is fully responsible for moving the file and creating a new one ready for the squid re-open to shift to. Check for file permissions. Amos
Sorry to jump in here, but I think I just saw the same problem using 3.1.12 on one of my machines.
Logrotate properly moves the file and then calls "/usr/sbin/squid3 -k rotate" to have squid release the file and reopen it. That call returns without error, however squid continues to write to the old file, now /var/log/squid3/access.log.1 and no /var/log/squid3/access.log is ever created. I tried manually running /usr/sbin/squid3 -k rotate as root and that had no effect. If I instead do /etc/init.d/squid3 reload which sends a SIGHUP to the process then the file is released and reopened as expected.
This does not seem to happen 100% of the time, but once a rotate fails, it will continue to fail until squid is restarted or SIGHUP'd. This is a new box that's been up since about July 2nd, and this has happened 3 times that I know of. My logs are rotated hourly. As far as I know, I have never seen this happen on any of my other machines.
If there are any related fixes between 3.1.12 and 3.1.14 I can grab the source and build a newer version. Otherwise is there any logging or debug information I can provide?
Regards, --Will
