Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: ModPerl

apache2 or mod_perl2 oddball error

 

 

First page Previous page 1 2 Next page Last page  View All ModPerl modperl RSS feed   Index | Next | Previous | View Threaded


web at umich

Jun 16, 2011, 9:28 AM

Post #1 of 26 (1840 views)
Permalink
apache2 or mod_perl2 oddball error

I'm not sure this is the best place to ask about this problem, and
this is my first posting to this mailing list. I have already asked
the freebsd-questions mailing list about this, but have received no
replies as of this writing.

I'm running FreeBSD 8.2-STABLE #0: Thu Jun 9 09:25:05 EDT 2011 on i386
and I rebuilt all my ports from source shortly after the upgrade. I got
a weird error when I tried to start apache2 (using "% apachectl -t" first):

[Mon Jun 13 10:16:15 2011] [error] syntax error at (eval 21) line 1, near "require Apache2::Const -"\n
[Mon Jun 13 10:16:15 2011] [error] Can't load Perl module Apache2::Const -compile => ':common' for server localhost:80, exiting...

The Perl module in question is present here:

freebsd% ls -l /usr/local/lib/perl5/site_perl/5.14.0/mach/Apache2/Const.pm
-r--r--r-- 1 root wheel 25924 Jun 10 17:08 /usr/local/lib/perl5/site_perl/5.14.0/mach/Apache2/Const.pm

The httpd.conf file is unchanged and was working since from before
the upgrade.

In the /usr/local/etc/apache22/httpd.conf file are these lines among
several hundred other lines:

LoadModule perl_module libexec/apache22/mod_perl.so
Include etc/apache22/Includes/*.conf

The only reference to the Apache2::Const module is in an Apache
config include file:

PerlModule "Apache2::Const -compile => ':common'"

I have these FreeBSD ports installed among several hundred others:

perl-5.14.0
apache-2.2.19
ap22-mod_perl2-2.0.5,3

Neither of these two commands gave any output at all:

freebsd% perl -e 'use Apache2::Const qw( :common );
freebsd% perl -M'Apache2::Const -compile => qw(:common)' -e 1;

This command gave one line of output:

freebsd% perl -MApache2::Const -e 'print $Apache2::Const::VERSION, "\n"';
2.000005

The above problem did not occur before the upgrade when I was running:

perl-5.12.3
apache-2.2.17_1
ap22-mod_perl2-2.0.4_2,3

I don't know how to debug this problem. No log files in /var/log were
changed by running the apachectl(8) command and there have been no new
lines added to /var/log/httpd-error.log since I rebooted and shut down
apache2 on June 9th as part of the upgrade. Any and all ideas welcome.

Regards,

web...

--
William Bulley Email: web [at] umich

72 characters width template ----------------------------------------->|


fred at redhotpenguin

Jun 16, 2011, 10:56 AM

Post #2 of 26 (1809 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

On Thu, Jun 16, 2011 at 9:28 AM, William Bulley <web [at] umich> wrote:
> The httpd.conf file is unchanged and was working since from before
> the upgrade.
>
> In the /usr/local/etc/apache22/httpd.conf file are these lines among
> several hundred other lines:
>
>   LoadModule perl_module libexec/apache22/mod_perl.so
>   Include etc/apache22/Includes/*.conf
>
> The only reference to the Apache2::Const module is in an Apache
> config include file:
>
>   PerlModule "Apache2::Const -compile => ':common'"

Hmm, odd that it wouldn't work under 2.0.5 but it would under 2.0.4.
No idea why offhand. Do you use a startup.pl in your application?

>
> I have these FreeBSD ports installed among several hundred others:
>
>   perl-5.14.0
>   apache-2.2.19
>   ap22-mod_perl2-2.0.5,3


> Neither of these two commands gave any output at all:
>
>   freebsd% perl -e 'use Apache2::Const qw( :common );
>   freebsd% perl -M'Apache2::Const -compile => qw(:common)' -e 1;

You need to call these statements in the context of a mod_perl interpreter.


web at umich

Jun 16, 2011, 11:54 AM

Post #3 of 26 (1816 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

According to Fred Moyer <fred [at] redhotpenguin> on Thu, 06/16/11 at 13:56:
>
> Hmm, odd that it wouldn't work under 2.0.5 but it would under 2.0.4.

My point exactly... :-(

> No idea why offhand. Do you use a startup.pl in your application?

No. The application's URL points to a directory with Mason laden HTML
files starting with "index.html". Why do you ask?

> > Neither of these two commands gave any output at all:
> >
> > ? freebsd% perl -e 'use Apache2::Const qw( :common );
> > ? freebsd% perl -M'Apache2::Const -compile => qw(:common)' -e 1;
>
> You need to call these statements in the context of a mod_perl interpreter.

Forgive me, but I don't understand what you mean. :-(

Recall the error message:

freebsd# apachectl -t
[Thu Jun 16 14:29:15 2011] [error] syntax error at (eval 21) line 1, near "require Apache2::Const -"\n
[Thu Jun 16 14:29:15 2011] [error] Can't load Perl module Apache2::Const -compile => ':common' for server localhost, exiting...

I have just searched the entire application source hierarchy for the
string ":common" using the find(1) command. The only file that contains
that string is the apache Includes file which has not changed since my
system upgrade. Here are several of the lines in that file:

#begining of file
PerlModule ModPerl::Util
PerlModule Apache2::Request
PerlModule Apache2::RequestRec
PerlModule Apache2::RequestIO
PerlModule Apache2::RequestUtil
PerlModule Apache2::ServerUtil
PerlModule Apache2::Connection
PerlModule Apache2::Log
PerlModule Apache::Session
PerlModule APR::Table
PerlModule ModPerl::Registry
PerlModule "Apache2::Const -compile => ':common'" <<<<<<=======
PerlModule "APR::Const -compile => ':common'" <<<<<<=======

PerlModule Apache2::SiteControl
PerlModule HTML::Mason::ApacheHandler

# Uncomment this next line if you get errors from libapreq2
# about an 'undefined symbol'
# LoadModule apreq_module /usr/lib/apache2/modules/mod_apreq2.so
LoadModule apreq_module /usr/local/libexec/apache22/mod_apreq2.so
.
.
.

Later in this file (and elsewhere in the application) there are uses of,
and references to, Apache2::Const, but there are no references to the
APR::Const module. I have tried commenting these lines out and tried
removing the trailing parameters. In some of the many permutations of
these two lines, I get a successful parsing of the httpd.conf file, but
likely that is because I commented out the entire line. However, in
these cases, I get a dozen error lines like this one:

Attempt to free unreferenced scalar: SV 0x28bda050 during global destruction.

In no case do I get a successful launch of the apache server, nor do
I get any lines in the httpd_error.log file. Any other ideas?

Regards,

web...

--
William Bulley Email: web [at] umich

72 characters width template ----------------------------------------->|


web at umich

Jun 17, 2011, 9:34 AM

Post #4 of 26 (1807 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

According to Fred Moyer <fred [at] redhotpenguin> on Thu, 06/16/11 at 13:56:
>
> Hmm, odd that it wouldn't work under 2.0.5 but it would under 2.0.4.

I have spent some time today looking at the change logs for both
mod_perl2 and apache2 to see what, if anything, might point to a
change that could have produced my current problem. I found none.

I originally thought based on this error output from "apachectl -t":

[Mon Jun 13 10:16:15 2011] [error] syntax error at (eval 21) line 1, near "require Apache2::Const -"\n
[Mon Jun 13 10:16:15 2011] [error] Can't load Perl module Apache2::Const -compile => ':common' for server localhost:80, exiting...

that the problem stemmed from the first of these two lines:

PerlModule "Apache2::Const -compile => ':common'"
PerlModule "APR::Const -compile => ':common'"

which are found inside a *.conf file in the Includes directory of apache2.

BTW, these two lines are the only two lines in the entire source tree
of the application in question that contain the string ":common". But
since I am merely trying to launch the apache server, the Perl application
has not come into play yet, except for the parsing of the httpd.conf
file and the above mentioned include file found in the Includes directory.

When I comment out the first line, I get a similar error, but this time
it mentions the second line:

[Fri Jun 17 12:17:41 2011] [error] syntax error at (eval 21) line 1, near "require APR::Const -"\n
[Fri Jun 17 12:17:41 2011] [error] Can't load Perl module APR::Const -compile => ':common' for server localhost:80, exiting...

When I comment out the second line, I get this output on the console:

freebsd# apachectl -t
Use of uninitialized value in lc at /usr/local/lib/perl5/site_perl/5.14.0/Class/DBI.pm line 196.
Syntax OK
Attempt to free unreferenced scalar: SV 0x28bda050 during global destruction.
Attempt to free unreferenced scalar: SV 0x28be05b4 during global destruction.
Attempt to free unreferenced scalar: SV 0x28be080c during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1c21c during global destruction.
Attempt to free unreferenced scalar: SV 0x28d19e60 during global destruction.
Attempt to free unreferenced scalar: SV 0x28be076c during global destruction.
Attempt to free unreferenced scalar: SV 0x28be04ec during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1c208 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda7a8 during global destruction.
Attempt to free unreferenced scalar: SV 0x28be0708 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda618 during global destruction.

BTW: ignore the DBI error since that occurred when starting apache prior
to my system upgrade last week.

So the syntax is now okay, but something else breaks and the server fails
to start. It seems like there is something wrong with the handling of the
PerlModule directive. For example, is "require" parsing different from
"use" parsing?

I don't see how anything I have done, or the application that worked before
the upgrade, could be at fault here. Something in apache2 or mod_perl2 or
their APIs has changed, perhaps related to the newish Perl 5.14 version.

I don't know how to approach this other than by asking the mailing lists
for some guidance. Thanks for your help.

Regards,

web...

--
William Bulley Email: web [at] umich

72 characters width template ----------------------------------------->|


torsten.foertsch at gmx

Jun 17, 2011, 10:13 AM

Post #5 of 26 (1799 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

On Friday, June 17, 2011 18:34:07 William Bulley wrote:
> Something in apache2 or
> mod_perl2 or their APIs has changed, perhaps related to the newish
> Perl 5.14 version.

That may be the reason. 5.14 required some changes in the code. One half
of them went into modperl 2.0.5. It made 5.14rc2 compiled without
ithreads work with a preforked apache. The other half required for
worker-MPM and interpreter-pools will come with modperl 2.0.6.

I don't know whether these changes are present in the freebsd ports.

Further, I have tested only on my Linux boxes. In production I still run
perl 5.12.

If I were you I'd compile apache and modperl from scratch. Take the SVN
version of modperl. If the test suite reveals something it is a hint
where to dig further. If not try to create a small test case with the
error present and post it here.

Torsten Förtsch

--
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net


web at umich

Jun 17, 2011, 10:29 AM

Post #6 of 26 (1799 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

According to Torsten F?rtsch <torsten.foertsch [at] gmx> on Fri, 06/17/11 at 13:13:
>
> On Friday, June 17, 2011 18:34:07 William Bulley wrote:
> > Something in apache2 or
> > mod_perl2 or their APIs has changed, perhaps related to the newish
> > Perl 5.14 version.
>
> That may be the reason. 5.14 required some changes in the code. One half
> of them went into modperl 2.0.5. It made 5.14rc2 compiled without
> ithreads work with a preforked apache. The other half required for
> worker-MPM and interpreter-pools will come with modperl 2.0.6.

I did see one mention in the mod_perl change log:

Prepare modperl for the upcoming perl 5.14 [Torsten Foertsch

about Perl 5.14 so the change from 5.12 to 5.14 looks to be relevant.

> I don't know whether these changes are present in the freebsd ports.

I have Perl 5.14 compiled from source.
I have apache 2.2.19 compiled from source.
I have mod_perl2 2.0.5 compiled from source (with these patches):

% cat patch-Makefile.PL
--- m Wed May 18 11:55:48 2005
+++ Makefile.PL Wed May 18 11:56:07 2005
@@ -668,11 +668,11 @@
cd "$(MODPERL_SRC)" && $(MAKE)

modperl_lib_install:
- cd "$(MODPERL_SRC)" && $(MAKE) DESTDIR=$(DESTDIR) install
+# cd "$(MODPERL_SRC)" && $(MAKE) DESTDIR=$(DESTDIR) install

modperl_xs_h_install:
- @$(MKPATH) $(DESTDIR)$(MODPERL_AP_INCLUDEDIR)
- $(CP) $(MODPERL_XS_H_FILES) $(DESTDIR)$(MODPERL_AP_INCLUDEDIR)
+# @$(MKPATH) $(DESTDIR)$(MODPERL_AP_INCLUDEDIR)
+# $(CP) $(MODPERL_XS_H_FILES) $(DESTDIR)$(MODPERL_AP_INCLUDEDIR)

modperl_src_clean:
cd "$(MODPERL_SRC)" && $(MAKE) clean

but those changes look to be FreeBSD specific.

> Further, I have tested only on my Linux boxes. In production I still run
> perl 5.12.

It would be a fairly large amount of work for me to revert to Perl 5.12... :-(

> If I were you I'd compile apache and modperl from scratch. Take the SVN
> version of modperl. If the test suite reveals something it is a hint
> where to dig further. If not try to create a small test case with the
> error present and post it here.

Well, all my FreeBSD ports (including apache2 and mod_perls in this case)
are compiled from source. I could rebuild them and see if there are any
testing errors. I wouldn't know how to craft a small test case since my
aim here is just to get apache2 to launch - which unfortunately it won't... :-(

Regards,

web...

--
William Bulley Email: web [at] umich

72 characters width template ----------------------------------------->|


fred at redhotpenguin

Jun 17, 2011, 10:43 AM

Post #7 of 26 (1796 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

On Fri, Jun 17, 2011 at 10:29 AM, William Bulley <web [at] umich> wrote:
> I have Perl 5.14 compiled from source.
> I have apache 2.2.19  compiled from source.
> I have mod_perl2 2.0.5 compiled from source (with these patches):

Can you pull 2.0.6-dev from svn and build?

http://perl.apache.org/download/source.html

% svn checkout https://svn.apache.org/repos/asf/perl/modperl/trunk/
mod_perl-2.0


perrin at elem

Jun 17, 2011, 10:44 AM

Post #8 of 26 (1799 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

On Fri, Jun 17, 2011 at 12:34 PM, William Bulley <web [at] umich> wrote:
>   PerlModule "Apache2::Const -compile => ':common'"
>   PerlModule "APR::Const -compile => ':common'"

That syntax used to work? It seems unlikely. I've never seen a
PerlModule call with options like this before. I'd expect it to work
without the "-compile => ':common'" stuff.

This sort of thing usually goes in a startup.pl, not inside
httpd.conf. It's easier to manage there and things don't get pulled
into surprising namespaces.

- Perrin


web at umich

Jun 17, 2011, 11:11 AM

Post #9 of 26 (1798 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

According to Fred Moyer <fred [at] redhotpenguin> on Fri, 06/17/11 at 13:43:
>
> On Fri, Jun 17, 2011 at 10:29 AM, William Bulley <web [at] umich> wrote:
> > I have Perl 5.14 compiled from source.
> > I have apache 2.2.19 ?compiled from source.
> > I have mod_perl2 2.0.5 compiled from source (with these patches):
>
> Can you pull 2.0.6-dev from svn and build?
>
> http://perl.apache.org/download/source.html
>
> % svn checkout https://svn.apache.org/repos/asf/perl/modperl/trunk/
> mod_perl-2.0

I will certainly attempt to do so. Stay tuned... ;-)

Regards,

web...

--
William Bulley Email: web [at] umich

72 characters width template ----------------------------------------->|


web at umich

Jun 17, 2011, 11:13 AM

Post #10 of 26 (1810 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

According to "James B. Muir" <James.B.Muir [at] hitchcock> on Fri, 06/17/11 at 13:29:
>
> Have you checked the permissions on the Const.pm module?

freebsd% ls -l /usr/local/lib/perl5/site_perl/5.14.0/mach/APR/Const.pm \
/usr/local/lib/perl5/site_perl/5.14.0/mach/Apache2/Const.pm \
/usr/local/lib/perl5/site_perl/5.14.0/mach/ModPerl/Const.pm
-r--r--r-- 1 root wheel 23410 Jun 10 17:08 /usr/local/lib/perl5/site_perl/5.14.0/mach/APR/Const.pm
-r--r--r-- 1 root wheel 25924 Jun 10 17:08 /usr/local/lib/perl5/site_perl/5.14.0/mach/Apache2/Const.pm
-r--r--r-- 1 root wheel 3080 Jun 10 17:08 /usr/local/lib/perl5/site_perl/5.14.0/mach/ModPerl/Const.pm


Regards,

web...

--
William Bulley Email: web [at] umich

72 characters width template ----------------------------------------->|


web at umich

Jun 17, 2011, 11:18 AM

Post #11 of 26 (1795 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

According to Perrin Harkins <perrin [at] elem> on Fri, 06/17/11 at 13:44:
>
> On Fri, Jun 17, 2011 at 12:34 PM, William Bulley <web [at] umich> wrote:
> > ? PerlModule "Apache2::Const -compile => ':common'"
> > ? PerlModule "APR::Const -compile => ':common'"
>
> That syntax used to work? It seems unlikely. I've never seen a
> PerlModule call with options like this before. I'd expect it to work
> without the "-compile => ':common'" stuff.
>
> This sort of thing usually goes in a startup.pl, not inside
> httpd.conf. It's easier to manage there and things don't get pulled
> into surprising namespaces.

Yes. Yes. Yes! :-)

This is what is so consternating for me to grok.

Others have suggested that I strip the parameters - I did and no change.

Others suggested I place the module(s) invocation inside (the existing)
<Perl>...</Perl> tags - I did and no change. Go figure?

Those two "Const -compile" lines were not in the httpd.conf file.

They were in an included *.conf file in the Includes directory
which might be the same thing, but I'm a pedantic sort of guy... :-)

Regards,

web...

--
William Bulley Email: web [at] umich

72 characters width template ----------------------------------------->|


perrin at elem

Jun 17, 2011, 11:24 AM

Post #12 of 26 (1795 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

On Fri, Jun 17, 2011 at 2:18 PM, William Bulley <web [at] umich> wrote:
> Others have suggested that I strip the parameters - I did and no change.
>
> Others suggested I place the module(s) invocation inside (the existing)
> <Perl>...</Perl> tags - I did and no change.  Go figure?

Have you tried making a startup.pl and calling these from there with use() ?

> They were in an included *.conf file in the Includes directory
> which might be the same thing, but I'm a pedantic sort of guy...  :-)

In terms of how mod_perl treats them, that shouldn't make a difference here.

- Perrin


web at umich

Jun 17, 2011, 12:20 PM

Post #13 of 26 (1798 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

According to Perrin Harkins <perrin [at] elem> on Fri, 06/17/11 at 14:24:
>
> Have you tried making a startup.pl and calling these from there with use() ?

Recall that all I'm trying to do at this point is to get the apache
server up and running. The fact that these two lines in this include
file of this particular application case "apachectl -t" to error out
should have nothing to do with the application and how it does or does
not start up.

Are you saying that a suitably constructed startup.pl file with these
two lines included would be useful to debugging this problem? If so,
then what all does one need in a standard startup.pl, for example, that
I could use as a model? Thanks.

Regards,

web...

--
William Bulley Email: web [at] umich

72 characters width template ----------------------------------------->|


perrin at elem

Jun 17, 2011, 12:35 PM

Post #14 of 26 (1797 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

On Fri, Jun 17, 2011 at 3:20 PM, William Bulley <web [at] umich> wrote:
> Recall that all I'm trying to do at this point is to get the apache
> server up and running.  The fact that these two lines in this include
> file of this particular application case "apachectl -t" to error out
> should have nothing to do with the application and how it does or does
> not start up.

Well, presumably they compile constants that your code needs. But I
see that you tried commenting them out, which is a good idea, and then
got some unreferenced scalar errors, which were not related to these
lines.

I'd probably try stripping down your conf file to try to find what
causes these errors, taking out chunks of mod_perl-related stuff until
it starts without complaint.

- Perrin


web at umich

Jun 17, 2011, 1:09 PM

Post #15 of 26 (1798 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

According to Fred Moyer <fred [at] redhotpenguin> on Fri, 06/17/11 at 13:43:
>
> On Fri, Jun 17, 2011 at 10:29 AM, William Bulley <web [at] umich> wrote:
> > I have Perl 5.14 compiled from source.
> > I have apache 2.2.19 ?compiled from source.
> > I have mod_perl2 2.0.5 compiled from source (with these patches):
>
> Can you pull 2.0.6-dev from svn and build?
>
> http://perl.apache.org/download/source.html
>
> % svn checkout https://svn.apache.org/repos/asf/perl/modperl/trunk/
> mod_perl-2.0

I have just built/installed mod_perl-2.0.6 (not sure about the dev part)
and tried again to start the apache server (using "# apachectl -t"):

[Fri Jun 17 16:05:58 2011] [error] syntax error at (eval 21) line 1, near "require Apache2::Const -"\n
[Fri Jun 17 16:05:58 2011] [error] Can't load Perl module Apache2::Const -compile => ':common' for server localhost:80, exiting...

This is very frustrating... :-(

Regards,

web...

--
William Bulley Email: web [at] umich

72 characters width template ----------------------------------------->|


fred at redhotpenguin

Jun 17, 2011, 1:22 PM

Post #16 of 26 (1796 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

I think Perrin is right, I've never seen -compile syntax used in
PerlModule directives. Move the PerlModule directives into a
startup.pl file.

In your httpd.conf:

LoadModule perl_module modules/mod_perl.so
PerlPostConfigRequire /my/startup.pl

In your startup.pl:

#!/usr/bin/perl

use strict;
use warnings;

# make sure we are in a sane environment.
$ENV{MOD_PERL} or die "GATEWAY_INTERFACE not Perl!";

use Apache2::Const -compile => ':common';

... add any other PerlModule statements in the 'use Module' format.

On Fri, Jun 17, 2011 at 1:09 PM, William Bulley <web [at] umich> wrote:
> According to Fred Moyer <fred [at] redhotpenguin> on Fri, 06/17/11 at 13:43:
>>
>> On Fri, Jun 17, 2011 at 10:29 AM, William Bulley <web [at] umich> wrote:
>> > I have Perl 5.14 compiled from source.
>> > I have apache 2.2.19 ?compiled from source.
>> > I have mod_perl2 2.0.5 compiled from source (with these patches):
>>
>> Can you pull 2.0.6-dev from svn and build?
>>
>> http://perl.apache.org/download/source.html
>>
>>   % svn checkout https://svn.apache.org/repos/asf/perl/modperl/trunk/
>> mod_perl-2.0
>
> I have just built/installed mod_perl-2.0.6 (not sure about the dev part)
> and tried again to start the apache server (using "# apachectl -t"):
>
>   [Fri Jun 17 16:05:58 2011] [error] syntax error at (eval 21) line 1, near "require Apache2::Const -"\n
>   [Fri Jun 17 16:05:58 2011] [error] Can't load Perl module Apache2::Const -compile => ':common' for server localhost:80, exiting...
>
> This is very frustrating...  :-(
>
> Regards,
>
> web...
>
> --
> William Bulley                     Email: web [at] umich
>
> 72 characters width template ----------------------------------------->|
>


web at umich

Jun 17, 2011, 2:05 PM

Post #17 of 26 (1797 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

According to Fred Moyer <fred [at] redhotpenguin> on Fri, 06/17/11 at 16:22:
>
> I think Perrin is right, I've never seen -compile syntax used in
> PerlModule directives. Move the PerlModule directives into a
> startup.pl file.
>
> In your httpd.conf:
>
> LoadModule perl_module modules/mod_perl.so
> PerlPostConfigRequire /my/startup.pl
>
> In your startup.pl:
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> # make sure we are in a sane environment.
> $ENV{MOD_PERL} or die "GATEWAY_INTERFACE not Perl!";
>
> use Apache2::Const -compile => ':common';
>
> ... add any other PerlModule statements in the 'use Module' format.

Fine. But what has this got to do with the inability of the apache
server to start? These PerlModule directives are not my idea. They
came with the application in question (to which I am trying to get).

Once I get the apache server running, I can deal with issues like
this one. BTW, the application in question does not have a startup
file, it just has an index.html file and uses Mason, but that is
neither here nor there as far as this problem is concerned.

Recall that with these two "Const -compile" lines commented out
of that include file, the syntax phase of "apachectl -t" succeeds,
but the server does not start, and a bunch of other errors appear.

This, to me, sounds like an issue between apache2 and Perl 5.14 or
between mod_perl2 and Perl 5.14, but I don't really have any clue.

Regards,

web...

--
William Bulley Email: web [at] umich

72 characters width template ----------------------------------------->|


web at umich

Jun 17, 2011, 8:50 PM

Post #18 of 26 (1797 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

According to Perrin Harkins <perrin [at] elem> on Fri, 06/17/11 at 15:35:
>
> On Fri, Jun 17, 2011 at 3:20 PM, William Bulley <web [at] umich> wrote:
> > Recall that all I'm trying to do at this point is to get the apache
> > server up and running. ?The fact that these two lines in this include
> > file of this particular application case "apachectl -t" to error out
> > should have nothing to do with the application and how it does or does
> > not start up.
>
> Well, presumably they compile constants that your code needs. But I
> see that you tried commenting them out, which is a good idea, and then
> got some unreferenced scalar errors, which were not related to these
> lines.
>
> I'd probably try stripping down your conf file to try to find what
> causes these errors, taking out chunks of mod_perl-related stuff until
> it starts without complaint.

Excellent suggestion! Thanks! :-)

This is where I will pick up the reins when I next return to this
effort. I'll report back here what I find out. Thanks again.

Regards,

web...

--
William Bulley Email: web [at] umich

72 characters width template ----------------------------------------->|


aw at ice-sa

Jun 19, 2011, 2:52 PM

Post #19 of 26 (1780 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

William Bulley wrote:
> According to Perrin Harkins <perrin [at] elem> on Fri, 06/17/11 at 15:35:
>> On Fri, Jun 17, 2011 at 3:20 PM, William Bulley <web [at] umich> wrote:
>>> Recall that all I'm trying to do at this point is to get the apache
>>> server up and running. ?The fact that these two lines in this include
>>> file of this particular application case "apachectl -t" to error out
>>> should have nothing to do with the application and how it does or does
>>> not start up.

Hi.
I am not really a mod_perl guru; I've just been using it for 10 years or so.
But let me maybe explain something in a probably not very accurate way, but which maybe
can explain what you are seeing.

When Apache executes a LoadModule directive, it not only loads that module code in memory.
The module code also gets called at that point, and in return the module tells Apache
which further configuration directives "it is interested in".
For example, when Apache encounters "LoadModule mod_perl.so", mod_perl gets loaded, and
tells Apache that it is interested in processing further directives such as "PerlModule",
PerlRequire, PerlSetVar, etc.. (all the other mod_perl specific directives).
(Otherwise,Apache would not "know" these directives, and would flag them as errors right
away).
Subsequently, when Apache detects one of these module-specific directives, it passes the
directive line to mod_perl, to parse and interpret that line.
If mod_perl then detects a syntax (or other) error in that line, it returns an error
status to Apache, and Apache as a result refuses to continue parsing the Apache
configuration file, and refuses to start.

In other words, maybe for mod_perl 5.x, a directive such as
PerlModule "Apache2::Const -compile => ':common'"
may have been acceptable, and did not cause mod_perl to return an error to Apache.
But for mod_perl 5.x+1, that same form is not acceptable anymore, and returns an error.
And *that* is what prevents Apache to start.

Personally, I have never seen before a PerlModule directive like
PerlModule "Apache2::Const -compile => ':common'"
In an Apache configuration file, I have always seem only PerlModule directives like
PerlModule Apache2::Const
(and that is also what the on-line mod_perl documentation seems to indicate as the valid
format, see http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlModule_)

So, if you just remove the "-compile => ':common'" part, does Apache still fail to start
(at the same point I mean) ?

That you may then see errors at some other point (because of the missing "-compile =>
':common'") is a different matter, and can be resolved separately.


web at umich

Jun 21, 2011, 5:05 AM

Post #20 of 26 (1773 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

According to Andr? Warnier <aw [at] ice-sa> on Sun, 06/19/11 at 17:52:
>
> When Apache executes a LoadModule directive, it not only loads that module
> code in memory. The module code also gets called at that point, and in
> return the module tells Apache which further configuration directives "it
> is interested in".
> For example, when Apache encounters "LoadModule mod_perl.so", mod_perl gets
> loaded, and tells Apache that it is interested in processing further
> directives such as "PerlModule", PerlRequire, PerlSetVar, etc.. (all the
> other mod_perl specific directives).
> (Otherwise,Apache would not "know" these directives, and would flag them as
> errors right away).
> Subsequently, when Apache detects one of these module-specific directives,
> it passes the directive line to mod_perl, to parse and interpret that line.
> If mod_perl then detects a syntax (or other) error in that line, it returns
> an error status to Apache, and Apache as a result refuses to continue
> parsing the Apache configuration file, and refuses to start.

Thanks. This is very educational information.

> In other words, maybe for mod_perl 5.x, a directive such as
> PerlModule "Apache2::Const -compile => ':common'"
> may have been acceptable, and did not cause mod_perl to return an error to
> Apache.
> But for mod_perl 5.x+1, that same form is not acceptable anymore, and
> returns an error.
> And *that* is what prevents Apache to start.

Well, I believe that isn't the problem here, but I'm still struggling
with the problem.

> Personally, I have never seen before a PerlModule directive like
> PerlModule "Apache2::Const -compile => ':common'"
> In an Apache configuration file, I have always seem only PerlModule
> directives like
> PerlModule Apache2::Const
> (and that is also what the on-line mod_perl documentation seems to indicate
> as the valid format, see
> http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlModule_)

Thanks. I did not write that line. The include file where that line is
found came with the application that requires mod_perl. Prior to using
this application I had no need to use mod_perl. Talk about a trial by fire...

Perhaps the reason that syntax is used may have come from this POD:

<http://search.cpan.org/~phred/mod_perl-2.0.5/docs/api/Apache2/Const.pod#:common>

> So, if you just remove the "-compile => ':common'" part, does Apache still
> fail to start (at the same point I mean) ?

You may have missed my earlier replies, or maybe I've lost track which list
I have been posting to (I've tried both apache and mod_perl lists to date).

This suggestion was given earlier and I tried it late last week to no avail.
I still got the same error complaining about the Apache2::Const module.
My belief is that something in Perl 5.14 is causing this problem since when
I renamed the include file in question (effectively removing it from the
list of *.conf files that httpd.conf was told to read), the problem went
away! I was able to start the apache server (several processes running)
and exercised it with other HTML files (not the application in question).

> That you may then see errors at some other point (because of the missing
> "-compile => ':common'") is a different matter, and can be resolved
> separately.

If I knew how to track down this problem further, I would be happy to,
but this is all new territory for me. I am now contemplating rebuilding
my system from scratch using Perl 5.12.3 which worked (in the apache
sense) prior to my June 9th upgrade. Unfortunately, this is a vary large
task and deprives me of some of the things in Perl 5.14 that might be
good to have. Of course, if this is a 5.14 problem, then I should do
the down-grade, but not knowing is making this decision more difficult.

Regards,

web...

--
William Bulley Email: web [at] umich

72 characters width template ----------------------------------------->|


perrin at elem

Jun 21, 2011, 8:57 AM

Post #21 of 26 (1784 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

On Tue, Jun 21, 2011 at 8:05 AM, William Bulley <web [at] umich> wrote:
>> So, if you just remove the "-compile => ':common'" part, does Apache still
>> fail to start (at the same point I mean) ?
[...]
> This suggestion was given earlier and I tried it late last week to no avail.
> I still got the same error complaining about the Apache2::Const module.

Maybe I'm the one confused now, but I thought you said that when you
removed that the application started and those errors about the
modules went away. You said that instead you got errors about
"unreferenced scalar" stuff when apache shut down. Have you checked
to see if the application works at that point?

- Perrin


aw at ice-sa

Jun 21, 2011, 9:05 AM

Post #22 of 26 (1774 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

William Bulley wrote:
...

>
> Perhaps the reason that syntax is used may have come from this POD:
>
> <http://search.cpan.org/~phred/mod_perl-2.0.5/docs/api/Apache2/Const.pod#:common>
>
Right, but what that page is showing, is the syntax of the perl "use some::module;"
directive, as used /inside of a perl program/.
Here we are talking about the "PerlModule" directive, as used in a httpd.conf file (or
another file included in it).

Although the effect of each of these instructions is quite similar, the allowable syntax
in each case may be different.

Referring again to the page
http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlModule_

One sees there an example of a PerlModule directive with several parameters after the
"PerlModule" directive itself. But these additional parameters are, all and each of them,
names of perl modules (aka "libraries") to be loaded. They are /not/ additional
parameters to the first named module.
Damn, this is probably obscure for a non-perl practitioner. Let me try again :

in a line like
use Apache2::Const -compile => ':common';
(which you would use in a perl script, not in an Apache configuration file)
- the "use Apache2::Const" part means : load the module "Apache2::Const"
- and the "-compile => ':common'" part means : /in addition/ to loading the Apache2::Const
module itself, also "prepare" a set of symbols from that module, so as to make them easier
to use in the program which executes the "use" directive. (*)

On the other hand, in an Apache configuration file, you cannot use the "use" directive,
you must use the "PerlModule" directive. But this PerlModule directive has no valid
syntax to allow the second part ("-compile => ':common'").

Ok so far ?

So how would you find a way to tell Apache and mod_perl to load the Apache2::Const module,
but /also/ do the "-compile => ':common'" part ?

Fortunately, in Perl there is always more than one way to do it.
That's where the already-named "startup.pl" script comes into play, along with the
"PerlRequire" directive.

By using the Apache/mod_perl configuration directive
PerlRequire "/path/to/some/script.pl"
you tell Apache and mod_perl to also compile and run the named script, /during the Apache
configuration phase/. And in this script, you can use the line :
use Apache2::Const -compile => ':common';
(because in a Perl script the "use" directive /can/ be used, with the additional
parameters and all).

(Note: the name of this script is often "startup.pl", but that is only a convention, and
you can use any script name you like, as long as the PerlRequire directive points to it).
(Note also that it does not matter that the rest of the application never references this
script; it is executed /once/ during the configuration phase of Apache, and just sets
things up for the rest of the life of this Apache/mod_perl server).


In other words, to summarise (and this is only a repeat of what someone else wrote
earlier), do as follows :

- create a simple perl script, for example as "/etc/apache2/mod_perl_startup.pl", as Fred
Moyer told you how to in a reply dated 17/06 22:22.
- remove the corresponding PerlModule line from the Apache configuration file (or comment
it out)
- add the above "PerlRequire" line to your Apache configuration

The fundamental effect should be the same, but the perl language "use" directive allows
for additional parameters such as "-compile", while this is less than certain for the
Apache/mod_perl "PerlModule" configuration directive.


(*) for example, it means that in all other perl programs, modules, scripts running under
your Apache/mod_perl, you can now use :

return OK;

instead of the longer

return Apache2::Const::OK;


web at umich

Jun 21, 2011, 9:16 AM

Post #23 of 26 (1779 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

According to Perrin Harkins <perrin [at] elem> on Tue, 06/21/11 at 11:57:
>
> Maybe I'm the one confused now, but I thought you said that when you
> removed that the application started and those errors about the
> modules went away. You said that instead you got errors about
> "unreferenced scalar" stuff when apache shut down. Have you checked
> to see if the application works at that point?

I may have mis-spoken. A lot of different tests and hair pulling here...

When the -compile parameters are removed, I get this:

Syntax OK.
Attempt to free unreferenced scalar: SV 0x28be1014 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda578 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda7d0 during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1b3e8 during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1b050 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda730 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda4b0 during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1b3d4 during global destruction.
Attempt to free unreferenced scalar: SV 0x28be176c during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda6cc during global destruction.
Attempt to free unreferenced scalar: SV 0x28be15dc during global destruction.

and the server does not start. I am becoming more and more convinced
that I will have to revert to 5.12.3 version of Perl...

Regards,

web...

--
William Bulley Email: web [at] umich

72 characters width template ----------------------------------------->|


web at umich

Jun 21, 2011, 9:51 AM

Post #24 of 26 (1775 views)
Permalink
Re: apache2 or mod_perl2 oddball error [In reply to]

According to Andr? Warnier <aw [at] ice-sa> on Tue, 06/21/11 at 12:05:
>
> Right, but what that page is showing, is the syntax of the perl "use
> some::module;" directive, as used /inside of a perl program/.
> Here we are talking about the "PerlModule" directive, as used in a
> httpd.conf file (or another file included in it).

I got that.

> Although the effect of each of these instructions is quite similar, the
> allowable syntax in each case may be different.
>
> Referring again to the page
> http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlModule_
>
> One sees there an example of a PerlModule directive with several parameters
> after the "PerlModule" directive itself. But these additional parameters
> are, all and each of them, names of perl modules (aka "libraries") to be
> loaded. They are /not/ additional parameters to the first named module.
> Damn, this is probably obscure for a non-perl practitioner. Let me try
> again :
>
> in a line like
> use Apache2::Const -compile => ':common';
> (which you would use in a perl script, not in an Apache configuration file)
> - the "use Apache2::Const" part means : load the module "Apache2::Const"
> - and the "-compile => ':common'" part means : /in addition/ to loading the
> Apache2::Const module itself, also "prepare" a set of symbols from that
> module, so as to make them easier to use in the program which executes the
> "use" directive. (*)

I think the person who wrote these lines:

PerlModule "Apache2::Const -compile => ':common'"
PerlModule "APR::Const -compile => ':common'"

was trying to say: "I'm only interested in those symbols associated with
the ':common' tag, so please load only those (in addition to the module)."

But this is neither here nor there, since when I reduce those two lines to:

PerlModule Apache2::Const
PerlModule APR::Const

and re-run "# apachectl -t" the syntax is clean, but the server fails to
start (which was my original complaint):

Syntax OK
Attempt to free unreferenced scalar: SV 0x28be1014 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda578 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda7d0 during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1b3e8 during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1b050 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda730 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda4b0 during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1b3d4 during global destruction.
Attempt to free unreferenced scalar: SV 0x28be176c during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda6cc during global destruction.
Attempt to free unreferenced scalar: SV 0x28be15dc during global destruction.


> On the other hand, in an Apache configuration file, you cannot use the
> "use" directive, you must use the "PerlModule" directive. But this
> PerlModule directive has no valid syntax to allow the second part
> ("-compile => ':common'").
>
> Ok so far ?

I got that.

> So how would you find a way to tell Apache and mod_perl to load the
> Apache2::Const module, but /also/ do the "-compile => ':common'" part ?
>
> Fortunately, in Perl there is always more than one way to do it.
> That's where the already-named "startup.pl" script comes into play, along
> with the "PerlRequire" directive.

The include file in question has a <Perl>...</Perl> section. So I tried
putting the "use...-common => ':common'" inside there (two lines). Then
running the apachectl(8) command, I got the same results as above. Still
no joy.

I got farther along just by renaming the include file so that apache2
could not see it (but of course this screws the pooch for the application
in question). After the renaming, "# apachectl start" succeeded.

> By using the Apache/mod_perl configuration directive
> PerlRequire "/path/to/some/script.pl"
> you tell Apache and mod_perl to also compile and run the named script,
> /during the Apache configuration phase/. And in this script, you can use
> the line :
> use Apache2::Const -compile => ':common';
> (because in a Perl script the "use" directive /can/ be used, with the
> additional parameters and all).

See above.

> (Note: the name of this script is often "startup.pl", but that is only a
> convention, and you can use any script name you like, as long as the
> PerlRequire directive points to it).

I do this for Perl applications that I write.

> (Note also that it does not matter that the rest of the application never
> references this script; it is executed /once/ during the configuration
> phase of Apache, and just sets things up for the rest of the life of this
> Apache/mod_perl server).

I got that.

> In other words, to summarise (and this is only a repeat of what someone
> else wrote earlier), do as follows :
>
> - create a simple perl script, for example as
> "/etc/apache2/mod_perl_startup.pl", as Fred Moyer told you how to in a
> reply dated 17/06 22:22.
> - remove the corresponding PerlModule line from the Apache configuration
> file (or comment it out)
> - add the above "PerlRequire" line to your Apache configuration
>
> The fundamental effect should be the same, but the perl language "use"
> directive allows for additional parameters such as "-compile", while this
> is less than certain for the Apache/mod_perl "PerlModule" configuration
> directive.
>
> (*) for example, it means that in all other perl programs, modules, scripts
> running under your Apache/mod_perl, you can now use :
>
> return OK;
>
> instead of the longer
>
> return Apache2::Const::OK;

I am still at a loss as to how to proceed. Ignoring the Apache2::Const
and APR::Const issues, the apache2 server still fails to start. And I
don't know how to track down the problem. Changing "Loglevel" to "debug"
in the httpd.conf file did not result in any errors logged to my apache
error log file (since the server failed to run). Is this still a Perl
problem or could it be a mod_perl2 problem? And how to debug it?

Regards,

web...

--
William Bulley Email: web [at] umich

72 characters width template ----------------------------------------->|


James.B.Muir at hitchcock

Jun 21, 2011, 9:57 AM

Post #25 of 26 (1774 views)
Permalink
RE: apache2 or mod_perl2 oddball error [In reply to]

Getting back to basics... Are you sure that your build of Apache and perl went well? Have you scrutinized the logs you created when you built perl and apache for any surprising error messages?
-James


-----Original Message-----
From: William Bulley [mailto:web [at] umich]
Sent: Tuesday, June 21, 2011 12:51 PM
To: Andr? Warnier
Cc: mod_perl list
Subject: Re: apache2 or mod_perl2 oddball error

According to Andr? Warnier <aw [at] ice-sa> on Tue, 06/21/11 at 12:05:
>
> Right, but what that page is showing, is the syntax of the perl "use
> some::module;" directive, as used /inside of a perl program/.
> Here we are talking about the "PerlModule" directive, as used in a
> httpd.conf file (or another file included in it).

I got that.

> Although the effect of each of these instructions is quite similar, the
> allowable syntax in each case may be different.
>
> Referring again to the page
> http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlModule_
>
> One sees there an example of a PerlModule directive with several parameters
> after the "PerlModule" directive itself. But these additional parameters
> are, all and each of them, names of perl modules (aka "libraries") to be
> loaded. They are /not/ additional parameters to the first named module.
> Damn, this is probably obscure for a non-perl practitioner. Let me try
> again :
>
> in a line like
> use Apache2::Const -compile => ':common';
> (which you would use in a perl script, not in an Apache configuration file)
> - the "use Apache2::Const" part means : load the module "Apache2::Const"
> - and the "-compile => ':common'" part means : /in addition/ to loading the
> Apache2::Const module itself, also "prepare" a set of symbols from that
> module, so as to make them easier to use in the program which executes the
> "use" directive. (*)

I think the person who wrote these lines:

PerlModule "Apache2::Const -compile => ':common'"
PerlModule "APR::Const -compile => ':common'"

was trying to say: "I'm only interested in those symbols associated with
the ':common' tag, so please load only those (in addition to the module)."

But this is neither here nor there, since when I reduce those two lines to:

PerlModule Apache2::Const
PerlModule APR::Const

and re-run "# apachectl -t" the syntax is clean, but the server fails to
start (which was my original complaint):

Syntax OK
Attempt to free unreferenced scalar: SV 0x28be1014 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda578 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda7d0 during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1b3e8 during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1b050 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda730 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda4b0 during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1b3d4 during global destruction.
Attempt to free unreferenced scalar: SV 0x28be176c during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda6cc during global destruction.
Attempt to free unreferenced scalar: SV 0x28be15dc during global destruction.


> On the other hand, in an Apache configuration file, you cannot use the
> "use" directive, you must use the "PerlModule" directive. But this
> PerlModule directive has no valid syntax to allow the second part
> ("-compile => ':common'").
>
> Ok so far ?

I got that.

> So how would you find a way to tell Apache and mod_perl to load the
> Apache2::Const module, but /also/ do the "-compile => ':common'" part ?
>
> Fortunately, in Perl there is always more than one way to do it.
> That's where the already-named "startup.pl" script comes into play, along
> with the "PerlRequire" directive.

The include file in question has a <Perl>...</Perl> section. So I tried
putting the "use...-common => ':common'" inside there (two lines). Then
running the apachectl(8) command, I got the same results as above. Still
no joy.

I got farther along just by renaming the include file so that apache2
could not see it (but of course this screws the pooch for the application
in question). After the renaming, "# apachectl start" succeeded.

> By using the Apache/mod_perl configuration directive
> PerlRequire "/path/to/some/script.pl"
> you tell Apache and mod_perl to also compile and run the named script,
> /during the Apache configuration phase/. And in this script, you can use
> the line :
> use Apache2::Const -compile => ':common';
> (because in a Perl script the "use" directive /can/ be used, with the
> additional parameters and all).

See above.

> (Note: the name of this script is often "startup.pl", but that is only a
> convention, and you can use any script name you like, as long as the
> PerlRequire directive points to it).

I do this for Perl applications that I write.

> (Note also that it does not matter that the rest of the application never
> references this script; it is executed /once/ during the configuration
> phase of Apache, and just sets things up for the rest of the life of this
> Apache/mod_perl server).

I got that.

> In other words, to summarise (and this is only a repeat of what someone
> else wrote earlier), do as follows :
>
> - create a simple perl script, for example as
> "/etc/apache2/mod_perl_startup.pl", as Fred Moyer told you how to in a
> reply dated 17/06 22:22.
> - remove the corresponding PerlModule line from the Apache configuration
> file (or comment it out)
> - add the above "PerlRequire" line to your Apache configuration
>
> The fundamental effect should be the same, but the perl language "use"
> directive allows for additional parameters such as "-compile", while this
> is less than certain for the Apache/mod_perl "PerlModule" configuration
> directive.
>
> (*) for example, it means that in all other perl programs, modules, scripts
> running under your Apache/mod_perl, you can now use :
>
> return OK;
>
> instead of the longer
>
> return Apache2::Const::OK;

I am still at a loss as to how to proceed. Ignoring the Apache2::Const
and APR::Const issues, the apache2 server still fails to start. And I
don't know how to track down the problem. Changing "Loglevel" to "debug"
in the httpd.conf file did not result in any errors logged to my apache
error log file (since the server failed to run). Is this still a Perl
problem or could it be a mod_perl2 problem? And how to debug it?

Regards,

web...

--
William Bulley Email: web [at] umich

72 characters width template ----------------------------------------->|

IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and may contain information that is privileged, confidential, and protected from disclosure under applicable law. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records.

First page Previous page 1 2 Next page Last page  View All ModPerl modperl RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.