Ok, this is a boring issue:
I know very little of the internals of mod_perl. So I'm hoping some of
this makes sense to someone that understands the source code.
A simple Apache::RegistryNG script that generates this error:
$SIG{ALRM} = undef;
alarm 2;
sleep 5;
Note that commenting out the $SIG{ALRM} = undef; line stops the error. So,
there must be a default $SIG{ALRM} handler set at the start of each
mod_perl request that catches $SIG{ALRM} and terminates the request without
killing the child. That is, alarm 2; sleep 5 by itself doesn't cause the
problem.
I also tried a server with only two children, running a script that sets
$SIG{ALRM} = undef, and then running another script that only does an alarm
2; sleep 5; and the child process doesn't die. So it looks like the
$SIG{ALRM} is reset at each request. e.g. I'm not able to easily undef
$SIG{ALRM} and leave it that way. -w would complain, if I did.
I'm using $SIG{ALRM} this way:
eval {
local $SIG{__DIE__};
local $SIG{ALRM} = sub { die 'Timed out' };
alarm $timeout;
[do something that might take too long]
alarm 0;
};
if ( $@ ) {
alarm 0; # just in case wasn't a timeout that died
[...]
}
I mentioned this yesterday: One interesting item is that the "exit signal
Alarm Clock (14)" is almost always 5 minutes and two or three seconds after
the last completed mod_perl request. The Apache Timeout setting is 5
minutes. I find this a bit odd as the Apache Timeout doesn't normally
effect a mod_perl script.
In other words, it seems as if $SIG{ALRM} is at some point undefined at the
same time as the Apache Timeout alarm fires. I'm unclear if this is
happening during the execution of my mod_perl script, while the server is
idle (unlikely), or while serving either mod_cgi or a static document.
Finally, this problem is only seen a few times for every 10,000 or so
requests. So it's some odd combination of events causing it, I'd guess.
Or something really obvious.
The only solution I've come up with so far is to adjust the LogLevel
setting ;)
Bill Moseley
mailto:[EMAIL PROTECTED]
