You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Kee Hinckley <na...@somewhere.com> on 2002/03/22 17:17:16 UTC
PerlModule hell - questions and comments
I'm posting this to the modperl list as well as embperl in hope that
someone there can answer some questions.
I've been trying to get the latest Embperl beta working on MacOS X
(although apparently the problems I'm experience occur on some other
operating systems as well). Embperl 2.0b7, Apache 1.3.23, mod_perl
1.26. Gerald's going on a well-deserved vacation starting about now,
but I think some of these questions are not specific to Embperl.
1. *Why* are the apache config files executed twice (completely with
loading and unloading all the modules)? At least one module even has
code to check and only do an initialization the second time it is
called!
2. Why doesn't mod_perl force the Perl interpreter to restart when
that happens, so that the initialization the second time is identical
to the first time?
3. Why does mod_perl only delete $INC entries if there is a <perl>
directive in the config file?
4. Why doesn't deleting the $INC entry force the second Require
(executed as a result of the PerlModule command) to actually load the
perl library again?
Here's what I believe is *supposed* to happen with Embperl.
mod_perl is loaded
PerlModule Embperl causes Embperl.pm to load, which calls an init
function, which calls ap_add_module which causes Embperl to be
installed as a full-fledged apache module (complete with added syntax
for the config file).
Here's what *actually* happens.
On the first pass through the config file, everything happens exactly
as described above.
On the second pass (more on that in a minute) through the config
file, mod_perl does a Require of Embperl, Embperl.pm has already been
loaded, so it isn't executed, the init call doesn't get called, the
module doesn't get loaded, everything breaks.
Quite by accident I discovered that if I put the following code in my
config file, things got a little bit better.
<perl>
</perl>
Now on the second pass through the config file, mod_perl calls delete
$INC{'Embperl.pm'} and the require loads the file again. At least in
theory.
That actually got me to the point where Embperl runs. But oddly, the
config file extensions don't get parsed (e.g. I can't use any of
Embperl's extensions to the config file syntax). The module isn't
completely registered.
So, to make a long story short. I had to do a number of things to
make this work. Some are Embperl specific, some I think relate to
problems with the mod_perl architecture.
1. In Embperl's Apache cleanup handler, always unload embperl.c, even
if mod_perl isn't loaded dynamically.
2. In Embperl's init routine, *always* call ap_add_module, even if we
weren't called from the Embperl.pm startup.
3. In the config file, explicitly call Embperl::Init in <perl></perl>
tags. You have to do this because on the second pass through the
config file it isn't called at the right times. It will get
correctly called when PerlHandler Embperl is found, but that's too
late for some config file directives.
That all sounds confusing, here's a trace (of the working version) to
clear it up (hah!). First, here's my <perl> section in the config
file.
<Perl>
print STDERR "**** Before 1\n";
print STDERR '#', $INC{"Embperl.pm"}, "#\n";
print STDERR "**** Before 2\n";
</Perl>
PerlModule Embperl
<Perl>
print STDERR "**** After 1\n";
print STDERR '#', $INC{"Embperl.pm"}, "#\n";
Embperl::Init();
print STDERR "**** After 2\n";
</Perl>
and the trace
$ MOD_PERL_TRACE=all sudo /usr/local/apache/bin/httpd -X
perl_parse args: '/dev/null' ...allocating perl interpreter...ok
constructing perl interpreter...ok
ok
running perl interpreter...ok
mod_perl: 0 END blocks encountered during server startup
loading perl module 'Apache'...loading perl module
'Apache::Constants::Exports'...ok
ok
loading perl module 'Tie::IxHash'...ok
Okay, cool we've loaded and started perl. Now we check and see if
$INC has been set for Embperl.
**** Before 1
##
**** Before 2
perl_section: </Files>
perl_section: </Location>
perl_section: </Files>
perl_section: </Location>
perl_section: </Directory>
perl_section: </Directory>
perl_section: </VirtualHost>
loading perl module 'Apache'...ok
And now we do the PerlModule Embperl. It correctly calls the init
functions, which correctly call add_module.
PerlModule: arg='Embperl'
loading perl module 'Embperl'...
## called embperl_INit (0x3C40EC)
## 1 calling add_module
## 2 calling add_module
ok
bootstrapping <Perl> sections: arg=Embperl, keys=8
loading perl module 'Apache'...ok
loading perl module 'Tie::IxHash'...ok
perl_section: </Files>
perl_section: </Location>
perl_section: </Files>
perl_section: </Location>
perl_section: </Directory>
perl_section: </Directory>
perl_section: </VirtualHost>
mod_perl: delete $INC{'Embperl.pm'} (klen=10)
Look ma, it just deleted the $INC entry so if we require it again it
will load again. Maybe.
loading perl module 'Apache'...ok
loading perl module 'Tie::IxHash'...ok
**** After 1
##
Now I call the init function from my code. This time around it won't
do anything because it was already properly loaded.
## called embperl_INit (0x0)
Caling addmodule anyway
## 1 calling add_module
## not calling add_module
**** After 2
perl_section: </Files>
perl_section: </Location>
perl_section: </Files>
perl_section: </Location>
perl_section: </Directory>
perl_section: </Directory>
perl_section: </VirtualHost>
PerlHandler gets called. And it calls the real module init routine
for the first time. That also calls Embperl::Init, but with
different arguments. Previously this was the only time that
add_module would get called. Note that this is too late in the
process if we want to be able to process config directives after the
PerlModule call, not after the PerlHandler call.
init `PerlHandler' stack
perl_cmd_push_handlers: @PerlHandler, 'Embperl'
pushing `Embperl' into `PerlHandler' handlers
ap_init_modules: embperl.c->init(0xD3308, 0xD32E0)
embperl_apacheInit(0xD3308, 0xD32E0)
## called embperl_INit (0x0)
Caling addmodule anyway
## 1 calling add_module
## not calling add_module
ap_init_modules: mod_perl.c->init(0xD3308, 0xD32E0)
loading perl module 'Apache'...ok
perl_startup: perl aleady running...ok
ap_init_modules: mod_unique_id.c->init(0xD3308, 0xD32E0)
ap_init_modules: mod_proxy.c->init(0xD3308, 0xD32E0)
ap_init_modules: mod_rewrite.c->init(0xD3308, 0xD32E0)
ap_init_modules: mod_status.c->init(0xD3308, 0xD32E0)
ap_init_modules: mod_mime.c->init(0xD3308, 0xD32E0)
ap_init_modules: mod_mime_magic.c->init(0xD3308, 0xD32E0)
ap_init_modules: mod_log_config.c->init(0xD3308, 0xD32E0)
Okay that was fun. Now let's run the entire config file again. (!!!!?)
loading perl module 'Apache'...ok
cleanup_sv: SvREFCNT(0x345238)==1
loading perl module 'Apache'...ok
loading perl module 'Apache'...ok
loading perl module 'Tie::IxHash'...ok
Nothing in $INC, nothing up my sleeve.
**** Before 1
##
**** Before 2
perl_section: </Files>
perl_section: </Location>
perl_section: </Files>
perl_section: </Location>
perl_section: </Directory>
perl_section: </Directory>
perl_section: </VirtualHost>
loading perl module 'Apache'...ok
Ah, time to load our perl module. Should load fine because there was
nothing in $INC, right?
PerlModule: arg='Embperl'
loading perl module 'Embperl'...ok
Hey! It wasn't reloaded! If it had been, we would have seen the
init() call there.
bootstrapping <Perl> sections: arg=Embperl, keys=8
loading perl module 'Apache'...ok
loading perl module 'Tie::IxHash'...ok
perl_section: </Files>
perl_section: </Location>
perl_section: </Files>
perl_section: </Location>
perl_section: </Directory>
perl_section: </Directory>
perl_section: </VirtualHost>
loading perl module 'Apache'...ok
loading perl module 'Tie::IxHash'...ok
**** After 1
#/Library/Perl/darwin/Embperl.pm#
## called embperl_INit (0x0)
Caling addmodule anyway
## 1 calling add_module
## 2 calling add_module
**** After 2
And there we confirm it. Note that nobody called delete $INC this
time around, and when we call add_module, it adds it, which means
nobody had got around to adding it before.
perl_section: </Files>
perl_section: </Location>
perl_section: </Files>
perl_section: </Location>
perl_section: </Directory>
perl_section: </Directory>
perl_section: </VirtualHost>
init `PerlHandler' stack
perl_cmd_push_handlers: @PerlHandler, 'Embperl'
pushing `Embperl' into `PerlHandler' handlers
[Fri Mar 22 10:43:22 2002] [warn] pid file
/usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of
previous Apache run?
And now we do the normal module inits.
ap_init_modules: embperl.c->init(0xD3308, 0xD32E0)
embperl_apacheInit(0xD3308, 0xD32E0)
## called embperl_INit (0x0)
Caling addmodule anyway
## 1 calling add_module
## not calling add_module
ap_init_modules: mod_perl.c->init(0xD3308, 0xD32E0)
loading perl module 'Apache'...ok
`PerlRestartHandler' push_handlers() stack is empty
PerlRestartHandler handlers returned -1
ap_init_modules: mod_unique_id.c->init(0xD3308, 0xD32E0)
ap_init_modules: mod_proxy.c->init(0xD3308, 0xD32E0)
ap_init_modules: mod_rewrite.c->init(0xD3308, 0xD32E0)
ap_init_modules: mod_status.c->init(0xD3308, 0xD32E0)
ap_init_modules: mod_mime.c->init(0xD3308, 0xD32E0)
ap_init_modules: mod_mime_magic.c->init(0xD3308, 0xD32E0)
ap_init_modules: mod_log_config.c->init(0xD3308, 0xD32E0)
perl_init_ids: uid=-2, euid=-2, gid=70, egid=70
`PerlChildInitHandler' push_handlers() stack is empty
PerlChildInitHandler handlers returned -1
So, I have a work-around. But I think there is something
fundamentally wrong. Embperl is doing a couple odd things that work
around the problem on some systems, but don't work on other systems.
However the whole thing could be fixed (I believe) by doing one of
two things.
1. Don't read the damn config file twice.
2. If you have to do #1, then restart the Perl interpreter each time
the config file is read.
Comments?
P.S. Anyone want someone to write an apache module for them? I might
as well put everything I've learned in the past few days to *some*
use!
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
nazgul@somewhere.com
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
Re: mod_perl developers cookbook... a kitchen hand asks... doh!
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 01:23 25.03.2002, Issac Goldstand wrote:
>>You must have taken this subroutine out of context. There are a certain
>>number of things which must appear for an Apache handler to work:
>>
>>package Apache::Whatever;
>>
>>You need to have that line to uniquely identify your module. If you use
>>the name Apache::Whatever, your handler must be named Whatever.pm and be
>>placed in your @INC search path under Apache/
>>This is probably the reason for your number 2 problem: you must have used
>>the same package name twice. Or not used a package name at all.
>
>
>Actually, this isn't true.. You don't *have* to use the Apache
>namespace... You can just as easily call it Foo::Bar if you'd like... I
>don't mean to come across as being an extremist on this issue, but we were
>all newbies once, and I know that as a newbie, *I* would take anything
>written here as the "authorative" answer, so I didn't want anyone here to
>be misled...
Yes, sorry, I didn't want to make it appear like you had to use the
Apache:: namespace. In the Cookbook for example they use the Cookbook::
namespace, and you could just as well use Jeff::.
--
Per Einar Ellefsen
per.einar@skynet.be
Re: mod_perl developers cookbook... a kitchen hand asks... doh!
Posted by Issac Goldstand <ma...@beamartyr.net>.
>
> You must have taken this subroutine out of context. There are a
> certain number of things which must appear for an Apache handler to work:
>
> package Apache::Whatever;
>
> You need to have that line to uniquely identify your module. If you
> use the name Apache::Whatever, your handler must be named Whatever.pm
> and be placed in your @INC search path under Apache/
> This is probably the reason for your number 2 problem: you must have
> used the same package name twice. Or not used a package name at all.
Actually, this isn't true.. You don't *have* to use the Apache
namespace... You can just as easily call it Foo::Bar if you'd like...
I don't mean to come across as being an extremist on this issue, but we
were all newbies once, and I know that as a newbie, *I* would take
anything written here as the "authorative" answer, so I didn't want
anyone here to be misled...
Issac
Re: mod_perl developers cookbook... a kitchen hand asks... doh!
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 17:30 23.03.2002 +0000, Jeff wrote:
>Just Curious of Hither Green writes:
>
>So, I am working my way through, and get to page 83 which has a little
>spellette:
>
>sub handler {
> my $r = shift;
> print STDERR $r->as_string();
> return OK;
>}
>
>looks easy peasy - but
>
>1) OK -> Bareword "OK" not allowed while "strict subs" in use
> well, that's easy to fix - I must be missing a 'use' [which one??]
> I assume OK is 1 - ie TRUE
>
>2) error log: Subroutine handler redefined at xxx line 1
>
>This is interesting - probably because PerlHandler Apache::Registry so
>kitchen whizzes, tell me please, exactly what knead I put in my
>httpd.conf instead of Apache::Registry?
You must have taken this subroutine out of context. There are a certain
number of things which must appear for an Apache handler to work:
package Apache::Whatever;
You need to have that line to uniquely identify your module. If you use the
name Apache::Whatever, your handler must be named Whatever.pm and be placed
in your @INC search path under Apache/
This is probably the reason for your number 2 problem: you must have used
the same package name twice. Or not used a package name at all.
use Apache::Constants;
This imports the constants like OK, DECLINED, etc... You can also specify
them explicitly:
use Apache::Constants qw(OK DECLINED);
I hope this helps you out.
--
Per Einar Ellefsen
per.einar@skynet.be
Re: PerlModule hell - questions and comments
Posted by Kee Hinckley <na...@somewhere.com>.
At 9:13 PM +0200 5/26/02, Gerald Richter wrote:
>Hi Kee,
>> >
>> >I am back, so let start another round in debugging the setup ....
>>
>> I haven't forgotten this--just swamped. Hopefully later this week.
>>
>
>While trying to get Embperl to work with Apache 2.0, I had another idea what
>maybe the problem. To verfiy this, could you please send me the output of
>
>httpd -l
>
>I guess you have both, mod_perl.c and mod_dso.c in this list...
>
>At least this would explain the strange behaviour and is a setup that I
>didn't have tested so far. If this is the case I think I will be able to fix
>it
Compiled-in modules:
http_core.c
mod_so.c
mod_perl.c
suexec: disabled; invalid wrapper /usr/local/apache/bin/suexec
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: PerlModule hell - questions and comments
Posted by Gerald Richter <ri...@ecos.de>.
Hi Kee,
> >
> >I am back, so let start another round in debugging the setup ....
>
> I haven't forgotten this--just swamped. Hopefully later this week.
>
While trying to get Embperl to work with Apache 2.0, I had another idea what
maybe the problem. To verfiy this, could you please send me the output of
httpd -l
I guess you have both, mod_perl.c and mod_dso.c in this list...
At least this would explain the strange behaviour and is a setup that I
didn't have tested so far. If this is the case I think I will be able to fix
it
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: PerlModule hell - questions and comments
Posted by Kee Hinckley <na...@somewhere.com>.
At 8:49 PM +0200 4/7/02, Gerald Richter wrote:
>Hi Kee,
>
>I am back, so let start another round in debugging the setup ....
I haven't forgotten this--just swamped. Hopefully later this week.
>
>I have tried to create a minimal httpd.conf. I have a httpd (1.3.23) with
>staticly compiled in mod_perl 1.26 and Perl version 5.6.1 (I try several
>other combinations, but same result). With this httpd.conf Apache starts
>without problems and when I do a request to
>http://localhost:8531/server-info I see the Embperl configuration. (of
>course mod_info must be compiled in)
>
>Does this also works for you or do you get the same errors as before?
>
>If you still get errors, how is your mod_perl compiled (which parameter did
>you give to perl Makefile.PL) ? and please send me the output of perl -V
>
>Gerald
>
>------
>
>ServerRoot "/usr/msrc/ep2a/test"
>ServerName localhost
>DocumentRoot "/usr/msrc/ep2a/test"
>Port 8531
>
>User nobody
>Group root
>
>MinSpareServers 1
>MaxSpareServers 30
>StartServers 3
>MaxClients 10
>MaxRequestsPerChild 0
>
>DirectoryIndex index.htm
>
>ErrorLog tmp/httpd.err.log
>PidFile tmp/httpd.pid
>AccessConfig conf/null
>ResourceConfig conf/null
>TypesConfig conf/null
>LockFile tmp/httpd.lock
>
>PerlModule Embperl
>
>Embperl_UseEnv off
>
>
><Location /server-status>
>SetHandler server-status
></Location>
>
><Location /server-info>
>SetHandler server-info
></Location>
>
>
>
>
>
>-------------------------------------------------------------
>Gerald Richter ecos electronic communication services gmbh
>Internetconnect * Webserver/-design/-datenbanken * Consulting
>
>Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
>E-Mail: richter@ecos.de Voice: +49 6133 925131
>WWW: http://www.ecos.de Fax: +49 6133 925152
>-------------------------------------------------------------
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
nazgul@somewhere.com
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: PerlModule hell - questions and comments
Posted by Gerald Richter <ri...@ecos.de>.
Hi Kee,
I am back, so let start another round in debugging the setup ....
I have tried to create a minimal httpd.conf. I have a httpd (1.3.23) with
staticly compiled in mod_perl 1.26 and Perl version 5.6.1 (I try several
other combinations, but same result). With this httpd.conf Apache starts
without problems and when I do a request to
http://localhost:8531/server-info I see the Embperl configuration. (of
course mod_info must be compiled in)
Does this also works for you or do you get the same errors as before?
If you still get errors, how is your mod_perl compiled (which parameter did
you give to perl Makefile.PL) ? and please send me the output of perl -V
Gerald
------
ServerRoot "/usr/msrc/ep2a/test"
ServerName localhost
DocumentRoot "/usr/msrc/ep2a/test"
Port 8531
User nobody
Group root
MinSpareServers 1
MaxSpareServers 30
StartServers 3
MaxClients 10
MaxRequestsPerChild 0
DirectoryIndex index.htm
ErrorLog tmp/httpd.err.log
PidFile tmp/httpd.pid
AccessConfig conf/null
ResourceConfig conf/null
TypesConfig conf/null
LockFile tmp/httpd.lock
PerlModule Embperl
Embperl_UseEnv off
<Location /server-status>
SetHandler server-status
</Location>
<Location /server-info>
SetHandler server-info
</Location>
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: mod_perl developers cookbook... a kitchen hand asks... doh!
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>
> "OK" is a constant for the HTTP return code 200.
close. OK is 0, which is different from HTTP_OK which is 200.
--Geoff
Re: mod_perl developers cookbook... a kitchen hand asks... doh!
Posted by Ade Olonoh <ol...@yahoo.com>.
> 1) OK -> Bareword "OK" not allowed while "strict subs" in use
> well, that's easy to fix - I must be missing a 'use' [which one??]
> I assume OK is 1 - ie TRUE
"OK" is a constant for the HTTP return code 200. Add:
use Apache::Constants ':common';
to the top of your prog. and it should work.
> 2) error log: Subroutine handler redefined at xxx line 1
Are you using Apache::StatINC?
--Ade.
Re: mod_perl developers cookbook... a kitchen hand asks... doh!
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Jeff wrote:
> Just Curious of Hither Green writes:
>
> I feel like a right tit for asking this...
>
> I already have mod_perl et al running, including my persistent DB connections
> etc etc, but following gourmet cookery advice on this list induced me to
> buy a copy of the mod_perl Developers Cookbook... and yes, my nails were
> rather short after the week it took my Amazon to deliver said arcane tome
> unto my abode.
I hope you enjoy it and that you didn't bite to the quick...
>
> So, I am working my way through, and get to page 83 which has a little spellette:
>
>
> sub handler { my $r = shift; print STDERR $r->as_string(); return OK; }
>
> looks easy peasy - but
>
> 1) OK -> Bareword "OK" not allowed while "strict subs" in use well, that's
> easy to fix - I must be missing a 'use' [which one??] I assume OK is 1 - ie
> TRUE
OK is actually 0, but is better used as
use Apache::Constants qw(OK);
as to avoid any real value behind the OK constant. see recipe 3.12 for more
details about this notation.
>
> 2) error log: Subroutine handler redefined at xxx line 1
well, you have to put handler() in a package first... depending on which package
you put it in, it might redefine something that already exists.
you're coming up against something I struggled with throughout the book. lots
of our examples use handler snippets instead of the complete handler. this is
because I thought doing this
package Cookbook::Foo;
use Apache::Constants qw(:common);
use strict;
sub handler {
...
}
1;
wasted lots of space - in this particular instance the other cruft is longer
than the code we were illustrating :)
so I basically took the point of view that for shortish stuff enforcing the
handler() meme was good enough, and the package stuff could be reinforced
elsewhere. and there's always the eagle book in addition to our stuff.
I hope that as you read through the rest of the book things start solidifying...
HTH
--Geoff
mod_perl developers cookbook... a kitchen hand asks... doh!
Posted by Jeff <ja...@aquabolt.com>.
Just Curious of Hither Green writes:
I feel like a right tit for asking this...
I already have mod_perl et al running, including my persistent DB
connections etc etc, but following gourmet cookery advice on this list
induced me to buy a copy of the mod_perl Developers Cookbook... and yes,
my nails were rather short after the week it took my Amazon to deliver
said arcane tome unto my abode.
So, I am working my way through, and get to page 83 which has a little
spellette:
sub handler {
my $r = shift;
print STDERR $r->as_string();
return OK;
}
looks easy peasy - but
1) OK -> Bareword "OK" not allowed while "strict subs" in use
well, that's easy to fix - I must be missing a 'use' [which one??]
I assume OK is 1 - ie TRUE
2) error log: Subroutine handler redefined at xxx line 1
This is interesting - probably because PerlHandler Apache::Registry so
kitchen whizzes, tell me please, exactly what knead I put in my
httpd.conf instead of Apache::Registry?
Thanks a munch!
Jeff
Re: PerlModule hell - questions and comments
Posted by Kee Hinckley <na...@somewhere.com>.
At 7:04 PM +0800 3/23/02, Stas Bekman wrote:
>If all you want to do is to be able to load the module only during
>the restart use in startup.pl:
>
> if ($Apache::Server::ReStarting) {
> require "My::Sensitive::Module";
> }
No, the module has to be loaded during both phases, other wise the
configuration file syntax extensions it adds won't be loaded. The
sequence is:
1. Module loads
2. On load, module registers as an Apache module
3. On the second parse of the config file, apache asks module to unload
4. Perl module unregisters itself
5. Module isn't reloaded (because perl modules get loaded only once)
6. Apache module doesn't get reloaded
7. Config file parse fails with syntax errors
You would think that I could just skip step #4, but as far as I can
tell that leaves stale pointers around, at least on some
platforms/configurations. It also doesn't seem proper in general.
The only work-around I have is to add an <perl> section that calls
the initialization manually. That works, but one would hope that
Perl modules could be treated as first-class Apache modules with
extra magic in the config file.
BTW. I thought that startup.pl was only called once, so your
suggestion would only work inside a <perl> directive anyway?
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
nazgul@somewhere.com
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: PerlModule hell - questions and comments
Posted by Kee Hinckley <na...@somewhere.com>.
At 7:04 PM +0800 3/23/02, Stas Bekman wrote:
>If all you want to do is to be able to load the module only during
>the restart use in startup.pl:
>
> if ($Apache::Server::ReStarting) {
> require "My::Sensitive::Module";
> }
No, the module has to be loaded during both phases, other wise the
configuration file syntax extensions it adds won't be loaded. The
sequence is:
1. Module loads
2. On load, module registers as an Apache module
3. On the second parse of the config file, apache asks module to unload
4. Perl module unregisters itself
5. Module isn't reloaded (because perl modules get loaded only once)
6. Apache module doesn't get reloaded
7. Config file parse fails with syntax errors
You would think that I could just skip step #4, but as far as I can
tell that leaves stale pointers around, at least on some
platforms/configurations. It also doesn't seem proper in general.
The only work-around I have is to add an <perl> section that calls
the initialization manually. That works, but one would hope that
Perl modules could be treated as first-class Apache modules with
extra magic in the config file.
BTW. I thought that startup.pl was only called once, so your
suggestion would only work inside a <perl> directive anyway?
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
nazgul@somewhere.com
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
Re: PerlModule hell - questions and comments
Posted by Stas Bekman <st...@stason.org>.
Kee Hinckley wrote:
> At 4:18 PM -0500 3/22/02, Perrin Harkins wrote:
>
>> Modules loaded with PerlModule and PerlRequire are not supposed to be
>> loaded again the second time. I seem to remember that they are loaded
>> again when using DSO though, so if you're using DSO you may want to
>> recompile as static. Also, if you have PerlFreshRestart on that will
>> cause a reload.
>
>
> If all you were doing was loading a normal Perl module, the single load
> would be fine. The catch is that in this case we are loading a Perl
> module which in turn is registering an Apache module. The Apache module
> is being *unloaded* prior to the second pass through the config file.
> The only way that it will be reloaded is if the Perl module is reloaded
> on the second pass as well.
If all you want to do is to be able to load the module only during the
restart use in startup.pl:
if ($Apache::Server::ReStarting) {
require "My::Sensitive::Module";
}
--
__________________________________________________________________
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: PerlModule hell - questions and comments
Posted by Kee Hinckley <na...@somewhere.com>.
At 5:11 PM -0500 3/22/02, Perrin Harkins wrote:
>Kee Hinckley wrote:
>>At Embperl 2.0b6 Gerald switched to a new architecture. The
>>previous version was just a plain Perl module loaded as a handler
>>by mod_perl. This version is also an Apache module.
>
>Okay, if it's only in the recent betas then it's possible that only
>a few people have encountered this. Can anyone else who has built a
>module with custom conf directives comment on this issue?
I should note that it also appears to be at least partially either an
architecture or configuration issue. The original code which worked
for Gerald didn't call unload in its cleanup handler. However that
did not work on my system (MacOS X), and on at least one other system
(Linux). I found that I had to call unload for things to work, and
then it wasn't getting it reloaded. So there may be another way to
fix the problem. Suggestions are more than welcome.
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
nazgul@somewhere.com
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: PerlModule hell - questions and comments
Posted by Kee Hinckley <na...@somewhere.com>.
At 5:11 PM -0500 3/22/02, Perrin Harkins wrote:
>Kee Hinckley wrote:
>>At Embperl 2.0b6 Gerald switched to a new architecture. The
>>previous version was just a plain Perl module loaded as a handler
>>by mod_perl. This version is also an Apache module.
>
>Okay, if it's only in the recent betas then it's possible that only
>a few people have encountered this. Can anyone else who has built a
>module with custom conf directives comment on this issue?
I should note that it also appears to be at least partially either an
architecture or configuration issue. The original code which worked
for Gerald didn't call unload in its cleanup handler. However that
did not work on my system (MacOS X), and on at least one other system
(Linux). I found that I had to call unload for things to work, and
then it wasn't getting it reloaded. So there may be another way to
fix the problem. Suggestions are more than welcome.
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
nazgul@somewhere.com
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
Re: PerlModule hell - questions and comments
Posted by Kee Hinckley <na...@somewhere.com>.
At 5:11 PM -0500 3/22/02, Perrin Harkins wrote:
>In your case, PerlFreshRestart might help with what you're trying to
>do since it will clear %INC, but you may still have the problem with
>needing to call Init.
PerlFreshRestart will reload the module and thus call Init, but
PerlFreshRestart is only called when we fork a new process, it is not
called between the first and second parsing of the config file at
startup.
That seems like a bug to me. If reading the config file twice is
intended to ensure that subsequent re-reads on HUP will work, then
*everything* should be the same, and that means if PerlFreshRestart
is set, it ought to happen there as well.
Oddly enough though, PerlFreshRestart is not required for this to
work after a HUP, even though it would seem to make sense. Looking
at my debug output, it appears that -HUP doesn't cause the cleanup
handlers to be called, so the module is never unloaded.
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
nazgul@somewhere.com
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
Re: PerlModule hell - questions and comments
Posted by Kee Hinckley <na...@somewhere.com>.
At 5:11 PM -0500 3/22/02, Perrin Harkins wrote:
>In your case, PerlFreshRestart might help with what you're trying to
>do since it will clear %INC, but you may still have the problem with
>needing to call Init.
PerlFreshRestart will reload the module and thus call Init, but
PerlFreshRestart is only called when we fork a new process, it is not
called between the first and second parsing of the config file at
startup.
That seems like a bug to me. If reading the config file twice is
intended to ensure that subsequent re-reads on HUP will work, then
*everything* should be the same, and that means if PerlFreshRestart
is set, it ought to happen there as well.
Oddly enough though, PerlFreshRestart is not required for this to
work after a HUP, even though it would seem to make sense. Looking
at my debug output, it appears that -HUP doesn't cause the cleanup
handlers to be called, so the module is never unloaded.
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
nazgul@somewhere.com
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: PerlModule hell - questions and comments
Posted by Perrin Harkins <pe...@elem.com>.
Kee Hinckley wrote:
> At Embperl 2.0b6 Gerald switched to a new architecture. The previous
> version was just a plain Perl module loaded as a handler by mod_perl.
> This version is also an Apache module.
Okay, if it's only in the recent betas then it's possible that only a
few people have encountered this. Can anyone else who has built a
module with custom conf directives comment on this issue?
> Maybe we need an option for PerlModule that forces a load each time?
It seems like something to keep the C and perl sides doing the same
thing is what's needed, so that if the C stuff gets unloaded the perl
stuff will too.
In your case, PerlFreshRestart might help with what you're trying to do
since it will clear %INC, but you may still have the problem with
needing to call Init.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: PerlModule hell - questions and comments
Posted by Stas Bekman <st...@stason.org>.
Kee Hinckley wrote:
> At 4:18 PM -0500 3/22/02, Perrin Harkins wrote:
>
>> Modules loaded with PerlModule and PerlRequire are not supposed to be
>> loaded again the second time. I seem to remember that they are loaded
>> again when using DSO though, so if you're using DSO you may want to
>> recompile as static. Also, if you have PerlFreshRestart on that will
>> cause a reload.
>
>
> If all you were doing was loading a normal Perl module, the single load
> would be fine. The catch is that in this case we are loading a Perl
> module which in turn is registering an Apache module. The Apache module
> is being *unloaded* prior to the second pass through the config file.
> The only way that it will be reloaded is if the Perl module is reloaded
> on the second pass as well.
If all you want to do is to be able to load the module only during the
restart use in startup.pl:
if ($Apache::Server::ReStarting) {
require "My::Sensitive::Module";
}
--
__________________________________________________________________
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: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: PerlModule hell - questions and comments
Posted by Perrin Harkins <pe...@elem.com>.
Kee Hinckley wrote:
> At Embperl 2.0b6 Gerald switched to a new architecture. The previous
> version was just a plain Perl module loaded as a handler by mod_perl.
> This version is also an Apache module.
Okay, if it's only in the recent betas then it's possible that only a
few people have encountered this. Can anyone else who has built a
module with custom conf directives comment on this issue?
> Maybe we need an option for PerlModule that forces a load each time?
It seems like something to keep the C and perl sides doing the same
thing is what's needed, so that if the C stuff gets unloaded the perl
stuff will too.
In your case, PerlFreshRestart might help with what you're trying to do
since it will clear %INC, but you may still have the problem with
needing to call Init.
- Perrin
Re: PerlModule hell - questions and comments
Posted by Kee Hinckley <na...@somewhere.com>.
At 4:18 PM -0500 3/22/02, Perrin Harkins wrote:
>Modules loaded with PerlModule and PerlRequire are not supposed to
>be loaded again the second time. I seem to remember that they are
>loaded again when using DSO though, so if you're using DSO you may
>want to recompile as static. Also, if you have PerlFreshRestart on
>that will cause a reload.
If all you were doing was loading a normal Perl module, the single
load would be fine. The catch is that in this case we are loading a
Perl module which in turn is registering an Apache module. The
Apache module is being *unloaded* prior to the second pass through
the config file. The only way that it will be reloaded is if the
Perl module is reloaded on the second pass as well.
>A couple of people reported a bug that they were seeing which caused
>these modules to be loaded twice anyway. That sounds like the issue
>you saw with <Perl> sections. I haven't tested this myself, and
>fixing it would probably require help from Doug. As a workaround,
>it is possible to do all of your module loading from a startup.pl
>called from PerlRequire, and avoid that problem. That's what I do.
That doesn't solve the problem because it won't load twice, and the
Apache module won't get reloaded.
>because I don't use any modules that add conf directives. Maybe
>Gerald will have an explanation of what the expected behavior is on
>his end. It can't be this much trouble for most people or no one
>would be using Embperl or custom conf directives.
At Embperl 2.0b6 Gerald switched to a new architecture. The previous
version was just a plain Perl module loaded as a handler by mod_perl.
This version is also an Apache module.
Maybe we need an option for PerlModule that forces a load each time?
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
nazgul@somewhere.com
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
Re: PerlModule hell - questions and comments
Posted by Kee Hinckley <na...@somewhere.com>.
At 4:18 PM -0500 3/22/02, Perrin Harkins wrote:
>Modules loaded with PerlModule and PerlRequire are not supposed to
>be loaded again the second time. I seem to remember that they are
>loaded again when using DSO though, so if you're using DSO you may
>want to recompile as static. Also, if you have PerlFreshRestart on
>that will cause a reload.
If all you were doing was loading a normal Perl module, the single
load would be fine. The catch is that in this case we are loading a
Perl module which in turn is registering an Apache module. The
Apache module is being *unloaded* prior to the second pass through
the config file. The only way that it will be reloaded is if the
Perl module is reloaded on the second pass as well.
>A couple of people reported a bug that they were seeing which caused
>these modules to be loaded twice anyway. That sounds like the issue
>you saw with <Perl> sections. I haven't tested this myself, and
>fixing it would probably require help from Doug. As a workaround,
>it is possible to do all of your module loading from a startup.pl
>called from PerlRequire, and avoid that problem. That's what I do.
That doesn't solve the problem because it won't load twice, and the
Apache module won't get reloaded.
>because I don't use any modules that add conf directives. Maybe
>Gerald will have an explanation of what the expected behavior is on
>his end. It can't be this much trouble for most people or no one
>would be using Embperl or custom conf directives.
At Embperl 2.0b6 Gerald switched to a new architecture. The previous
version was just a plain Perl module loaded as a handler by mod_perl.
This version is also an Apache module.
Maybe we need an option for PerlModule that forces a load each time?
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
nazgul@somewhere.com
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: PerlModule hell - questions and comments
Posted by Perrin Harkins <pe...@elem.com>.
Kee Hinckley wrote:> 1. *Why* are the apache config files executed twice (completely with
> loading and unloading all the modules)?
This is a core apache thing. Apache does it to verify that a restart is
safe. See
http://thingy.kcilink.com/modperlguide/config/Apache_Restarts_Twice_On_Start.html
I'm not saying I think it's the greatest idea, but that's the reason
behind it.
Modules loaded with PerlModule and PerlRequire are not supposed to be
loaded again the second time. I seem to remember that they are loaded
again when using DSO though, so if you're using DSO you may want to
recompile as static. Also, if you have PerlFreshRestart on that will
cause a reload.
A couple of people reported a bug that they were seeing which caused
these modules to be loaded twice anyway. That sounds like the issue you
saw with <Perl> sections. I haven't tested this myself, and fixing it
would probably require help from Doug. As a workaround, it is possible
to do all of your module loading from a startup.pl called from
PerlRequire, and avoid that problem. That's what I do.
Of course my goal here sounds like exactly the opposite of yours: you
actually *want* Embperl to get loaded both times so that your conf
directives will work. I haven't run into that problem before because I
don't use any modules that add conf directives. Maybe Gerald will have
an explanation of what the expected behavior is on his end. It can't be
this much trouble for most people or no one would be using Embperl or
custom conf directives.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: PerlModule hell - questions and comments
Posted by Perrin Harkins <pe...@elem.com>.
Kee Hinckley wrote:> 1. *Why* are the apache config files executed twice (completely with
> loading and unloading all the modules)?
This is a core apache thing. Apache does it to verify that a restart is
safe. See
http://thingy.kcilink.com/modperlguide/config/Apache_Restarts_Twice_On_Start.html
I'm not saying I think it's the greatest idea, but that's the reason
behind it.
Modules loaded with PerlModule and PerlRequire are not supposed to be
loaded again the second time. I seem to remember that they are loaded
again when using DSO though, so if you're using DSO you may want to
recompile as static. Also, if you have PerlFreshRestart on that will
cause a reload.
A couple of people reported a bug that they were seeing which caused
these modules to be loaded twice anyway. That sounds like the issue you
saw with <Perl> sections. I haven't tested this myself, and fixing it
would probably require help from Doug. As a workaround, it is possible
to do all of your module loading from a startup.pl called from
PerlRequire, and avoid that problem. That's what I do.
Of course my goal here sounds like exactly the opposite of yours: you
actually *want* Embperl to get loaded both times so that your conf
directives will work. I haven't run into that problem before because I
don't use any modules that add conf directives. Maybe Gerald will have
an explanation of what the expected behavior is on his end. It can't be
this much trouble for most people or no one would be using Embperl or
custom conf directives.
- Perrin