Squid 2.1.PATCH2 dnsserver, cache.log, and log rotation

With

(a) Squid 2.1.PATCH2 (Solaris 2.6, Sun's C compiler, and with the Squid
clientHandleIMSReply-leak patch and the patch for forgetting parents on
reconfigure), and

(b) "logfile_rotate 0" in squid.conf [though that may not be critical to
the problem, just the way I have it set up,

I've noticed a potentially serious and/or confusing problem with what
happens (actually, what fails to happen) when I do squid -krotate after
renaming the existing log files.

Quite simply, the dnsserver processes (in this case 32 of them - though at
times that limit has been a problem...) keep the old cache.log open. My log
rotation scheme uses symbolic links under the "standard" names to get
timestamped log files (e.g. cache.log.19990308.<hostname>) created in a
simple and in other respects reliable way, which made this particularly
obvious.

Although the logs are normally analysed and then gzip'd the same night, for
a few days recently the gzip-ing was skipped because the analysis runs were
aborting. When I used the lsof command to list details of the open files
in the log directory to check on progress of a multi-day analysis run, it
showed that all the dnsserver processes still had an old
cache.log.<date>.<hostname> open as stderr - specifically, the version of
the file that would have been current when Squid was last started, several
days earlier. Squid itself had correctly re-opened the logs (and as a side
effect, created appropriately date-stamped logs via the symbolic links) each
night.

It looks as though the log rotation signal is either not being passed on to
the dnsserver processes, or being ignored by them.

This is a potentially serious problem, since it could have the effect (for
example) that an enormous log file full of debugging output could be kept
open with the result that it would continue to use space after the file was
deleted. Or if the dnsserver processes may write significant messages to the
logs (rather than passing back failure details and leaving Squid to write
any messages), those may be written to an old file (that may even have been
unlinked from its containing directory by an rm command or as in my case, by
gzip-ing the log) rather than the current log.

If the dnsserver processes may actually use stderr, then they ought to
re-open the logs when they are rotated. If they shouldn't ever write
anything useful to stderr, they should close it at startup. At least, that's
how it looks from what I've seen so far.

                                John Line

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