Hi all,
Tl;dr
I've actually resolved my problem.but I figured I'd send this email anyway
as it might be interesting to users of mod_perl on Red Hat Enterprise Linux
(RHEL) 6.8.
In the end, the problem/solution were so obvious, but I'd only recently
started using RHEL after using SLES, and I wasn't prepared for the
differences in how Apache is set up between the different OSes.
###
I noticed in the Changelog that "PerlSetEnv, PerlPassEnv and %ENV in
PerlRequre, PerlModule,
PerlConfigRequire and PerlPostConfigRequire" should affect each other*.
However, I'm having issues with this.
On SLES 11.1 with package apache2-mod_perl 2.0.4-40.19, I can get a value
from PerlSetEnv in the startup.pl script defined by PerlPostConfigRequire,
if I have a preceding section of <Perl> blank line </Perl> as per
https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-perl2/+bug/305646.
On RHEL 6.8, this doesn't work for me, unfortunately, when using package
mod_perl 2.0.4.
However, I'm thinking it might be because the <Perl> sections aren't running
at all on RHEL 6.8!!!
I set up the following:
<Location /perl-status>
SetHandler perl-script
PerlHandler Apache2::Status
</Location>
But I don't see any %ENV from <Perl> in the output. I see my PerlSetEnv
values in the output, as they're appearing in request (just not the
post_config phase).
Ideally, a person should be able to do what this person does:
http://stackoverflow.com/questions/14778981/how-to-pass-environment-variable
-to-an-autoloaded-mod-perl-handler-to-be-used-a
And indeed that works in SLES 11.1 if you have the following above the
PerlSetEnv directive:
<Perl>
</Perl>
But that doesn't work in RHEL 6.8. I'm guessing because <Perl> doesn't get
run.
So maybe there's an alternative to getting a running perl as per
https://perl.apache.org/docs/2.0/user/handlers/server.html#When_Does_perl_St
art_To_Run
However, I have "PerlModule Data::Dumper" near the top of my Apache
configuration and that doesn't make a difference.
Hmm. I thought maybe I wasn't loading the DSO. so I added "LoadModule
perl_module modules/mod_perl.so" above my VirtualHost config. and now it
looks like the <Perl> sections are working, except STDERR is being sent to
my screen rather than the error_log.
The LoadModule directive already exists at /etc/httpd/conf.d/perl.conf. but
httpd restart fails unless I load the module in my app.conf Virtualhost file
in /conf.d. Alphabetically, app.conf comes before perl.conf. could that be
related?
Huh. that seems to be a factor. as I've added the following to the top of my
app.conf:
<IfModule !perl_module>
LoadModule perl_module modules/mod_perl.so
</IfModule>
So I've just removed all the extra debugging stuff from my app.conf file and
now STDERR is showing up in error_log again.
So on SLES 11.1. mod_perl.so was being loaded via Include
/etc/apache2/sysconfig.d/loadmodule.conf which happens BEFORE Include
/etc/apache2/vhosts.d/*.conf
On RHEL 6.8, there really aren't many options for configuration files
installed by a package. There really is just conf.d, and then there's that
race condition of trying to load perl.conf before another *.conf which
requires mod_perl, since Apache runs Include alphabetically
(http://httpd.apache.org/docs/2.2/mod/core.html#include).
So my solution is just making sure the module is loaded in my configuration
file. but I wonder what the greater solution is for RHEL users. Looking at
conf/httpd.conf:
#
# Dynamic Shared Object (DSO) Support
#
# To be able to use the functionality of a module which was built as a DSO
you
# have to place corresponding `LoadModule' lines at this location so the
# directives contained in it are actually available _before_ they are used.
# Statically compiled modules (those listed by `httpd -l') do not need
# to be loaded here.
I'd say either Red Hat should follow the SUSE model and have a
sysconfig/loadmodule.conf file included earlier. or maybe have the
"mod_perl" package install the "perl.conf" file as "_perl.conf" so as to
load it before *most* other .conf files. That latter idea still has room for
race conditions though, so I really think the other way would be better.
I suppose the official Red Hat policy might be that you need to update
conf/httpd.conf manually, but that's not very feasible in this day and age
with the numbers of servers one needs to manage. Sure, you could use
Ansible to replace httpd.conf on all those machines, but it's still not that
elegant, especially as any automated updates via the httpd package will
break your workflow.
Anyway. glad that I resolved my issue. hopefully this helps other people.
*
=item 1.999_21 - January 22, 2005
PerlPostConfigRequire was trying to detect missing files early on,
but without searching thru @INC, causing false negatives. Better off
skipping that check and leave it to modperl_require_file() to report
problems with finding the file. [Patrick LeBoutillier
<patrick.leboutillier@gmail.com>, Gozer]
add a perl bug workaround: with USE_ITHREADS perl leaks pthread_key_t
on every reload of libperl.{a,so} (it's allocated on the very first
perl_alloc() and never freed). This becomes a problem on apache
restart: if the OS limit is 1024, 1024 restarts later things will
start crashing [Gisle Aas <gisle@ActiveState.com>, Stas]
on Irix mod_perl.so needs to see the libperl.so symbols, which
requires the -exports option immediately before -lperl. [Gordon Lack
<gml4410@ggr.co.uk>]
pool arguments to startup and connection callbacks must be blessed
into APR::Pool and not Apache::Pool class [joes]
Make PerlSetEnv, PerlPassEnv and %ENV in PerlRequre, PerlModule,
PerlConfigRequire and PerlPostConfigRequire affect each other, so a
change in one of these is immediately seen in the others. [Pratik
<pratiknaik gmail.com>, Stas]
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Office: 02 9212 0899
Direct: 02 8005 0595
Tl;dr
I've actually resolved my problem.but I figured I'd send this email anyway
as it might be interesting to users of mod_perl on Red Hat Enterprise Linux
(RHEL) 6.8.
In the end, the problem/solution were so obvious, but I'd only recently
started using RHEL after using SLES, and I wasn't prepared for the
differences in how Apache is set up between the different OSes.
###
I noticed in the Changelog that "PerlSetEnv, PerlPassEnv and %ENV in
PerlRequre, PerlModule,
PerlConfigRequire and PerlPostConfigRequire" should affect each other*.
However, I'm having issues with this.
On SLES 11.1 with package apache2-mod_perl 2.0.4-40.19, I can get a value
from PerlSetEnv in the startup.pl script defined by PerlPostConfigRequire,
if I have a preceding section of <Perl> blank line </Perl> as per
https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-perl2/+bug/305646.
On RHEL 6.8, this doesn't work for me, unfortunately, when using package
mod_perl 2.0.4.
However, I'm thinking it might be because the <Perl> sections aren't running
at all on RHEL 6.8!!!
I set up the following:
<Location /perl-status>
SetHandler perl-script
PerlHandler Apache2::Status
</Location>
But I don't see any %ENV from <Perl> in the output. I see my PerlSetEnv
values in the output, as they're appearing in request (just not the
post_config phase).
Ideally, a person should be able to do what this person does:
http://stackoverflow.com/questions/14778981/how-to-pass-environment-variable
-to-an-autoloaded-mod-perl-handler-to-be-used-a
And indeed that works in SLES 11.1 if you have the following above the
PerlSetEnv directive:
<Perl>
</Perl>
But that doesn't work in RHEL 6.8. I'm guessing because <Perl> doesn't get
run.
So maybe there's an alternative to getting a running perl as per
https://perl.apache.org/docs/2.0/user/handlers/server.html#When_Does_perl_St
art_To_Run
However, I have "PerlModule Data::Dumper" near the top of my Apache
configuration and that doesn't make a difference.
Hmm. I thought maybe I wasn't loading the DSO. so I added "LoadModule
perl_module modules/mod_perl.so" above my VirtualHost config. and now it
looks like the <Perl> sections are working, except STDERR is being sent to
my screen rather than the error_log.
The LoadModule directive already exists at /etc/httpd/conf.d/perl.conf. but
httpd restart fails unless I load the module in my app.conf Virtualhost file
in /conf.d. Alphabetically, app.conf comes before perl.conf. could that be
related?
Huh. that seems to be a factor. as I've added the following to the top of my
app.conf:
<IfModule !perl_module>
LoadModule perl_module modules/mod_perl.so
</IfModule>
So I've just removed all the extra debugging stuff from my app.conf file and
now STDERR is showing up in error_log again.
So on SLES 11.1. mod_perl.so was being loaded via Include
/etc/apache2/sysconfig.d/loadmodule.conf which happens BEFORE Include
/etc/apache2/vhosts.d/*.conf
On RHEL 6.8, there really aren't many options for configuration files
installed by a package. There really is just conf.d, and then there's that
race condition of trying to load perl.conf before another *.conf which
requires mod_perl, since Apache runs Include alphabetically
(http://httpd.apache.org/docs/2.2/mod/core.html#include).
So my solution is just making sure the module is loaded in my configuration
file. but I wonder what the greater solution is for RHEL users. Looking at
conf/httpd.conf:
#
# Dynamic Shared Object (DSO) Support
#
# To be able to use the functionality of a module which was built as a DSO
you
# have to place corresponding `LoadModule' lines at this location so the
# directives contained in it are actually available _before_ they are used.
# Statically compiled modules (those listed by `httpd -l') do not need
# to be loaded here.
I'd say either Red Hat should follow the SUSE model and have a
sysconfig/loadmodule.conf file included earlier. or maybe have the
"mod_perl" package install the "perl.conf" file as "_perl.conf" so as to
load it before *most* other .conf files. That latter idea still has room for
race conditions though, so I really think the other way would be better.
I suppose the official Red Hat policy might be that you need to update
conf/httpd.conf manually, but that's not very feasible in this day and age
with the numbers of servers one needs to manage. Sure, you could use
Ansible to replace httpd.conf on all those machines, but it's still not that
elegant, especially as any automated updates via the httpd package will
break your workflow.
Anyway. glad that I resolved my issue. hopefully this helps other people.
*
=item 1.999_21 - January 22, 2005
PerlPostConfigRequire was trying to detect missing files early on,
but without searching thru @INC, causing false negatives. Better off
skipping that check and leave it to modperl_require_file() to report
problems with finding the file. [Patrick LeBoutillier
<patrick.leboutillier@gmail.com>, Gozer]
add a perl bug workaround: with USE_ITHREADS perl leaks pthread_key_t
on every reload of libperl.{a,so} (it's allocated on the very first
perl_alloc() and never freed). This becomes a problem on apache
restart: if the OS limit is 1024, 1024 restarts later things will
start crashing [Gisle Aas <gisle@ActiveState.com>, Stas]
on Irix mod_perl.so needs to see the libperl.so symbols, which
requires the -exports option immediately before -lperl. [Gordon Lack
<gml4410@ggr.co.uk>]
pool arguments to startup and connection callbacks must be blessed
into APR::Pool and not Apache::Pool class [joes]
Make PerlSetEnv, PerlPassEnv and %ENV in PerlRequre, PerlModule,
PerlConfigRequire and PerlPostConfigRequire affect each other, so a
change in one of these is immediately seen in the others. [Pratik
<pratiknaik gmail.com>, Stas]
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Office: 02 9212 0899
Direct: 02 8005 0595