|
Greetings! We have a couple of instances of squid to service our students’ Internet access. Squid version is: Squid Cache: Version 3.4.10 We use the pre-packaged Red Hat binary from
http://www1.ngtech.co.il/repo/centos/, as linked to from the squid wiki, as the Red Hat version is rather old. The two instances are effectively identical; they are not peered, we just use round-robin DNS. We have a script to sync the configs (barring obvious things like tcp_outgoing_address
and visible_hostname). The first system, I’ll call T1, functions fine and specifically, the logging behaves as expected and like all our other squid instances. We have “log_rotate 30” to keep 30
days of logs, and “squid –k rotate” at midnight via cron. The rotate renumbers all the logs, and squid starts writing in a new access.log. This is our main interest, as data from access logs feeds our quotaing and other usage reports. The second system, T2, has the same setup and while it renumbers the logs all right, it doesn’t close them or start writing in new ones. Thus we see a succession of zero-length
access.logs, eventually access.log.29 reaches over 3 gigabytes, and on the next rotation, the whole lot is thrown away and squid finally starts writing in a fresh access.log, which gradually works its way up to access.log.29 again in the next log_rotate cycle.
This is rather disadvantageous, as most of the time there will not be 30 days worth of data in the logs like on T1.
Other logs such as cache.log and store.log suffer equally the same buildup and wipe. Does anyone have any suggestions? How might we go about debugging this situation? Regards Gary Gary Woodman Enterprise Systems Engineer
Phone: +61 7 4631 1688 | Fax: +61 7 4631 2798 Email:
gary.woodman@xxxxxxxxxx
(CRICOS No: 00244B QLD; 02225M NSW; TEQSA PRV12081) _____________________________________________________________ This email (including any attached files) is confidential and is for the intended recipient(s) only. If you received this email by mistake, please, as a courtesy, tell the sender, then delete this email. The views and opinions are the originator's and do not necessarily reflect those of the University of Southern Queensland. Although all reasonable precautions were taken to ensure that this email contained no viruses at the time it was sent we accept no liability for any losses arising from its receipt. The University of Southern Queensland is a registered provider of education with the Australian Government. (CRICOS Institution Code QLD 00244B / NSW 02225M, TEQSA PRV12081 ) |
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
