You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Beau E. Cox" <be...@beaucox.com> on 2003/03/05 04:21:24 UTC
[mp2] apache/mod_perl starup failure using cvs 09
-------------8<---------- Start Bug Report ------------8<----------
1. Problem Description:
Sorry - is this mason's problem?
Apache does not start using latest mod_perl2 (cvs) when
using a mason startup script.
Failure matrix:
mod_perl version mason version using startup.pl using simple-mason.pl
OK?
--------------------------------------------------------------------------
----
08-source 1.16 yes yes
OK
08-source 1.19 yes yes
OK
09-cvs 1.19 yes yes
FAIL
09-cvs 1.16 yes yes
FAIL
09-cvs 1.19 no-in httpd no mason
OK
09-cvs 1.19 no-in httpd no-in httpd
OK
Apache startup console output:
[Tue Mar 04 16:45:09 2003] [error] Global $r object is not available. Set:
PerlOptions +GlobalRequest
in httpd.conf at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm
line 573.
Compilation failed in require at (eval 3) line 1.
[Tue Mar 04 16:45:09 2003] [error] Can't load Perl file:
/srv/www/conf/simple-mason.pl for server TOMOKO.beaucox.com:0, exiting...
Apache error.log - no entries
Apache rcapache.log - Syntax OK
Apache access.log - no entries
mod_perl/mason (1.19) relevant entries in httpd.conf:
LoadModule perl_module /srv/www/modules/mod_perl.so
PerlRequire "/srv/www/conf/startup.pl"
Alias /perl/ /srv/www/perl/
<Location /perl/>
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
</Location>
PerlRequire "/srv/www/conf/simple-mason.pl"
<FilesMatch "\.html$">
SetHandler perl-script
PerlHandler MyMason::MyApp
</FilesMatch>
/srv/www/conf/startup.pl
use Apache2 ();
use lib qw(/srv/www/perl);
use Apache::compat ();
use ModPerl::Util (); #for CORE::GLOBAL::exit
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::Server ();
use Apache::ServerUtil ();
use Apache::Connection ();
use Apache::Log ();
use Apache::Session ();
use CGI::Cookie ();
use APR::Table ();
use ModPerl::Registry ();
use Apache::Const -compile => ':common';
use APR::Const -compile => ':common';
1;
/srv/www/conf/simple-mason.pl
#!/usr/bin/perl
#
# A basic, functional Mason handler.pl.
#
package MyMason::MyApp;
#
# Setup for mod_perl 2
use Apache2 ();
use Apache::compat ();
# Preload CGI since we are using it for mod_perl 2
use CGI ();
# Bring in Mason with Apache support.
use HTML::Mason::ApacheHandler;
use strict;
#
# List of modules that you want to use within components.
{
package HTML::Mason::Commands;
use Data::Dumper;
}
# Create ApacheHandler object at startup.
my $ah =
HTML::Mason::ApacheHandler->new (
args_method => "CGI",
comp_root => "/srv/www/htdocs",
data_dir => "/srv/www/mason",
error_mode => 'output',
);
#
sub handler
{
my ($r) = @_;
my $status = $ah->handle_request($r);
return $status;
}
#
1;
HTML::Mason::ApacheHandler revelant lines:
my $allowed_params = $class->allowed_params(%defaults, %params);
573: if ( exists $allowed_params->{comp_root} and
my $req = $r || Apache->request ) # DocumentRoot is only available
inside requests
{
$defaults{comp_root} = $req->document_root;
}
2. Used Components and their Configuration:
*** using lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_AP_PREFIX => /usr/local/apache2
MP_GENERATE_XS => 1
MP_INST_APACHE2 => 1
MP_LIBNAME => mod_perl
MP_USE_DSO => 1
MP_USE_STATIC => 1
*** /usr/local/apache2/sbin/httpd -V
Server version: Apache/2.0.44
Server built: Mar 4 2003 14:35:52
Server's Module Magic Number: 20020903:0
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/worker"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/usr/local/apache2"
-D SUEXEC_BIN="/usr/local/apache2/bin/suexec"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="/etc/httpd/mime.types"
-D SERVER_CONFIG_FILE="/etc/httpd/httpd.conf"
*** /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.19, archname=i586-linux-thread-multi
uname='linux amdsim5 2.4.19 #1 wed mar 27 13:57:05 utc 2002 i686 unknown
'
config_args='-ds -e -Dprefix=/usr -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_g
dbm -Duseshrplib=true'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags
='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FIL
E_OFFSET_BITS=64',
optimize='-O3 --pipe',
cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing'
ccversion='', gccversion='3.2', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =''
libpth=/lib /usr/lib /usr/local/lib
libs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil
libc=, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.2.5'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef,
ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i586-linux-thread-multi
/CORE'
cccdlflags='-fPIC', lddlflags='-shared'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Oct 8 2002 16:55:42
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
/usr/lib/perl5/5.8.0/i586-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
.
3. This is the core dump trace: (if you get a core dump):
[CORE TRACE COMES HERE]
This report was generated by t/REPORT on Wed Mar 5 02:57:13 2003 GMT.
-------------8<---------- End Bug Report --------------8<----------
Note: Complete the rest of the details and post this bug report to
dev <at> perl.apache.org. To subscribe to the list send an empty
email to dev-subscribe@perl.apache.org.
RE: [mp2] apache/mod_perl starup failure using cvs 09
Posted by "Beau E. Cox" <be...@beaucox.com>.
Hi Stas -
> -----Original Message-----
> From: Stas Bekman [mailto:stas@stason.org]
> Sent: Tuesday, March 04, 2003 10:45 PM
> To: Beau E. Cox
> Cc: Modperl
> Subject: Re: [mp2] apache/mod_perl starup failure using cvs 09
>
>
> Beau E. Cox wrote:
> > Yea, Stas, I clearly see your reasoning. However, this is not a change
> > of behaviour between mp1 and mp2, but rather between mp2-08 and the
> > current cvs (09).
>
> since 09 > 08, it *is* a change in behaviour between mp1 and mp2
> ;) though
> potentially not the final one.
>
> > I will continue using mp2-08 and talk to the mason
>
> meanwhile you can continue using the lates cvs, but add to the
> beginning of
> your startup to cheat on the latest change:
>
> require Apache::RequestUtil;
> no warnings 'redefine';
> my $sub = *Apache::request{CODE};
> *Apache::request = sub {
> my $r;
> eval { $r = $sub->('Apache'); };
> # warn $@ if $@;
> return $r;
> };
>
> > list - but it seems that folks over there are not too anxious to
> > do much in the line of mp2 development until the 'request' is converted.
>
> You mean Apache::Request?
Yes...
> [...]
Your fix works perfectly - I'm a happy camper. I passed our discussion
to the mason list - will keep you folks informed.
Aloha => Beau;
PS: Have you ever noticed the closer your deadline becomes, the more
things go wrong and the more mistakes you make?
Re: [mp2] apache/mod_perl starup failure using cvs 09
Posted by Stas Bekman <st...@stason.org>.
Beau E. Cox wrote:
> Yea, Stas, I clearly see your reasoning. However, this is not a change
> of behaviour between mp1 and mp2, but rather between mp2-08 and the
> current cvs (09).
since 09 > 08, it *is* a change in behaviour between mp1 and mp2 ;) though
potentially not the final one.
> I will continue using mp2-08 and talk to the mason
meanwhile you can continue using the lates cvs, but add to the beginning of
your startup to cheat on the latest change:
require Apache::RequestUtil;
no warnings 'redefine';
my $sub = *Apache::request{CODE};
*Apache::request = sub {
my $r;
eval { $r = $sub->('Apache'); };
# warn $@ if $@;
return $r;
};
> list - but it seems that folks over there are not too anxious to
> do much in the line of mp2 development until the 'request' is converted.
You mean Apache::Request?
> My only concern is that mp2 and mason will eventually work well
> together - I feel a little like I am caught in the middle ;)
if you don't mind to get frustrated here and there, that's the best position
to learn things ;)
> Please don't spend any more time on this until I get a mason answer.
;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
RE: [mp2] apache/mod_perl starup failure using cvs 09
Posted by "Beau E. Cox" <be...@beaucox.com>.
> -----Original Message-----
> From: Stas Bekman [mailto:stas@stason.org]
> Sent: Tuesday, March 04, 2003 9:23 PM
> To: Beau E. Cox
> Cc: Modperl
> Subject: Re: [mp2] apache/mod_perl starup failure using cvs 09
>
>
> [...]
>
> >>why does Mason needs $r at the server startup? There is no
> >>request object at
> >>the server startup, so it's only fair that mp reports the error.
>
> [...]
>
> > Would you have and suggestions from the mod_perl perspective?
> > I will take this query over to mason if you feel that is where
> > it belongs - but I'll need some further insight into the mod_perl
> > changes.
>
> I see what you mean. In mp1 you relied on Apache->request's not
> being defined
> as a side-effect to test whether you are inside request or not.
>
> I will explain why I've chosen to croak, rather than return 'undef'.
>
> In mp1 Apache->request was either undef (outside of request) or
> $r (during the
> request). You couldn't control that. In mp2 in order to optimize things,
> keeping the global request around is optional. So if you don't
> need it you get
> some speed improvement.
>
> So if the user has the global request setting off and
> Apache->request returns
> undef, he may think that he is not inside the request phases
> (precisely what
> mason does), which is wrong.
>
> Therefore if you still wish to rely on this (which is no longer
> always valid
> under mp2), you can do:
>
> eval { $r = Apache->request}
>
> to trap the croak.
>
> may be you should use something else as a predicate to calling
> Apache->request. For example you could use:
>
> ModPerl::Util::current_callback() to figure out where you are.
> Though it'll
> incur a checking of several options. So perhaps we need a new
> method or may be
> not. Ideas are welcome.
>
> Philippe has agreed with my reasoning when I've suggested the change and
> nobody else has objected (or had any opinion at all), so it went
> in. Since
> nothing is cast is stone (yet) on the mp2 API, you may suggest your
> explanation why it should behave differently if you think that my
> idea is wrong.
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
Yea, Stas, I clearly see your reasoning. However, this is not a change
of behaviour between mp1 and mp2, but rather between mp2-08 and the
current cvs (09). I will continue using mp2-08 and talk to the mason
list - but it seems that folks over there are not too anxious to
do much in the line of mp2 development until the 'request' is converted.
My only concern is that mp2 and mason will eventually work well
together - I feel a little like I am caught in the middle ;)
Please don't spend any more time on this until I get a mason answer.
Aloha => Beau;
Re: [mp2] apache/mod_perl starup failure using cvs 09
Posted by Stas Bekman <st...@stason.org>.
[...]
>>why does Mason needs $r at the server startup? There is no
>>request object at
>>the server startup, so it's only fair that mp reports the error.
[...]
> Good point. However, I seemed to have given you the code of
> mason's ApacheHandler out of context; the snip above is from the
> 'new' method which I use in setting up the mason handler routine:
>
> # Create ApacheHandler object at startup.
> my $ah =
> HTML::Mason::ApacheHandler->new (
> args_method => "CGI",
> comp_root => "/srv/www/htdocs",
> data_dir => "/srv/www/mason",
> error_mode => 'output',
> );
>
> In this trivial case it doesn't seem worthwhile to go to all
> that trouble, but, as in my production server, when working
> with a lot of (possible dynamic) vhosts, it works well.
>
> If the Apache->request (or a request passed as the last -
> odd - parameter to new) is defined, some further processing
> occurs; but at startup, the request is neither expected to
> be there nor needed.
>
> I guess (looking at my result matrix) that some change was made
> to mod_perl to prohibit even querying the presence of
> Apache->request at startup. So now I (and other mason folks)
> must find another way to instantiate handlers.
>
> Would you have and suggestions from the mod_perl perspective?
> I will take this query over to mason if you feel that is where
> it belongs - but I'll need some further insight into the mod_perl
> changes.
I see what you mean. In mp1 you relied on Apache->request's not being defined
as a side-effect to test whether you are inside request or not.
I will explain why I've chosen to croak, rather than return 'undef'.
In mp1 Apache->request was either undef (outside of request) or $r (during the
request). You couldn't control that. In mp2 in order to optimize things,
keeping the global request around is optional. So if you don't need it you get
some speed improvement.
So if the user has the global request setting off and Apache->request returns
undef, he may think that he is not inside the request phases (precisely what
mason does), which is wrong.
Therefore if you still wish to rely on this (which is no longer always valid
under mp2), you can do:
eval { $r = Apache->request}
to trap the croak.
may be you should use something else as a predicate to calling
Apache->request. For example you could use:
ModPerl::Util::current_callback() to figure out where you are. Though it'll
incur a checking of several options. So perhaps we need a new method or may be
not. Ideas are welcome.
Philippe has agreed with my reasoning when I've suggested the change and
nobody else has objected (or had any opinion at all), so it went in. Since
nothing is cast is stone (yet) on the mp2 API, you may suggest your
explanation why it should behave differently if you think that my idea is wrong.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
RE: [mp2] apache/mod_perl starup failure using cvs 09
Posted by "Beau E. Cox" <be...@beaucox.com>.
Hi Stas -
> -----Original Message-----
> From: Stas Bekman [mailto:stas@stason.org]
> Sent: Tuesday, March 04, 2003 6:18 PM
> To: Beau E. Cox
> Cc: Modperl
> Subject: Re: [mp2] apache/mod_perl starup failure using cvs 09
>
>
> Beau E. Cox wrote:
> > -------------8<---------- Start Bug Report ------------8<----------
> > 1. Problem Description:
> >
> > Sorry - is this mason's problem?
> >
> > Apache does not start using latest mod_perl2 (cvs) when
> > using a mason startup script.
> >
> > Failure matrix:
> >
> > mod_perl version mason version using startup.pl using
> simple-mason.pl
> > OK?
> >
> --------------------------------------------------------------------------
> > ----
> > 08-source 1.16 yes yes
> > OK
> > 08-source 1.19 yes yes
> > OK
> > 09-cvs 1.19 yes yes
> > FAIL
> > 09-cvs 1.16 yes yes
> > FAIL
> > 09-cvs 1.19 no-in httpd no mason
> > OK
> > 09-cvs 1.19 no-in httpd no-in httpd
> > OK
> >
> > Apache startup console output:
> >
> > [Tue Mar 04 16:45:09 2003] [error] Global $r object is not
> available. Set:
> > PerlOptions +GlobalRequest
> > in httpd.conf at
> /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm
> > line 573.
> > Compilation failed in require at (eval 3) line 1.
>
> [...]
>
> > HTML::Mason::ApacheHandler revelant lines:
> >
> > my $allowed_params = $class->allowed_params(%defaults, %params);
> >
> > 573: if ( exists $allowed_params->{comp_root} and
> > my $req = $r || Apache->request ) # DocumentRoot is only
> available
>
> why does Mason needs $r at the server startup? There is no
> request object at
> the server startup, so it's only fair that mp reports the error.
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
Good point. However, I seemed to have given you the code of
mason's ApacheHandler out of context; the snip above is from the
'new' method which I use in setting up the mason handler routine:
# Create ApacheHandler object at startup.
my $ah =
HTML::Mason::ApacheHandler->new (
args_method => "CGI",
comp_root => "/srv/www/htdocs",
data_dir => "/srv/www/mason",
error_mode => 'output',
);
In this trivial case it doesn't seem worthwhile to go to all
that trouble, but, as in my production server, when working
with a lot of (possible dynamic) vhosts, it works well.
If the Apache->request (or a request passed as the last -
odd - parameter to new) is defined, some further processing
occurs; but at startup, the request is neither expected to
be there nor needed.
I guess (looking at my result matrix) that some change was made
to mod_perl to prohibit even querying the presence of
Apache->request at startup. So now I (and other mason folks)
must find another way to instantiate handlers.
Would you have and suggestions from the mod_perl perspective?
I will take this query over to mason if you feel that is where
it belongs - but I'll need some further insight into the mod_perl
changes.
Aloha => Beau;
Re: [mp2] apache/mod_perl starup failure using cvs 09
Posted by Stas Bekman <st...@stason.org>.
Beau E. Cox wrote:
> -------------8<---------- Start Bug Report ------------8<----------
> 1. Problem Description:
>
> Sorry - is this mason's problem?
>
> Apache does not start using latest mod_perl2 (cvs) when
> using a mason startup script.
>
> Failure matrix:
>
> mod_perl version mason version using startup.pl using simple-mason.pl
> OK?
> --------------------------------------------------------------------------
> ----
> 08-source 1.16 yes yes
> OK
> 08-source 1.19 yes yes
> OK
> 09-cvs 1.19 yes yes
> FAIL
> 09-cvs 1.16 yes yes
> FAIL
> 09-cvs 1.19 no-in httpd no mason
> OK
> 09-cvs 1.19 no-in httpd no-in httpd
> OK
>
> Apache startup console output:
>
> [Tue Mar 04 16:45:09 2003] [error] Global $r object is not available. Set:
> PerlOptions +GlobalRequest
> in httpd.conf at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm
> line 573.
> Compilation failed in require at (eval 3) line 1.
[...]
> HTML::Mason::ApacheHandler revelant lines:
>
> my $allowed_params = $class->allowed_params(%defaults, %params);
>
> 573: if ( exists $allowed_params->{comp_root} and
> my $req = $r || Apache->request ) # DocumentRoot is only available
why does Mason needs $r at the server startup? There is no request object at
the server startup, so it's only fair that mp reports the error.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com