File descriptor leaks; misc queries

Back in May, a number of people commented that Squid 1.NOVM.10 seemed to
accumulate an ever-increasing number of file descriptors open to zero-length
cache files, and I've also been having trouble with this. I typically see
pairs of them in cachemgr.cgi output, one listed as reading and the other as
writing).

I tried upgrading to 1.NOVM.11 today, in the hope that it might fix the
problem, but it looks as though it is still accumulating old open file
descriptors just as before, though not many yet as it's only be running a
few hours. Highest FD used is 156, but only around 30 actually in use total
(with 1.NOVM.10 I've seen it as high as 500+ overnight at times when there
were fewer than 10 requests per minute). The high FDs are open to zero-length
files last modified a couple of hours ago...

This is on a Sun SPARCstation 20/151 with Solaris 2.5.1, and with Squid
compiled using Sun's ANSI C compiler (since I really don't want to have to
install/maintain gcc if I can avoid it... haven't had any problems with
Sun's compiler).

I have a few additional (unrelated) comments/queries...

(1) The cachemgr.cgi "Cache Information" page for 1.NOVM.11 reports

File descriptor usage for squid:
        Max number of file desc available: 1024
        Number of file descriptors in use: 51
        Largest file desc currently in use: 156
        Number of file desc currently in use: 51
        Available number of file descriptors: 1
        Reserved number of file descriptors: 256

The penultimate line looks very suspicious - what does it really mean when
it says it has 1 file descriptor available?

(2) Again in cachemgr.cgi, is it standard/unavoidable (at least on Solaris
2) that the "Resource usage section for squid" of the Cache Info page lists
all zeroes for the values, with zeroes also in cache.log when it writes
details as squid terminates? E.g.

Resource usage for squid:
        CPU Time: 0 seconds (0 user 0 sys)
        CPU Usage: 0%
        Maximum Resident Size: 0 KB
        Page faults with physical i/o: 0

from cachemgr.cgi, and

CPU Usage: user 0 sys 0
Maximum Resident Size: 0 KB
Page faults with physical i/o: 0

in cache.log. Not very helpful!

(3) I suspect this one is some sort of DNS lookup oddity.

(a) In the cachemgr.cgi "Cache Client List", it often lists IP addresses in
some of the Name: lines, even though the systems concerned have perfectly
good DNS registrations and the names should be available.

(b) In access.log, I get a steady stream of UDP_DENIED entries for requests
from my one ICP neighbour; most requests are OK, but around 3% are logged
with the IP address in the access log instead of the hostname, and are
rejected instead of being processed normally. (ICP queries are only allowed
from that server, configured by hostname.)

I *think* I saw indications that some parent caches (running Squid, details
unknown) similarly rejected a proportion of our ICP queries, presumably for
the same reason.

Any ideas why this is happening?

A solution to (b) would presumably be to use an IP address rather than name
when configuring access control for ICP queries, but that seems like a major
retrograde step when the whole idea of names is that they are relatively
stable, whereas addresses can (and do) change, sometimes quite frequently as
systems are swapped around and different physical systems take over the
services provided via a particular hostname (typically an alias, CNAME).

Since the system running Squid also runs a secondary DNS server for the zone
including the ICP neighbour, and it is configured to use its own nameserver
as first choice, DNS lookup timeouts ought not to be a problem...

                                John Line

-- 
University of Cambridge WWW manager account (usually John Line)
Send general WWW-related enquiries to webmaster@ucs.cam.ac.uk