perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <>
Subject Re: exit signal Alarm Clock (14)
Date Fri, 03 Mar 2000 23:51:34 GMT
On Thu, 2 Mar 2000, Bill Moseley wrote:
> But, when this problem happens a log entry gets written into my private log
> file written by the script, but NOT into the Apache log file.  So, it looks
> like the request cycle isn't finishing, since there's no entry in the
> access_log.

right, because the child isn't catching the SIGALRM at all, the error
message posted indicates the waitpid() call has returned in the parent,
who logs that message.
> This is confusing.  Since the "exit signal Alarm" is clearly the result of
> Apache setting its alarm( Timeout ), one would think that Apache started a
> new request.  After all, I've set alarm( 0 ) in my script when exiting the
> eval block, so I don't see alarm( Timeout ) being set until the next
> request.  But since Apache is not writing an entry in the access_log it
> would seem like this request never finishes, and Apache does not start a
> new request.

that's not apache's default request alarm handler, when I gave the example
to reproduce the message:
local $SIG{ALRM};
alarm 1;
sleep 2;

the 'local $SIG{ARLM}' sets the SIGALRM handler to NULL.  the default
apache request-time alarm handler is timeout() in http_main.c, which would
produce a message like so:
"[client %s] %s timed out"

> I'm missing something, obviously.
> I thought perhaps logging this in mod_perl.c
>        "mod_perl: restoring SIG%s (%d) handler from: ....
> might show if the SIGALRM handler is being restored correctly.  I'm not
> sure where in the request cycle the handler is restored, though.  I don't
> want to enable all g-level debugging because of the volume written to the
> log file.

what happened to just removing the MP_TRACE_g() ? 

> Again, I'm only messing with $SIG{ALRM} in one place.  Here's the code:
>     eval {
>         local $SIG{__DIE__};
>         local $SIG{ALRM} = sub { die 'Timed out' };
>         alarm 30;
>         # read_results() writes a log entry.
>         $return = read_results( $query, *SEARCH, $start_time );
>         alarm 0;
>     };
>     if ( $@ ) {
>         alarm 0;  # just in case wasn't a timeout that died
>         [...]

hmm, why do you set $SIG{ALRM} here, what's happening in read_results()?
if it's just apache i/o, you should probably just let apache handle that.
apache i/o will also set an alarm(), there could be some sort of conflict
there or race condition, not sure what though.
if there's something else you want to timeout, narrow the $SIG{ALRM} scope
to be around that specific operation.

View raw message