Re: Shared memory broke ;.;
Daniel Wilson wrote: Its not sharing the modules at start up and none of the config or compile options have changed. You diff'ed httpd.conf and startup.pl and found no differences at all? The only thing different is the fact the old server has a custom SMP kernel and the new has redhat's stock kernel. I suppose it's possible that the two kernels have a different approach to calculating memory usage. Doesn't seem likely though. Are you sure you used the same Perl, same apache, same mod_perl, etc.? Double-check them. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: VirtualHost + PerlSetVar
Paul G. Weiss wrote: Rats! PerlPostConfigHandler appears to have absolutely no effect when placed inside a scope. It does indeed run when placed outside. I know this because I have something like: open(H, ">", "/tmp/output"); print H "something\n" in my handler and the file written to only when PerlPostConfigHandler is outside the scope. By the way, this is also true with PostOpenLogsHandler. In fact, when I set PerlTrace all in my configuration file, I see the line: modperl_callback_run_handlers: no PerlPostConfigHandler handlers configured () You are right. I added a test and it fails :( I was pretty sure that it should have worked. I've digged into the code and learned that Apache runs it only for the main server. Same for open_logs. Lemme ping httpd-dev about this, though I doubt any good will come out of this. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Problems with configuring mod_perl / apache 1.3.29 and mod ssl -2.8.16-1.3.29
HI all, On Sat, 20 Dec 2003, Stas Bekman wrote: > See: http://perl.apache.org/bugs/ PING perl.apache.org (209.237.227.195) from 212.22.195.7 : 56(84) bytes of data. --- perl.apache.org ping statistics --- 9 packets transmitted, 0 packets received, 100% packet loss Is anyone else having problems just now? (Because of the number of times it crops up, I was going to ask if http://perl.apache.org/docs/2.0/user/help/help.html#Wrong_Apache_mod_perl_combination should perhaps be in a more obvious place on the site - but as I can't get a reponse from the server, I don't know how obvious it is now... :) 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Shared memory broke ;.;
Hi there, On Sat, 20 Dec 2003, Daniel Wilson wrote: > Moved my site to a new server. > > Old Server > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND > 30056 apache 9 0 10964 10M 10288 S 0.0 0.7 0:00 0 httpd > New Server > 2733 apache16 0 12716 12M 3520 S 3.0 2.5 0:00 0 httpd > > What the hell happened? You didn't tell us much about the servers. Did you have more memory in the old one? > Recompiling the kernel is the last thing i want to do remotely. You can do it if you're careful. I do. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Problems with configuring mod_perl / apache 1.3.29 and mod ssl -2.8.16-1.3.29
Ged Haywood wrote: HI all, On Sat, 20 Dec 2003, Stas Bekman wrote: See: http://perl.apache.org/bugs/ PING perl.apache.org (209.237.227.195) from 212.22.195.7 : 56(84) bytes of data. --- perl.apache.org ping statistics --- 9 packets transmitted, 0 packets received, 100% packet loss Is anyone else having problems just now? It's down. Due to a fire in SF. (Because of the number of times it crops up, I was going to ask if http://perl.apache.org/docs/2.0/user/help/help.html#Wrong_Apache_mod_perl_combination should perhaps be in a more obvious place on the site - but as I can't get a reponse from the server, I don't know how obvious it is now... :) It's all over the place. If the user has even tried to read the online docs, there is at least 3 places in the installation where it says so in big letters. Of course the user may have not known about the existance of these online docs. But the included modperl-2.0/README file says: *** Prerequisites *** Apache: This version of mod_perl works with Apache versions 2.0.36 - 2.0.47. ... of course the user may have never seen the source... oh well __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Problems with configuring mod_perl / apache 1.3.29 and mod ssl -2.8.16-1.3.29
Hi Stas, On Sun, 21 Dec 2003, Stas Bekman wrote: > > Is anyone else having problems just now? > > It's down. Due to a fire in SF. Oh. Careless. > If the user has even tried to read the online docs, there is at > least 3 places in the installation... :) 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: VirtualHost + PerlSetVar
Hi,
Am Samstag, 20. Dezember 2003 22:52 schrieb Paul G. Weiss:
> Great suggestion. I'll certainly try that.
>
> As to why I expected PerlSetVar to be available during startup, it is
> because that is how it was with mod_perl1, and I wasn't considering the
> fact that configuration in mod_perl2 is a very different animal. I'll
> pass your suggestion on to the maintainer of Apache::PageKit (that is, if
> he doesn't read this list), because it will affect his documentation.
>
Just for the Apache::PageKit case, you can do all the startup stuff in your
startup.pl or in a section outside of your section.
But now it is up to you to make sure that the A::P startup parameter match the
perlsetvar vars.
This should work with mod_perl 1 and 2.
ie:
use Apache::PageKit;
Apache::PageKit->startup('/x/z/a/my_pkit_root_for_site_foo', 'staging');
Apache::PageKit->startup('//yyy/my_pkit_root_for_site_bar', 'staging');
PerlSetVar PKIT_ROOT /x/z/a/my_pkit_root_for_site_foo
PerlSetVar PKIT_SERVER staging
SetHandler perl-script
PerlHandler +Apache::PageKit
PerlSetVar PKIT_ROOT //yyy/my_pkit_root_for_site_bar
PerlSetVar PKIT_SERVER staging
SetHandler perl-script
PerlHandler +Apache::PageKit
> -Paul
>
> On Fri, 19 Dec 2003 18:32:46 -0800, Stas Bekman <[EMAIL PROTECTED]> wrote:
> > Paul G. Weiss wrote:
> > [...]
> >
> >> The reason this is important is that I'm trying to get Apache::PageKit
> >> to run in virtual hosts, and it depends on the availability of
> >> PerlSetVar variables on startup.
> >
> > First of all, why do you expect PerlSetVar to be available at the server
> > startup? The config phase is not completed and the value can be
> > overriden several times by the end of config.
> >
> > Second, Apache->server always gives you the global (top-level) server,
> > so of course once you move PerlSetVar outside of vhost, you get to see
> > its value.
> >
> > I think using PerlPostConfigHandler will let you achieve what you want:
> >
> > PerlRequire /var/www/perl/startup.pl
> > # set value in global scope
> > PerlSetVar foo global
> >
> > SetHandler perl-script
> > PerlHandler Module
> >
> >
> > # set value in virtual host scope
> > PerlSetVar foo virtual
> > PerlModule Module
> > PerlPostConfigHandler Module::start
> >
> >
> > package Module;
> >
> > sub start {
> > my($conf_pool, $log_pool, $temp_pool, $s) = @_;
> > print "Module->start sees foo=" . $s->dir_config('foo') . "\n";
> > }
> >
> > (this code is untested, but I think it should do what you want)
> >
> > The difference is that you get the correct $s object here (which you
> > can't get during the config phase). Sounds like your case can be a
> > useful addition to the existing example:
> > http://perl.apache.org/docs/2.0/user/handlers/server.html#PerlPostConfigH
> >andler
> >
> > __
> > Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> > http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> > http://modperlbook.org http://apache.org http://ticketmaster.com
--
Boris
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: directive says no perl handler specified
Thanks for the help. I painstakingly built new RPMs and got Apache to 2.0.48-1 and fixed all dependencies and updated mod perl to 1.99_11, and SO FAR everything with the directive seems to be fine. I might have made a bit of a mess of my RPM dependencies and I can only pray no problems happen in the future. :-) --- Stas Bekman <[EMAIL PROTECTED]> wrote: > Brian Bober wrote: > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25175 > > > > Running Redhat 9, Apache 2.0.40 > > See http://perl.apache.org/bugs/ > > > This directive is within a virtual host section. I also installed > > bundle::openinteract > > > > > > use lib qw( /var/www/html/thenetdragon/www ); > > > > > > OpenInteract needs this to function properly. > > > > (/etc/httpd/conf.d)> service httpd restart > > Stopping httpd:[FAILED] > > Starting httpd: Syntax error on line 1087 of /etc/httpd/conf/httpd.conf: > > no handler specified > > > > > > I tried installing Bundle::Apache through Cpan to solve the problem, but it > > wouldn't finish installing... I got errors. > > You need to install the latest modperl, 1.99_11 (1.99_12 will be released on > Monday). > > > > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com > --- Chris Winters <[EMAIL PROTECTED]> wrote: > >> This directive is within a virtual host section. I also installed > >> bundle::openinteract > >> > >> use lib qw( /var/www/html/thenetdragon/www ); > >> > >> OpenInteract needs this to function properly. > >> (/etc/httpd/conf.d)> service httpd restart > > FWIW, OpenInteract doesn't work with Apache2/mod_perl2, and AFAIK it > probably won't. OpenInteract2 (now in beta) will work with mod_perl > versions 1, 2 and other environments as well. > > Chris > > -- > Chris Winters > Creating enterprise-capable snack systems since 1988 > > > -- > Reporting bugs: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Testing custom configuration directives
Hi! Anyone has experience in testing an Apache module (mod_perl 2.0, of course) with custom configuration directives ? I'm talking about a module "packaged" (h2xs -AX -n Foo::Bar) and then tested (perl Makefile.PL; make; make test), when as custom configuration is like that: # file t/conf/extra.conf.in PerlModule Foo::Bar #PerlLoadModule Foo::Bar# if uncommented catch an error when "make test" MyFoo 30 SetHandler modperl PerlRequestHandler Foo::Bar Obviously the variable MyFoo is corrected "handled" in Foo/Bar.pm (see mod_perl 2.0 User's guide ch.6 for more details) but seems to be not work under a "packaged" module. So I can't test... only testing "by hand" (orribly long time operation..). Any suggestions/critics/wishes ? TIA -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Testing custom configuration directives
Carletto wrote: > Hi! > Anyone has experience in testing an Apache module (mod_perl 2.0, of course) > with > custom configuration directives ? > I'm talking about a module "packaged" (h2xs -AX -n Foo::Bar) and then tested > (perl Makefile.PL; make; make test), when as custom configuration is like > that: > > # file t/conf/extra.conf.in > PerlModule Foo::Bar > #PerlLoadModule Foo::Bar# if uncommented catch an error when "make test" > > MyFoo 30 > SetHandler modperl > PerlRequestHandler Foo::Bar > > > Obviously the variable MyFoo is corrected "handled" in Foo/Bar.pm (see > mod_perl 2.0 User's guide ch.6 for > more details) but seems to be not work under a "packaged" module. > So I can't test... only testing "by hand" (orribly long time operation..). > I don't really understand what you mean by all this. are you saying you want to test whether MyFoo is "30" via "make test"? that's fairly simple to do. just use the "test from within a handler" approach when planning your tests - see t/response/TestDirective/perlloadmodule.pm for an example that is custom directive specific. if you're talking about testing something else, if you could take a moment to re-explain your issue I'm sure we can give you what you need. --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Testing custom configuration directives
Geoffrey Young wrote: Carletto wrote: Hi! Anyone has experience in testing an Apache module (mod_perl 2.0, of course) with custom configuration directives ? I'm talking about a module "packaged" (h2xs -AX -n Foo::Bar) and then tested (perl Makefile.PL; make; make test), when as custom configuration is like that: # file t/conf/extra.conf.in PerlModule Foo::Bar #PerlLoadModule Foo::Bar# if uncommented catch an error when "make test" MyFoo 30 SetHandler modperl PerlRequestHandler Foo::Bar Obviously the variable MyFoo is corrected "handled" in Foo/Bar.pm (see mod_perl 2.0 User's guide ch.6 for more details) but seems to be not work under a "packaged" module. So I can't test... only testing "by hand" (orribly long time operation..). I don't really understand what you mean by all this. are you saying you want to test whether MyFoo is "30" via "make test"? that's fairly simple to do. just use the "test from within a handler" approach when planning your tests - see t/response/TestDirective/perlloadmodule.pm for an example that is custom directive specific. if you're talking about testing something else, if you could take a moment to re-explain your issue I'm sure we can give you what you need. Carletto is talking about the live testing of a module that won't work without running mod_perl and he is not aware of Apache-Test, required for this kind of tests. Unfortunately apache.org is still down. But once it's up, Carletto please read: http://perl.apache.org/docs/general/testing/testing.html __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Testing custom configuration directives
>>> # file t/conf/extra.conf.in > Carletto is talking about the live testing of a module that won't work > without running mod_perl and he is not aware of Apache-Test, required > for this kind of tests. I was assuming from the above that he already had Apache-Test working. --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: VirtualHost + PerlSetVar
Stas Bekman wrote:
Paul G. Weiss wrote:
Rats! PerlPostConfigHandler appears to have absolutely no effect when
placed inside a scope. It does indeed run when placed
outside. I know this because I have something like:
open(H, ">", "/tmp/output");
print H "something\n"
in my handler and the file written to only when PerlPostConfigHandler
is outside the scope. By the way, this is also true
with PostOpenLogsHandler. In fact, when I set
PerlTrace all
in my configuration file, I see the line:
modperl_callback_run_handlers: no PerlPostConfigHandler handlers
configured ()
You are right. I added a test and it fails :( I was pretty sure that it
should have worked.
OK, we have to do it ourselves, which is easy (.e.g with the patch below). The
problem is this: all vhosts inherit PerlPostConfigHandler from the main server
and run it. They all inherit the PerlSetVar as well. I'm not sure this is the
wanted behavior. I suppose this is why Apache doesn't do it for each vhost.
Comments?
Index: src/modules/perl/mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.205
diff -u -r1.205 mod_perl.c
--- src/modules/perl/mod_perl.c 15 Dec 2003 08:24:57 - 1.205
+++ src/modules/perl/mod_perl.c 22 Dec 2003 03:31:13 -
@@ -588,6 +588,17 @@
ap_log_error(APLOG_MARK, APLOG_INFO, 0, s,
"mod_perl: using Perl HASH_SEED: %"UVuf, MP_init_hash_seed);
#endif
+
+/* run PerlPostConfigHandler for each vhost (apache already does
+ * that for the main server) */
+for (s=s->next; s; s=s->next) {
+int rc = modperl_callback_files(MP_POST_CONFIG_HANDLER,
+pconf, plog, ptemp, s,
+MP_HOOK_RUN_ALL);
+if (rc != OK) {
+return rc;
+}
+}
return OK;
}
Here is the test:
--- /dev/null 1969-12-31 16:00:00.0 -0800
+++ t/hooks/startup.t 2003-12-21 19:05:29.0 -0800
@@ -0,0 +1,28 @@
+
+use strict;
+use warnings FATAL => 'all';
+
+use Apache::Test;
+use Apache::TestUtil;
+use Apache::TestRequest;
+
+my $config = Apache::Test::config();
+my $path = Apache::TestRequest::module2path('TestHooks::startup');
+
+# XXX: vhosts are not run for postconfig at the moment
+my @modules = qw(default TestHooks::startup);
+#my @modules = qw(default TestHooks::);
+
+plan tests => scalar @modules;
+
+for my $module (sort @modules) {
+
+Apache::TestRequest::module($module);
+my $hostport = Apache::TestRequest::hostport($config);
+t_debug("connecting to $hostport");
+
+ok t_cmp("ok",
+ GET_BODY_ASSERT("http://$hostport/$path";),
+ "testing PostConfig");
+}
+
--- /dev/null 1969-12-31 16:00:00.0 -0800
+++ t/hooks/TestHooks/startup.pm2003-12-21 01:12:31.0 -0800
@@ -0,0 +1,89 @@
+package TestHooks::startup;
+
+use strict;
+use warnings FATAL => 'all';
+
+use Apache::TestUtil;
+use Apache::Test;
+use Apache::TestTrace;
+
+use APR::Table;
+use Apache::Server ();
+use Apache::ServerUtil ();
+use Apache::RequestRec ();
+use Apache::RequestIO ();
+
+use File::Spec::Functions qw(catfile catdir);
+use File::Path qw(mkpath);
+
+use Apache::Const -compile => 'OK';
+
+my $dir = catdir Apache::Test::config()->{vars}->{documentroot}, 'hooks',
+'startup';
+
+sub post_config {
+my($conf_pool, $log_pool, $temp_pool, $s) = @_;
+
+my $val = $s->dir_config->{PostConfig} or die "Can't read PostConfig var";
+debug "configuration is completed: $val";
+
+my $file = catfile $dir, $s->port;
+
+mkpath $dir, 0, 0755;
+open my $fh, ">$file" or die "can't open $file: $!";
+print $fh $val;
+close $fh;
+
+Apache::OK;
+}
+
+sub handler {
+my $r = shift;
+
+$r->content_type('text/plain');
+
+my $s = $r->server;
+my $expected = $s->dir_config->{PostConfig}
+or die "Can't read PostConfig var";
+my $port = $s->port;
+
+my $file = catfile $dir, $port;
+open my $fh, "$file" or die "can't open $file: $!";
+my $received = <$fh> || '';
+close $fh;
+
+# cleanup
+unlink $file;
+
+if ($expected eq $received) {
+$r->print("ok");
+}
+else {
+warn "port: $port";
+warn "expected: $expected\n";
+warn "received: $received\n";
+}
+
+Apache::OK;
+}
+
+1;
+__DATA__
+
+
+PerlSetVar PostConfig VHost
+PerlModule TestHooks::startup
+PerlPostConfigHandler TestHooks::startup::post_config
+
+SetHandler modperl
+PerlResponseHandler TestHooks::startup
+
+
+PerlSetVar PostConfig Main
+PerlModule TestHooks::startup
+PerlPostConfigHandler TestHooks::startup::post_config
+
+SetHandler modperl
+PerlResponseHandler TestHooks::startup
+
+
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.
getting any version of modperl to run
I had to setup an entire new computer and setup just to get mod_perl to work. My previous server is httpd 2.048 /PHP4.34/MySQL4.01 I tried to install mod_perl2 on this to get the Apache::Mp3 to work, but apparently mod_perl2 is not ready for prime time yet. There was no bloody way I was going to change my entire webserver from httpd 2.048 to the older Apache 1.3x just to get mod_perl to run. So I installed a new server with RH9, Apache 1.329, PHP4.34, MySQL 4.01 Then I tried to compile and get mod_perl 1.29 to run. PROBLEM: Basically Im trying to get Apache::MP3 to work, and that means first getting mod_perl to bloody run. Im new to mod_perl. I need my Apache to compile with --enable-modules=most and enable-module=mod_so But when mod_perl is compiled, it wants to rebuild the apache, and it doesnt compile any of these modules. So Apache is useless. I would prefer to load mod_perl as a DSO, but frankly I'd be happy even to see it work once.Getting frustrated. Even seeting up a qmail server makes more sense to me than mod_perl. Ranting==done. --- teddy mills http://www.vger.ca Family Guys Quagmire "a right" Capt Tenneal "LETS GO!" -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: VirtualHost + PerlSetVar
Let me see if I have this straight.
With your patch, if I have:
PerlPostConfigHandler A
PerlPostConfigHandler B
PerlPostConfigHandler C
then A gets run once, B gets run once, and C gets run once.
But if I have:
PerlPostConfigHandler A
PerlPostConfigHandler C
then A gets run twice (once for the main server and once for the vhost)
and C gets run once?
If so, that would be even more confusing, and any author of a
PostConfigHandler would need to make sure that the code is safe if run for
each vhost. I think that would cause more problems than it would solve.
In my case a better solution would be to write a PerlPostConfigHandler
that walked the config tree and did the right thing for each vhost. In
the case of Apache::PageKit, Boris Zenter has already posted a
workaround. An alternative to that would be something like this:
PerlPostConfigHandler PageKitHandler::handle
PerlSetVar PKIT_ROOT onevalue
PerlSetVar PKIT_SERVER serverone
PerlSetVar PKIT_ROOT twovalue
PerlSetVar PKIT_SERVER servervalue
sub handle {
my $tree = Apache::Directive->conftree;
my @pkitroots = $tree->lookup('PerlSetVar', 'PKIT_ROOT');
foreach my $node (@pkitroots) {
my $rootvalue = $node->args->[1];
my $servervalue;
my $sib = $node->parent->first_child;
while ($sib) {
if (lc $sib->directive eq 'perlsetvar' && $sub->args->[0] eq
'PKIT_SERVER') {
$servervalue = $sub->args->[1];
last;
}
$sib = $sib->next;
}
Apache::PageKit->startup($rootvalue, $servervalue);
}
In other words, look for places where PKIT_ROOT is set and then look up
the value of PKIT_SERVER set in the same scope, and call
Apache::PageKit->startup with both args.
Actually this doesn't quite work because if PKIT_SERVER is inherited from
an enclosing scope, then the code above won't find it -- it really should
recurse upward on the parent if it doesn't find a value for PKIT_SERVER.
Furthermore, it doesn't consider PerlAddVar. It would be nice if
Apache::Directive was extended so that one could do the equivalent of
$node->dir_config("value").
-P
On Sun, 21 Dec 2003 19:46:15 -0800, Stas Bekman <[EMAIL PROTECTED]> wrote:
Stas Bekman wrote:
Paul G. Weiss wrote:
Rats! PerlPostConfigHandler appears to have absolutely no effect when
placed inside a scope. It does indeed run when placed
outside. I know this because I have something like:
open(H, ">", "/tmp/output");
print H "something\n"
in my handler and the file written to only when PerlPostConfigHandler
is outside the scope. By the way, this is also true
with PostOpenLogsHandler. In fact, when I set
PerlTrace all
in my configuration file, I see the line:
modperl_callback_run_handlers: no PerlPostConfigHandler handlers
configured ()
You are right. I added a test and it fails :( I was pretty sure that it
should have worked.
OK, we have to do it ourselves, which is easy (.e.g with the patch
below). The problem is this: all vhosts inherit PerlPostConfigHandler
from the main server and run it. They all inherit the PerlSetVar as
well. I'm not sure this is the wanted behavior. I suppose this is why
Apache doesn't do it for each vhost. Comments?
Index: src/modules/perl/mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.205
diff -u -r1.205 mod_perl.c
--- src/modules/perl/mod_perl.c 15 Dec 2003 08:24:57 - 1.205
+++ src/modules/perl/mod_perl.c 22 Dec 2003 03:31:13 -
@@ -588,6 +588,17 @@
ap_log_error(APLOG_MARK, APLOG_INFO, 0, s,
"mod_perl: using Perl HASH_SEED: %"UVuf,
MP_init_hash_seed);
#endif
+
+/* run PerlPostConfigHandler for each vhost (apache already does
+ * that for the main server) */
+for (s=s->next; s; s=s->next) {
+int rc = modperl_callback_files(MP_POST_CONFIG_HANDLER,
+pconf, plog, ptemp, s,
+MP_HOOK_RUN_ALL);
+if (rc != OK) {
+return rc;
+}
+}
return OK;
}
Here is the test:
--- /dev/null 1969-12-31 16:00:00.0 -0800
+++ t/hooks/startup.t 2003-12-21 19:05:29.0 -0800
@@ -0,0 +1,28 @@
+
+use strict;
+use warnings FATAL => 'all';
+
+use Apache::Test;
+use Apache::TestUtil;
+use Apache::TestRequest;
+
+my $config = Apache::Test::config();
+my $path = Apache::TestRequest::module2path('TestHooks::startup');
+
+# XXX: vhosts are not run for postconfig at the moment
+my @modules = qw(default TestHooks::startup);
+#my @modules = qw(default TestHooks::);
+
+plan tests => scalar @modules;
+
+for my $module (sort @modules) {
+
+Apache::TestRequest::module($module);
+my $hostport = Apache::TestRequest::hostport($config);
+t_debug("connecting to $hostport");
+
+ok t_cmp("ok",
+ GET_BODY_ASSERT("http://$hostport/$path";),
+ "testing PostConfig");
+}
Re: getting any version of modperl to run
Teddy Mills wrote: I tried to install mod_perl2 on this to get the Apache::Mp3 to work, but apparently mod_perl2 is not ready for prime time yet. As I understand it, the issue is that Apache::MP3 does not have support for mod_perl 2 yet. There was no bloody way I was going to change my entire webserver from httpd 2.048 to the older Apache 1.3x just to get mod_perl to run. Sounds easier than installing a whole new server to me, unless you have a lot of apache 2-specific programs that you are committed to. You could also simply build apache 1.x/mod_perl 1.x in a different location on the same server and start it on port 8080 or something. So I installed a new server with RH9, Apache 1.329, PHP4.34, MySQL 4.01 Then I tried to compile and get mod_perl 1.29 to run. What instructions did you follow? There is a lot of information on installation here: http://perl.apache.org/docs/1.0/guide/install.html Also, although this is not mod_perl-specific, you should fix the locale problems with Red Hat 9's Perl: http://perl.apache.org/docs/1.0/guide/troubleshooting.html#RH_8_and_9_Locale_Issues I need my Apache to compile with --enable-modules=most and enable-module=mod_so Many people here use DSO builds, and there are full instructions at the link above. (I always heard that qmail was really easy to install.) - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
