Re: File descriptor leaks; misc queries

webadm@info.cam.ac.uk writes:

>(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?

The '1' comes from 'fdstat_are_n_free()' which I recently changed.
Now it returns 1 or 0 instead of the number of descriptors available.
I didn't realize it was being used for output like that.

Also I hadn't noticed the duplicated 'Number of file descriptors in
use'.

>(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!

Might be related to this:

    #ifdef _SQUID_SOLARIS_
        /* Solaris 2.5 has getrusage() permission bug -- Arjan de Vet */
        enter_suid();
    #endif
    getrusage(RUSAGE_SELF, &rusage);
    #ifdef _SQUID_SOLARIS_
        leave_suid();
    #endif

I'd suggest removing the enter/leave_suid calls and see if that
works.

>(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.

As I'm sure you realize, performing DNS lookups takes time and would
block the Squid process (hence the dnsservers). So the FQDN cache
exists to cache these reverse lookups just like the IP cache exists
to cache the forward lookups.

Because you've given a hostname in the access lists, Squid must check
the FQDN cache for every ICP query received.

But the FQDN cache entries can timeout, or get purged to make room
for other entries. When and ICP query comes in, and there is no
FQDN cache entry for the address, what should Squid do?

Waiting for the reverse lookup to happen is really out of the question.
The ICP reply needs to be sent immediately. Any delay is unacceptable.
Since we can't immediately determine the hostname from the address,
we have to choose to either allow or deny the request. We opt to
be paranoid and deny it.

>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...

I guess its a tradeoff. Do you want your cache to be faster or easier
to maintain? Unfortunately I can't tell you to just disable the
IP and FQDN caches and make resolver calls for every lookup.

Duane W.
Received on Wed Jul 02 1997 - 10:08:54 MDT