perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Moseley <mose...@hank.org>
Subject Re: exit signal Alarm Clock (14)
Date Fri, 03 Mar 2000 04:14:42 GMT
Thanks Doug for taking time to assist!

At 02:47 PM 03/02/00 -0800, Doug MacEachern wrote:
>when you log the RegistryNG request, to you include the url?  i mean, do
>you know which script is triggering the problem?  seeing that would help a
>great deal.

Yes, I do.  There's only one mod_perl (RegistryNG) script running in the
server.

We changed the Apache Timeout from five minutes to four minutes.  Sure
enough, the time between the last request to the RegistryNG script and when
the signal Alarm is caught is the Apache Timeout setting plus a few seconds.

Maybe this is a hint of what's happening:  I log the requests to a separate
log file in my RegistryNG script.  This logging happens within my script --
actually it happens in the read_results() routine shown below before any
output is sent to the browser.

Completed requests are also logged in Apache's access_log file as normal.

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.

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.

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.


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
        [...]



Bill Moseley
mailto:moseley@hank.org

Mime
View raw message