Apparent incomplete startup of Squid under Linux 2.0.31

Hi, all.

Some background:

I am working on updating myself from 1.1.12 to 1.1.18 and am trying to produce
an RPM for 1.1.18. One of the things I am working on for this is the rotation
of logs using RedHat's logrotate script. Reading through the documentation and
sources implies that sending the squid process a SIGUSR1 will cause it rotate
logs, renaming access.log to access.log.0 f'rinstance. Naturally I'd like to
test this and see what happens.

The problem:

Unfortunately squid on my system seems to be ignoring certain signals (such as
SUGUSR1 and SIGHUP).

I have gone into the sources and added debugging statements here and there, and
this is what I have seen: squid does not appear to be successfully completing
execution of mainInitialize() - it seems to get hung up in the call

     _db_init(Config.Log.log, Config.debugOptions);

on line 555. If I add tracing debug() statements, the one just before this line
is the last to be printed. Running "squid -D -X" (from pristine sources) shows
this (at the end):

 ...
 97/11/17 09:25:24| Processing: 'miss_access allow all'
 97/11/17 09:25:24| aclParseAccessLine: looking for ACL name 'all'
 97/11/17 09:25:24| Processing: 'cache_effective_user nobody nobody'
 97/11/17 09:25:24| Processing: 'dns_testnames internic.net usc.edu
cs.colorado.edu mit.edu yale.edu'
 97/11/17 09:25:24| Processing: 'minimum_direct_hops 4'
 97/11/17 09:25:24| leave_suid: PID 30785 called
 97/11/17 09:25:24| leave_suid: PID 30785 giving up root, becoming 'nobody'

Then nothing. I have waited most of an hour and this is the last thing printed.

Note that the caching of requests *is* working, and squid is usable. It just
does not get as far as the part of the code that sets up the SIGUSR1 and SIGHUP
handlers, so it ignores these signals (as well as apparently not doing whatever
is past this point in mainInitialize()).

I dropped back to 1.1.17 and got the same results, and tried the -X flag on the
1.1.12 that I've been using for months and also got the same results...

Can anyone verify this, or am I missing something obvious?

The only unusual thing that I haven't explored yet is that I am running a
2.0.31 kernel patched to render the stack not executable. Could this be
interfering with squid somehow? I have not yet tried an unpatched kernel to see
if the behavior changes.

Environment:
   Linux 2.0.31 (RH 4.2 + updates)
   Solar Designer's x86 stack-no-execute patch
   Intel 486 DX2/66
   32 Mb RAM
   squid 1.1.12 from RHL
   squid 1.1.17 and 1.1.18 from nlanr ftp site
   gcc-2.7.2.1-2

-------------------------------------------------------------------------
   John Hardin KA7OHZ jhardin@gonzo.wolfenet.com
   PGP fingerprint: A3 0C 5B C2 EF 0D 2C E5 E9 BF C8 33 A7 A9 CE 76
   finger for PGP key Linux: the choice of a Gnu generation
-------------------------------------------------------------------------
   48 days until In The Beginning + The Gathering
Received on Mon Nov 17 1997 - 10:10:02 MST