Squid 1.NOVM.13 shutdown oddity; max file descriptors

I just tried Squid 1.NOVM.13 on Solaris 2.5 (compiled with Sun's C
compiler), and have hit a repeatable (every time :-) oddity during shutdown
(after a TERM signal).

It seems to work fine until I send it a HUP signal. Then, after e.g.

97/07/10 20:52:40| Waiting 30 seconds for active connections to finish
97/07/10 20:52:41| FD 20 Closing HTTP connection

I get a flood of 30-40 messages like

97/07/10 20:52:41| FD 21 Closing ICP connection

(identical apart from the timestamp), before eventually getting

97/07/10 20:53:11| icpHandleUdp: FD 21 recvfrom: (11) Resource temporarily unavailable
97/07/10 20:53:11| FD 21 Closing ICP connection
97/07/10 20:53:11| Shutting down...

That looks wrong... I tried watching what was happening using truss (the
Solaris 2 system call tracer), but it looks like the only actual system
calls during the flood of Closing ICP connection messages are alternating
writes (to the log) and poll() calls. ["Looks like" because the truss output
only shows the start of the buffer being written, including only the date
and the hours part of the time...]

I thought it might be a result of building squid with -DUSE_POLL for the
first time, after modifying /etc/system to set the hard limit on file
descriptors to 4096 a few hours back, so I tried re-running configure
after re-editing Makefile.in to comment out the setting of USE_POLL, and
then make clean/make all.

That made no difference, and I also noticed that squid was still announcing
that it was using 4096 FDs, even though it wasn't configured to use poll
instead of select - that looks like a bug, or at least something which would
benefit from a compile-time sanity check (i.e. assume max FDs 1024 on
Solaris 2 if USE_POLL isn't set).

I then looked for ways to convince it that it should use only 1024 FDs,
and the only option seemed to be to edit include/autoconf.h manually
(altering the definition of SQUID_MAXFD). Is there any better (and more
reliable, not likely to be lost by re-running configure) way?

That enabled me to try running squid 1.NOVM.13 with the normal limit on file
descriptors, which helped only to the extent that it showed the limit on
file descriptors wasn't relevant to the shutdown problem (i.e. it still
happened with 1024 descriptors).

I have also tried shutting down our live server, running Squid 1.NOVM.11 -
built with max FDs 1024 (when the system was configured with that limit), but
running on the same system with the hard limit set at 4096 FDs, soft limit at
1024, and it does not have the repeated message problem. So that's not purely
due to the change in soft & hard limits on FDs.

So ... has anyone else seen the shutdown problem or got any ideas what is
causing it (and how to fix it - does it actually matter)? And is there any
better way to control the maximum number of file descriptors which Squid
will attempt to use?

                                John Line

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