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.leboutill...@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 <gi...@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 <gml4...@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
