Sometimes stdout ends in the error_log!
I have a problem thats bothering me. Sometimes one of the httpd childs start to send normal output to the error_log, and browsers report 'document contains no data'. Normally only one child does it, and the others respond normally, meaning that the user sees sporadic failure. Is this a known problem? Is it in apache or in mod_perl? I don't recall having seen anything on the mod_perl list, and dejanews didn't turn up anything for apache. It seems to happen after restarts, so I have taken to the habit of stopping the server completely and starting from scratch. Not a good solution, but better than serving docs to the error_log. It is not a very busy server, so high load is not a likely source of the problem. I am not running the latest and greatest, but neither very old versions: Perl version 5.00503 for Apache/1.3.11 (Unix) PHP/3.0.14 mod_perl/1.21 Statically linked mod_perl (php is a DSO). I also use HTML::Mason 0.81 on one vhost. Server is a PC, Linux 2.2.13 from slackware 7, 128Mb ram. -- René Seindal ([EMAIL PROTECTED]) http://www.seindal.dk/rene/
Re: Apache::StatINC.pm
Ken Williams wrote: > > [EMAIL PROTECTED] (René Seindal) wrote: > >I just got bitten by the problem of Apache::StatINC not reloading > >modules found through an element of @INC, which is no longer present > >when StatINC runs. > [...] > >A small change to StatINC solves the problem. Since StatINC could stat > >the file, the file is accessible, only not through require(). The fix is > >to change StatINC to load the file instead of the module, which is > >achieved with this little patch (against 1.06 from mod_perl 1.21, but > >nothing seems to have changed): > > I've been in favor of this change for a long time. I last suggested it here: > http://forum.swarthmore.edu/epigone/modperl/stexlorblay > I'm still in favor, perhaps this time it will happen? The only problem seems > to happen when people use relative pathnames to source files, which is a bad > idea under mod_perl anyway. If both ways cause problems, then the right solution is to leave it to the user. Apache::StatINC already uses dir_config() to adjust its behaviour according to user preferences, so adding another configuration variable can't be a problem. Current behaviour would be the default and setting a variable with PerlSetVar would change it to what we have proposed. I'll make a patch relative to the cvs version if there is any change such a change would make it into the distribution. It will inspect a PerlSetVar parameter, and use require() or do() accordingly - couldn't be simpler. -- René Seindal ([EMAIL PROTECTED]) http://www.seindal.dk/rene/
Apache::StatINC.pm
I just got bitten by the problem of Apache::StatINC not reloading
modules found through an element of @INC, which is no longer present
when StatINC runs. This happens when a module adds a private directory
to @INC, which is then reset by mod_perl after the request is done.
This problem is mentioned in the mod_perl guide at
porting.html#Using_Apache_StatINC_for_the_De
If you load a module, say Data.om, from . then $INC{'Data.pm'} eq
'Data.pm', and StatINC won't be able to find it. This is easily solved
with
use Cwd;
use lib Cwd::cwd;
which puts the current working directory in the path. Make the obvious
adjustments if you use a subdirectory. Now the local modules will load
from $CWD (full path) and not from . (relative path), and %INC will hold
the absolute path name of locally found modules.
The next problem is that Apache::StatINC won't reload your modules
anyway. StatINC scans %INC and stats all the files, and when one is out
of date, it does a require() on the module name. This fails, because the
directory of the module is no longer in the path. Yet StatINC knows the
filename, because it could do a stat on it.
A small change to StatINC solves the problem. Since StatINC could stat
the file, the file is accessible, only not through require(). The fix is
to change StatINC to load the file instead of the module, which is
achieved with this little patch (against 1.06 from mod_perl 1.21, but
nothing seems to have changed):
***
*** 25,32
my $class = Apache::Symbol::file2class($key);
$class->Apache::Symbol::undef_functions( undef, 1 );
}
! delete $INC{$key};
! require $key;
warn "Apache::StatINC: process $$ reloading $key\n"
if $DEBUG;
}
--- 25,33
my $class = Apache::Symbol::file2class($key);
$class->Apache::Symbol::undef_functions( undef, 1 );
}
! # delete $INC{$key};
! # require $key;
! do $INC{$key};
warn "Apache::StatINC: process $$ reloading $key\n"
if $DEBUG;
}
Presumably one could do a 'do $file' as well, which would be a bit
faster.
--
René Seindal ([EMAIL PROTECTED]) http://www.seindal.dk/rene/
