Re: apache2 or mod_perl2 oddball error
According to Perrin Harkins per...@elem.com 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: w...@umich.edu 72 characters width template -|
Re: apache2 or mod_perl2 oddball error
According to Andr? Warnier a...@ice-sa.com 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
RE: apache2 or mod_perl2 oddball error
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:w...@umich.edu] 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 a...@ice-sa.com 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
Re: apache2 or mod_perl2 oddball error
William Bulley wrote: According to Perrin Harkins per...@elem.com on Fri, 06/17/11 at 15:35: On Fri, Jun 17, 2011 at 3:20 PM, William Bulley w...@umich.edu 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.
Re: apache2 or mod_perl2 oddball error
According to Fred Moyer f...@redhotpenguin.com 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: w...@umich.edu 72 characters width template -|
Re: apache2 or mod_perl2 oddball error
On Fri, Jun 17, 2011 at 10:29 AM, William Bulley w...@umich.edu 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
Re: apache2 or mod_perl2 oddball error
On Fri, Jun 17, 2011 at 12:34 PM, William Bulley w...@umich.edu 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
Re: apache2 or mod_perl2 oddball error
According to Fred Moyer f...@redhotpenguin.com on Fri, 06/17/11 at 13:43: On Fri, Jun 17, 2011 at 10:29 AM, William Bulley w...@umich.edu 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: w...@umich.edu 72 characters width template -|
Re: apache2 or mod_perl2 oddball error
According to James B. Muir james.b.m...@hitchcock.org 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: w...@umich.edu 72 characters width template -|
Re: apache2 or mod_perl2 oddball error
According to Perrin Harkins per...@elem.com on Fri, 06/17/11 at 13:44: On Fri, Jun 17, 2011 at 12:34 PM, William Bulley w...@umich.edu 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: w...@umich.edu 72 characters width template -|
Re: apache2 or mod_perl2 oddball error
On Fri, Jun 17, 2011 at 2:18 PM, William Bulley w...@umich.edu 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
Re: apache2 or mod_perl2 oddball error
According to Perrin Harkins per...@elem.com 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: w...@umich.edu 72 characters width template -|
Re: apache2 or mod_perl2 oddball error
On Fri, Jun 17, 2011 at 3:20 PM, William Bulley w...@umich.edu 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
Re: apache2 or mod_perl2 oddball error
According to Fred Moyer f...@redhotpenguin.com on Fri, 06/17/11 at 13:43: On Fri, Jun 17, 2011 at 10:29 AM, William Bulley w...@umich.edu 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: w...@umich.edu 72 characters width template -|
Re: apache2 or mod_perl2 oddball error
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_modulemodules/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 w...@umich.edu wrote:
According to Fred Moyer f...@redhotpenguin.com on Fri, 06/17/11 at 13:43:
On Fri, Jun 17, 2011 at 10:29 AM, William Bulley w...@umich.edu 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: w...@umich.edu
72 characters width template -|
Re: apache2 or mod_perl2 oddball error
According to Fred Moyer f...@redhotpenguin.com 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_modulemodules/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: w...@umich.edu
72 characters width template -|
Re: apache2 or mod_perl2 oddball error
According to Perrin Harkins per...@elem.com on Fri, 06/17/11 at 15:35: On Fri, Jun 17, 2011 at 3:20 PM, William Bulley w...@umich.edu 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: w...@umich.edu 72 characters width template -|
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.05 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: w...@umich.edu 72 characters width template -|
Re: apache2 or mod_perl2 oddball error
On Thu, Jun 16, 2011 at 9:28 AM, William Bulley w...@umich.edu 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.
Re: apache2 or mod_perl2 oddball error
According to Fred Moyer f...@redhotpenguin.com 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: w...@umich.edu 72 characters width template -|
