You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by John Wittkoski <jo...@aol.com> on 2004/04/27 18:01:53 UTC
[MP2] apachectl doesn't run PerlModule code?
-------------8<---------- Start Bug Report ------------8<----------
1. Problem Description:
Running 'apachectl configtest' doesn't seem to run perl code in httpd.conf.
Perhaps I'm doing something wrong here, but according to the docs,
running 'apachectl configtest' should run any perl code in http.conf (or
included files) specified by PerlModule and/or PerlRequire.
This is using apache 2.0.49 and mod_perl 1.99_13 with perl 5.8.3 on OS X
10.3 (NOT using the default apache and perl that Apple supplies, these
were built as myself in a test directory).
For example, if I put the following at the end of an almost generic
httpd.conf (only host and port changed from the default install):
LoadModule perl_module modules/mod_perl.so
PerlModule Not::Here
Running 'apachectl start' fails as expected because Not::Here doesn't exist.
Running 'apachectl configtest' reports 'Syntax OK'.
If I create an actual file for Not::Here, but put invalid perl code in
it, I get similar results.
Did I miss a config step here or is this broken? A similar setup with
Apache 1.3.29 and mod_perl 1.29 works as expected.
Note that mod_perl in all other respects works fine in this same setup,
it is only the behavior of 'apachectl configtest' that seems odd.
2. Used Components and their Configuration:
*** mod_perl version 1.9913
*** using lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_AP_PREFIX => /Users/jpw/web2/httpd
MP_COMPAT_1X => 1
MP_GENERATE_XS => 1
MP_LIBNAME => mod_perl
MP_USE_DSO => 1
MP_USE_STATIC => 1
*** /Users/jpw/web2/httpd/bin/httpd -V
Server version: Apache/2.0.49
Server built: Apr 27 2004 11:22:15
Server's Module Magic Number: 20020903:7
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_POSIXSEM_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="/Users/jpw/web2/httpd"
-D SUEXEC_BIN="/Users/jpw/web2/httpd/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
*** /Users/jpw/web2/perl/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration:
Platform:
osname=darwin, osvers=7.3.0, archname=darwin-2level
uname='darwin gabriel.office.aol.com 7.3.0 darwin kernel version
7.3.0: fri mar 5 14:22:55 pst 2004;
root:xnuxnu-517.3.15.obj~4release_ppc power macintosh powerpc '
config_args='-Dprefix=/Users/jpw/web2/perl -de'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-pipe -fno-common -DPERL_DARWIN -no-cpp-precomp
-fno-strict-aliasing -I/usr/local/include',
optimize='-Os',
cppflags='-no-cpp-precomp -pipe -fno-common -DPERL_DARWIN
-no-cpp-precomp -fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='3.3 20030304 (Apple Computer, Inc. build
1495)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib
libs=-ldbm -ldl -lm -lc
perllibs=-ldl -lm -lc
libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup
-L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under darwin
Compiled at Apr 21 2004 18:36:56
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
/Users/jpw/web2/perl/lib/5.8.3/darwin-2level
/Users/jpw/web2/perl/lib/5.8.3
/Users/jpw/web2/perl/lib/site_perl/5.8.3/darwin-2level
/Users/jpw/web2/perl/lib/site_perl/5.8.3
/Users/jpw/web2/perl/lib/site_perl
.
*** Packages of interest status:
Apache::Request: -
CGI : 3.05
LWP : 5.79
mod_perl : 1.9913
3. This is the core dump trace: (if you get a core dump):
No core trace
This report was generated by t/REPORT on Tue Apr 27 15:28:57 2004 GMT.
-------------8<---------- End Bug Report --------------8<----------
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: PerlModule versus PerlLoadModule
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>What do you mean it has no clear utility, you've just heard John
>>complaining on the users list that 'apachectl configtest' wasn't
>>invoking mod_perl setup. Unless you think that suggesting to use the
>><perl> section hack is the best we can come up with.
>
>
> actually, I think that his expectations are wrong. configtest is for making
> sure that the config is syntactically correct, that a TAKE1 directive has
> only one argument, etc. I don't really think that configtest was meant to
> catch things like invalid perl modules, even if it did in mp1. I don't
> think it catches things like invalid ErrorLog or RewriteLog paths or things
> of that nature either, which could also prevent the server from starting in
> real life, but I'm not sure.
Hmm, that's not a very nice policy, I'd suggest. 'configtest' is there to
verify that once you do 'apachectl restart', your server will actually start.
Apache can only go as far as running the config phase and expects the modules
not to play tricks on it. Sure, the problem could be just as well in the
child_init phase, but still it's nice to have mod_perl DWIM wrgt 'configtest'
and not surprise people with production sites...
>>The only solution I could think of is to add a some hook into config
>>that will check whether we are running under configtest and will force
>>the perl startup at the end of config if it's not running already. These
>>new query status thingies added in 2.0.49 (?) for the
>>starting/restarting may need to be extended to tell us when a
>>'configtest' is running.
>
>
> that's not a bad idea and would be a nice bonus.
Yeah, but I'm not going to do any digging into httpd any time soon. I really
want to get the API finalizing going at full speed, as a first priority. So if
you get a chance to look at it, that would be great.
>>>I had thought about creating some kind of flag (local %ENV or package
>>>variable) that would act as a flag in those circumstances. so a
>>>module could
>>>
>>> die unless $Apache::Module::IsPerlLoadModule;
>>>
>>>or something. I admit, it's a stretch, but some mechanism would be nice.
>>
>>
>>that's wacky. That's why we may need to change the name of that
>>directive, so there will be no confusion.
>
>
> the name of the directive may not have any bearing on this, since there
> would always be the danger of both being used to load modules. PerlModule
> and PerlRequire are pretty much the same, but it's only by convention that
> we use one over the other. this would be a convention as well.
Not quite so. PerlModule == use, PerlRequire == require. So they map 1:1 to
the familiar perl functions. So if can come up with a better non-ambiguous
naming for this new directive that's the best. Doug, who came up with that
name, had put 'XXX: not sure if that's going to stay' and I think I've removed
that XXX some time go.
>>I hope we aren't going to piss off too many folks with these late
>>changes...
>
>
> I highly doubt that people are using directive handlers in mp2 yet. almost
> nobody used them in mp1 so they're still a pretty obscure feature. I seem
> to be the exception on both fronts :)
I know, I was talking in general (e.g. me going to completely change the
socket IO API), and probably more to come in the next few weeks, as I'm going
to try and make a consistent *perlish* api, and use the C'ish API only when
it's really needed, or we have a similar function in perl which is not quite
perlish (e.g. read()/sysread() which put the data into the argument)
> besides, the point of not having a 2.0 release yet is so we can create the
> best stable API we can ;) seriously, without doing something in this area,
> lots of mp1 people will be without a feature they used to rely on short of
> sticking in <Perl> sections.
Sure.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: PerlModule versus PerlLoadModule
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> What do you mean it has no clear utility, you've just heard John
> complaining on the users list that 'apachectl configtest' wasn't
> invoking mod_perl setup. Unless you think that suggesting to use the
> <perl> section hack is the best we can come up with.
actually, I think that his expectations are wrong. configtest is for making
sure that the config is syntactically correct, that a TAKE1 directive has
only one argument, etc. I don't really think that configtest was meant to
catch things like invalid perl modules, even if it did in mp1. I don't
think it catches things like invalid ErrorLog or RewriteLog paths or things
of that nature either, which could also prevent the server from starting in
real life, but I'm not sure.
>
> The only solution I could think of is to add a some hook into config
> that will check whether we are running under configtest and will force
> the perl startup at the end of config if it's not running already. These
> new query status thingies added in 2.0.49 (?) for the
> starting/restarting may need to be extended to tell us when a
> 'configtest' is running.
that's not a bad idea and would be a nice bonus.
>> I had thought about creating some kind of flag (local %ENV or package
>> variable) that would act as a flag in those circumstances. so a
>> module could
>>
>> die unless $Apache::Module::IsPerlLoadModule;
>>
>> or something. I admit, it's a stretch, but some mechanism would be nice.
>
>
> that's wacky. That's why we may need to change the name of that
> directive, so there will be no confusion.
the name of the directive may not have any bearing on this, since there
would always be the danger of both being used to load modules. PerlModule
and PerlRequire are pretty much the same, but it's only by convention that
we use one over the other. this would be a convention as well.
> I hope we aren't going to piss off too many folks with these late
> changes...
I highly doubt that people are using directive handlers in mp2 yet. almost
nobody used them in mp1 so they're still a pretty obscure feature. I seem
to be the exception on both fronts :)
besides, the point of not having a 2.0 release yet is so we can create the
best stable API we can ;) seriously, without doing something in this area,
lots of mp1 people will be without a feature they used to rely on short of
sticking in <Perl> sections.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: PerlModule versus PerlLoadModule
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[...]
>>Meaning that you need
>>to document that one needs to do:
>>
>> PerlLoadModule Foo
>>
>>which is just as well, could be documented as:
>>
>> PerlStartNow
>> PerlModule Foo
>>
>>especially if we are going to add PerlStartNow anyway (are we?).
>
>
> well, something about that strikes me as dangerous. PerlStartNow has no
> clear utility. that is, everyone knows what <Perl> sections do, and
> hopefully we could explain that PerlLoadModule would be for modules that
> need to run init code. but PerlStartNow is kind of floating in the aether -
> starting the interpreter on demand has no clear benefit or activity
> associated with it.
What do you mean it has no clear utility, you've just heard John complaining
on the users list that 'apachectl configtest' wasn't invoking mod_perl setup.
Unless you think that suggesting to use the <perl> section hack is the best we
can come up with.
The only solution I could think of is to add a some hook into config that will
check whether we are running under configtest and will force the perl startup
at the end of config if it's not running already. These new query status
thingies added in 2.0.49 (?) for the starting/restarting may need to be
extended to tell us when a 'configtest' is running.
>>But I
>>don't have any hard preferences. All I was saying is that if you remove
>>the magickness of PerlLoadModule with regards to add_module, then the
>>only remaining difference between PerlModule and PerlLoadModule is that
>>the latter starts perl.
>
>
> that's true, except that we can document it in terms of using it for modules
> that need to interact with config-time activities, such as loading
> directives into the server before other modules (like mod_authn_basic) get
> the chance to start.
I guess so. In which case the mnemonics of this directive's name are now not
as clear.
>>And you can't really ensure that a user won't
>>invoke your module via PerlModule.
>
>
> I had thought about creating some kind of flag (local %ENV or package
> variable) that would act as a flag in those circumstances. so a module could
>
> die unless $Apache::Module::IsPerlLoadModule;
>
> or something. I admit, it's a stretch, but some mechanism would be nice.
that's wacky. That's why we may need to change the name of that directive, so
there will be no confusion.
>>Sure. I don't think we have any remaining disagreements here.
>
>
> whew! :)
>
> ok, I'll start working up a patch that will take directive handlers to the
> next level. keep the ideas coming and we'll get something together that's
> spiffy :)
I hope we aren't going to piss off too many folks with these late changes...
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: PerlModule versus PerlLoadModule
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> That's exactly what will happen if a user will use PerlModule instead of
> PerlLoadModule at the moment. It'll silently fail.
yes. but in some circumstances the failure might not be silent - directive
handlers would fail because httpd would croak, for example. but you're
right, there is a danger.
> Meaning that you need
> to document that one needs to do:
>
> PerlLoadModule Foo
>
> which is just as well, could be documented as:
>
> PerlStartNow
> PerlModule Foo
>
> especially if we are going to add PerlStartNow anyway (are we?).
well, something about that strikes me as dangerous. PerlStartNow has no
clear utility. that is, everyone knows what <Perl> sections do, and
hopefully we could explain that PerlLoadModule would be for modules that
need to run init code. but PerlStartNow is kind of floating in the aether -
starting the interpreter on demand has no clear benefit or activity
associated with it.
> But I
> don't have any hard preferences. All I was saying is that if you remove
> the magickness of PerlLoadModule with regards to add_module, then the
> only remaining difference between PerlModule and PerlLoadModule is that
> the latter starts perl.
that's true, except that we can document it in terms of using it for modules
that need to interact with config-time activities, such as loading
directives into the server before other modules (like mod_authn_basic) get
the chance to start.
> And you can't really ensure that a user won't
> invoke your module via PerlModule.
I had thought about creating some kind of flag (local %ENV or package
variable) that would act as a flag in those circumstances. so a module could
die unless $Apache::Module::IsPerlLoadModule;
or something. I admit, it's a stretch, but some mechanism would be nice.
> Sure. I don't think we have any remaining disagreements here.
whew! :)
ok, I'll start working up a patch that will take directive handlers to the
next level. keep the ideas coming and we'll get something together that's
spiffy :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: PerlModule versus PerlLoadModule
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>In which case why having two directives, if they do the same thing? Drop
>>PerlLoadModule completely and have a new directive that will start the
>>interpreter on demand, add the new API to Apache::Module. Won't that
>>solve the problem?
>
>
> not really. the issue that started this discussion aside, if I have a
> module that implements directive handlers I would need two directives
> instead of one. for the new issue (module init code) the code simply
> wouldn't run if the interpreter weren't started, possibly failing silently.
That's exactly what will happen if a user will use PerlModule instead of
PerlLoadModule at the moment. It'll silently fail. Meaning that you need to
document that one needs to do:
PerlLoadModule Foo
which is just as well, could be documented as:
PerlStartNow
PerlModule Foo
especially if we are going to add PerlStartNow anyway (are we?). But I don't
have any hard preferences. All I was saying is that if you remove the
magickness of PerlLoadModule with regards to add_module, then the only
remaining difference between PerlModule and PerlLoadModule is that the latter
starts perl. And you can't really ensure that a user won't invoke your module
via PerlModule.
> really, I think we're looking at the whole issue differently. I want code
> to run during config. this happens to require an interpreter. you keep
> focusing on starting the interpreter early or "on demand" which I think is
> the wrong way to look at it. again, it's not early if I require it, which
> directive handlers (and other things) currently do.
Sure, if you want it that way then be it.
>>It's not invalid if you want to do more things than just set -Tw. Take a
>>look at my reply to John:
>
>
>>I fail to see how is that invalid.
>
>
> I understand the issues. but if you're saying that giving me an interpreter
> before you're ready invalidates things like PerlSwitches, I was merely
> pointing out that the ability exists already, so it's not like I'm asking
> for something that mucks up existing strategies. the muck exists and is
> possible already with the existing directive structure.
Sure. I don't think we have any remaining disagreements here.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: PerlModule versus PerlLoadModule
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>> continuing from modperl@
>>
>>
>>> In this thread you were trying to make
>>> PerlLoadModule do what it wasn't designed for.
>>
>>
>>
>> that's an oversimplification and somewhat belittling.
>>
>> PerlLoadModule does a few things:
>>
>> - starts up an interpreter
>
>
> That's a side effect, not the design goal.
no, it's a requirement for directive handlers which are XS free.
>> use Apache::Module ();
>> our @APACHE_MODULE_COMMANDS = (...);
>> Apache::Module->add(__PACKAGE__);
>>
>> or something similar. the added call really isn't all that much, as
>> directive handlers are still much, much simpler than they were in mp1.
>
>
> If you do that, then it's the best to remove the magical
> @APACHE_MODULE_COMMANDS name, just pass an array as an argument? The
> special name is needed only when things happen behind the scenes.
great idea. cool.
>
>> the
>> benefit is that PerlLoadModule is more of a LoadModule counterpart -
>> not all
>> C modules have directive declarations, you know :)
>
>
> In which case why having two directives, if they do the same thing? Drop
> PerlLoadModule completely and have a new directive that will start the
> interpreter on demand, add the new API to Apache::Module. Won't that
> solve the problem?
not really. the issue that started this discussion aside, if I have a
module that implements directive handlers I would need two directives
instead of one. for the new issue (module init code) the code simply
wouldn't run if the interpreter weren't started, possibly failing silently.
really, I think we're looking at the whole issue differently. I want code
to run during config. this happens to require an interpreter. you keep
focusing on starting the interpreter early or "on demand" which I think is
the wrong way to look at it. again, it's not early if I require it, which
directive handlers (and other things) currently do.
> It's not invalid if you want to do more things than just set -Tw. Take a
> look at my reply to John:
> I fail to see how is that invalid.
I understand the issues. but if you're saying that giving me an interpreter
before you're ready invalidates things like PerlSwitches, I was merely
pointing out that the ability exists already, so it's not like I'm asking
for something that mucks up existing strategies. the muck exists and is
possible already with the existing directive structure.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: PerlModule versus PerlLoadModule
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> continuing from modperl@
>
>
>>In this thread you were trying to make
>>PerlLoadModule do what it wasn't designed for.
>
>
> that's an oversimplification and somewhat belittling.
>
> PerlLoadModule does a few things:
>
> - starts up an interpreter
That's a side effect, not the design goal.
> - requires a module, thus running module init code
> - inserts code into the Apache module list (another oversimplification :)
>
> to me, this all boils down to a module that requires init code to run during
> config time. in other words, directive handlers are merely a special case
> of what many modules want or require - code to be run at config time.
>
> if we abstracted out that last point and offered an interface into
> modperl_module_add() this would be exactly like all the stuff I want to do.
> modules that used ap_register_provider() (the example I gave in the
> previous thread) and modperl_module_add() would both have the same
> requirements - they would need to be loaded using PerlLoadModule to ensure
> that their init code ran at config time.
>
> so, my point is that PerlLoadModule is designed poorly - lots of modules
> would like to be able to take advantage of the first two points, with fewer
> taking advantage of the last. if the directive handler interface were a bit
> more generic then PerlLoadModule would have the effect I think it should,
> namely give modules a way to ensure that their init code is run at config time.
>
> I guess that means that I'm also considering a redesign of the directive
> handler interface:
>
> PerlLoadModule My::Module
>
> where My::Module has:
>
> use Apache::Module ();
> our @APACHE_MODULE_COMMANDS = (...);
> Apache::Module->add(__PACKAGE__);
>
> or something similar. the added call really isn't all that much, as
> directive handlers are still much, much simpler than they were in mp1.
If you do that, then it's the best to remove the magical
@APACHE_MODULE_COMMANDS name, just pass an array as an argument? The special
name is needed only when things happen behind the scenes.
> the
> benefit is that PerlLoadModule is more of a LoadModule counterpart - not all
> C modules have directive declarations, you know :)
In which case why having two directives, if they do the same thing? Drop
PerlLoadModule completely and have a new directive that will start the
interpreter on demand, add the new API to Apache::Module. Won't that solve the
problem?
>>And since you've mention this thread, it goes:
>>
>>"BTW, one other reason for postponing startup is to be able to specify
>>PerlSwitches anywhere in the config file and PerlInterp* directives as well
>>(as Doug has reminded me). Something that won't work after perl was
>>started."
>>
>>So if you force an early startup, you can not use PerlSwitches and you
>>better remove the whole feature, since it becomes useless.
>
>
> mp1 has the same issue - use <Perl> sections before a PerlTaintCheck
> directive and the PerlTaintCheck directive is silently ignored (IIRC :).
> and PerlLoadModule as it exists currently has the same effect anyway. so
> really, this is an invalid argument as the situation exists already outside
> of wanting to change things around a but.
It's not invalid if you want to do more things than just set -Tw. Take a look
at my reply to John:
<quote>
A more significant reason is that PerlSwitches must be set before perl starts.
If you want to set PerlSwitches inside vhosts, and perl has already been
started, you are out of luck. Here is why you want this feature:
http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlSwitches_
http://perl.apache.org/docs/2.0/user/config/config.html#C_Clone_
http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_
With a <perl> hack section, or a new directive to do just that - force the
startup of the interpreter, you have a complete control over things. If we
start early by default, then you're out of control.
</quote>
I fail to see how is that invalid.
So if you want to use some new directives in httpd.conf and set PerlSwitches
at the same time, you really can't (even as it's now).
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
PerlModule versus PerlLoadModule
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
continuing from modperl@
> In this thread you were trying to make
> PerlLoadModule do what it wasn't designed for.
that's an oversimplification and somewhat belittling.
PerlLoadModule does a few things:
- starts up an interpreter
- requires a module, thus running module init code
- inserts code into the Apache module list (another oversimplification :)
to me, this all boils down to a module that requires init code to run during
config time. in other words, directive handlers are merely a special case
of what many modules want or require - code to be run at config time.
if we abstracted out that last point and offered an interface into
modperl_module_add() this would be exactly like all the stuff I want to do.
modules that used ap_register_provider() (the example I gave in the
previous thread) and modperl_module_add() would both have the same
requirements - they would need to be loaded using PerlLoadModule to ensure
that their init code ran at config time.
so, my point is that PerlLoadModule is designed poorly - lots of modules
would like to be able to take advantage of the first two points, with fewer
taking advantage of the last. if the directive handler interface were a bit
more generic then PerlLoadModule would have the effect I think it should,
namely give modules a way to ensure that their init code is run at config time.
I guess that means that I'm also considering a redesign of the directive
handler interface:
PerlLoadModule My::Module
where My::Module has:
use Apache::Module ();
our @APACHE_MODULE_COMMANDS = (...);
Apache::Module->add(__PACKAGE__);
or something similar. the added call really isn't all that much, as
directive handlers are still much, much simpler than they were in mp1. the
benefit is that PerlLoadModule is more of a LoadModule counterpart - not all
C modules have directive declarations, you know :)
>
> And since you've mention this thread, it goes:
>
> "BTW, one other reason for postponing startup is to be able to specify
> PerlSwitches anywhere in the config file and PerlInterp* directives as well
> (as Doug has reminded me). Something that won't work after perl was
> started."
>
> So if you force an early startup, you can not use PerlSwitches and you
> better remove the whole feature, since it becomes useless.
mp1 has the same issue - use <Perl> sections before a PerlTaintCheck
directive and the PerlTaintCheck directive is silently ignored (IIRC :).
and PerlLoadModule as it exists currently has the same effect anyway. so
really, this is an invalid argument as the situation exists already outside
of wanting to change things around a but.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [MP2] apachectl doesn't run PerlModule code?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Let's not mix things, Geoff.
fine. I've moved to dev@.
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [MP2] apachectl doesn't run PerlModule code?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>The main rationale I think is because of the restart, loading is twice
>>as slow. So the more things you can postpone until after restart the
>>faster your server will start.
>
>
> I suppose that's a consideration. but I hate to not have functionality just
> because it takes the server a while to start. for most production
> environments, which are behind some kind of load-balancer, a slow start or
> restart really doesn't matter. large, complex applications already can take
> minutes to start.
>
>
>>It should be very easy to match the mp1 behavior. You already suggested
>>that an empty <Perl>\n<Perl> section will trigger an early startup.
>
>
> that's really not an option. if I create a module that relies on code
> running during startup I don't want to say in the docs 'oh, and you have to
> fake a <Perl> section to get the module working properly.'
>
>
>>And
>>we could introduce a special directive for that, to make it less
>>hackish.
>
>
> we've discussed this at length before:
>
> http://marc.theaimsgroup.com/?t=105343767200008&r=1&w=2
>
> after re-reading the entire thread, I'm pretty sure we are each on the same
> side of the argument as we were then. I know I am :)
Let's not mix things, Geoff. In this thread you were trying to make
PerlLoadModule do what it wasn't designed for. This current thread is talking
about an early startup in general. While related, they aren't the same things.
If we have turned PerlLoadModule into what you were trying to make it, it
still doesn't solve John's problem.
And since you've mention this thread, it goes:
"BTW, one other reason for postponing startup is to be able to specify
PerlSwitches anywhere in the config file and PerlInterp* directives as well
(as Doug has reminded me). Something that won't work after perl was started."
So if you force an early startup, you can not use PerlSwitches and you better
remove the whole feature, since it becomes useless.
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [MP2] apachectl doesn't run PerlModule code?
Posted by Stas Bekman <st...@stason.org>.
John Wittkoski wrote:
>
> Geoffrey Young wrote on 4/27/04, 1:56 PM:
> >
> > > The main rationale I think is because of the restart, loading is twice
> > > as slow. So the more things you can postpone until after restart the
> > > faster your server will start.
> >
> > I suppose that's a consideration. but I hate to not have
> > functionality just
> > because it takes the server a while to start. for most production
> > environments, which are behind some kind of load-balancer, a slow
> > start or
> > restart really doesn't matter. large, complex applications already
> > can take
> > minutes to start.
>
>
> I can see how startup time (or restart time) could be important in many
> situations. However, when running "apachectl configtest", aren't you
> running a new httpd process, separate from the real server? In that case
> startup time should not be critical - why not load the interpreter? When
> doing a real server start (or restart), the code gets executed as
> expected (without using the <Perl></Perl> force trigger), so when the
> interpreter is loaded isn't an issue (as far as my original problem is
> concerned). It is only with "configtest" do I see this behavior. Is it
> that mod_perl cannot easily distinguish between a "normal" start and a
> "test" start?
Please take a look at my reply to Geoff, the startup time is not the only
reason. A more significant reason is that PerlSwitches must be set before perl
starts. If you want to set PerlSwitches inside vhosts, and perl has already
been started, you are out of luck. Here is why you want this feature:
http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlSwitches_
http://perl.apache.org/docs/2.0/user/config/config.html#C_Clone_
http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_
With a <perl> hack section, or a new directive to do just that - force the
startup of the interpreter, you have a complete control over things. If we
start early by default, then you're out of control.
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [MP2] apachectl doesn't run PerlModule code?
Posted by Stas Bekman <st...@stason.org>.
John Wittkoski wrote:
> Another note, just FYI:
>
> To trigger the interpreter to load, putting this in httpd.conf (or in an
> included file) doesn't work:
>
> <Perl>
> </Perl>
>
> But this does:
>
> <Perl>
> # foo
> </Perl>
>
> Obviously something wants a non-null data in the Perl section before
> firing off the interpreter.
Yup thanks, that has been documented already:
http://perl.apache.org/docs/2.0/user/porting/compat.html#Server_Startup
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [MP2] apachectl doesn't run PerlModule code?
Posted by John Wittkoski <jo...@aol.com>.
Another note, just FYI:
To trigger the interpreter to load, putting this in httpd.conf (or in an
included file) doesn't work:
<Perl>
</Perl>
But this does:
<Perl>
# foo
</Perl>
Obviously something wants a non-null data in the Perl section before
firing off the interpreter.
--John
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [MP2] apachectl doesn't run PerlModule code?
Posted by John Wittkoski <jo...@aol.com>.
Geoffrey Young wrote on 4/27/04, 1:56 PM:
>
> > The main rationale I think is because of the restart, loading is twice
> > as slow. So the more things you can postpone until after restart the
> > faster your server will start.
>
> I suppose that's a consideration. but I hate to not have
> functionality just
> because it takes the server a while to start. for most production
> environments, which are behind some kind of load-balancer, a slow
> start or
> restart really doesn't matter. large, complex applications already
> can take
> minutes to start.
I can see how startup time (or restart time) could be important in many
situations. However, when running "apachectl configtest", aren't you
running a new httpd process, separate from the real server? In that case
startup time should not be critical - why not load the interpreter? When
doing a real server start (or restart), the code gets executed as
expected (without using the <Perl></Perl> force trigger), so when the
interpreter is loaded isn't an issue (as far as my original problem is
concerned). It is only with "configtest" do I see this behavior. Is it
that mod_perl cannot easily distinguish between a "normal" start and a
"test" start?
Thanks,
--John
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [MP2] apachectl doesn't run PerlModule code?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> The main rationale I think is because of the restart, loading is twice
> as slow. So the more things you can postpone until after restart the
> faster your server will start.
I suppose that's a consideration. but I hate to not have functionality just
because it takes the server a while to start. for most production
environments, which are behind some kind of load-balancer, a slow start or
restart really doesn't matter. large, complex applications already can take
minutes to start.
>
> It should be very easy to match the mp1 behavior. You already suggested
> that an empty <Perl>\n<Perl> section will trigger an early startup.
that's really not an option. if I create a module that relies on code
running during startup I don't want to say in the docs 'oh, and you have to
fake a <Perl> section to get the module working properly.'
> And
> we could introduce a special directive for that, to make it less
> hackish.
we've discussed this at length before:
http://marc.theaimsgroup.com/?t=105343767200008&r=1&w=2
after re-reading the entire thread, I'm pretty sure we are each on the same
side of the argument as we were then. I know I am :)
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [MP2] apachectl doesn't run PerlModule code?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>For example, if I put the following at the end of an almost generic
>>httpd.conf (only host and port changed from the default install):
>>
>> LoadModule perl_module modules/mod_perl.so
>> PerlModule Not::Here
>>
>>Running 'apachectl start' fails as expected because Not::Here doesn't exist.
>>
>>Running 'apachectl configtest' reports 'Syntax OK'.
>
>
> I think you're running into the "perl module loading is deferred" thingy
> that is the default behavior in mp2. if you stuck a valid <Perl> section
> above it you would probably see configtest fail, since an interpreter would
> be loaded.
>
> basically, PerlModule no longer runs module code at the time that the
> PerlModule directive is parsed unless an interpreter is already resident in
> the configuration process. I'm not entirely certain as to the rationale for
> this, but I think it has something to do with startup times, overhead,
> interpreter pools, etc.
The main rationale I think is because of the restart, loading is twice as
slow. So the more things you can postpone until after restart the faster your
server will start.
It should be very easy to match the mp1 behavior. You already suggested that
an empty <Perl>\n<Perl> section will trigger an early startup. And we could
introduce a special directive for that, to make it less hackish. I'm not sure
what's the best default behavior. This is something that we can always fix
later. So let's see whether it is good or not when more people move in.
But yes, I'll document that in the porting/compat doc now. Thanks for
suggestion, John.
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [MP2] apachectl doesn't run PerlModule code?
Posted by John Wittkoski <jo...@aol.com>.
Geoffrey Young wrote on 4/27/04, 12:22 PM:
> I think you're running into the "perl module loading is deferred" thingy
> that is the default behavior in mp2. if you stuck a valid <Perl> section
> above it you would probably see configtest fail, since an interpreter
> would
> be loaded.
>
> basically, PerlModule no longer runs module code at the time that the
> PerlModule directive is parsed unless an interpreter is already
> resident in
> the configuration process. I'm not entirely certain as to the
> rationale for
> this, but I think it has something to do with startup times, overhead,
> interpreter pools, etc.
>
> now, I have problems with this sometimes - there are quite a few places
> where I want PerlModule to run code, and _not_ doing so presents a vary
> large problem. in fact, people who depend on the mp1 behavior currently
> have no recourse except to force in an interpreter via <Perl>. well,
> in mp2
> we also have PerlLoadModule, which always runs module code on loading,
> except that it is exclusively for the use of directive handlers (another
> mistake I think, but not a battle I was able to win).
>
> HTH
>
> --Geoff
Geoff,
Thanks for the hint, that fixed things. If I put ANY <Perl> </Perl>
section in the config - even if there is nothing in that block - it
triggers the interpreter to start, and the rest of the PerlModule and
PerlRequire statements in the config are executed.
I guess the docs I was looking at that mentioned PerlModule/PerlRequire
get executed with 'configtest' were for 1.x, although this is behavior
that I would expect to be similar between both versions. I don't know
how often people run into this - perhaps a note could be added to the
"Migrating to 2.0" pages on perl.apache.org about the difference in
bahavior.
In my case, I am not concerned about startup time or overhead, but being
able to use 'apachectl configtest' to let the module validate it's own
config file (which is separate from httpd.conf) before restarting apache
to make sure the whole thing can survive a restart.
Thanks,
--John
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [MP2] apachectl doesn't run PerlModule code?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> For example, if I put the following at the end of an almost generic
> httpd.conf (only host and port changed from the default install):
>
> LoadModule perl_module modules/mod_perl.so
> PerlModule Not::Here
>
> Running 'apachectl start' fails as expected because Not::Here doesn't exist.
>
> Running 'apachectl configtest' reports 'Syntax OK'.
I think you're running into the "perl module loading is deferred" thingy
that is the default behavior in mp2. if you stuck a valid <Perl> section
above it you would probably see configtest fail, since an interpreter would
be loaded.
basically, PerlModule no longer runs module code at the time that the
PerlModule directive is parsed unless an interpreter is already resident in
the configuration process. I'm not entirely certain as to the rationale for
this, but I think it has something to do with startup times, overhead,
interpreter pools, etc.
now, I have problems with this sometimes - there are quite a few places
where I want PerlModule to run code, and _not_ doing so presents a vary
large problem. in fact, people who depend on the mp1 behavior currently
have no recourse except to force in an interpreter via <Perl>. well, in mp2
we also have PerlLoadModule, which always runs module code on loading,
except that it is exclusively for the use of directive handlers (another
mistake I think, but not a battle I was able to win).
HTH
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html