From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7.12) Gecko/20050915 Description of problem: Some requests for numeric IP address referenced pages will cause squid child processes to crash. Too many of these and squid will bail out altogether due to 'repeated, frequent failures'. Version-Release number of selected component (if applicable): squid-2.5.STABLE3-6.3E.14 How reproducible: Always Steps to Reproduce: 1. Have a dstdomain acl so that squid performs reverse lookups on numeric IP addresses 2. Send a number of numeric IP address requests to squid Actual Results: 1. Watch child processes die 'due to signal 6' 2. Too many of these and the parent process will die 'Exiting due to repeated, frequent failures' Expected Results: Squid retuns the requests. Additional info: Googling found this thread, which enabled me to workaround the problem (by removing the dstdomain acl for the time being): http://archives.neohapsis.com/archives/linux/debian/2005-q3/0147.html Some detective work was done later in the thread: http://archives.neohapsis.com/archives/linux/debian/2005-q3/0545.html Seems to have been fixed in squid upstream: http://archives.neohapsis.com/archives/linux/debian/2005-q3/0563.html Fixed in one of these squid bugzillas: http://www.squid-cache.org/bugs/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__closed__&product=Squid&content=rfc1035.c
To reproduce, it may be that the host being reverse looked-up must have a PTR record and a CNAME. That would explain why the problem only became apparent to us today (after that specific host was given a CNAME). This may point to the squid bug being: http://www.squid-cache.org/bugs/show_bug.cgi?id=1136 although that refers to multiple PTR records, rather than PTR & CNAME, but I'd imagine that you'd want dstdomain (and other acl DNS lookups) to match CNAMEs as well, so it wouldn't surprise me if this would trigger it as well.
Thanks for your report, it will be fixed in the next RHEL3/4 update. *** This bug has been marked as a duplicate of 165367 ***