Problems with section
Hello. I'm trying to build an Apache configuration that makes it possible for all the developpers in my group to work with their own Apache process. For doing so, I'm using sections that build the server configuration; changing the User/Group, dynamically ajusting the DocumentRoot and Port, etc. But however I try to do it, I just can't make it work. It's acting the same as if the perl sections where not taking in account when starting the server. But mod_perl is working, and it's seems to at least try to execute the directives : if I start it with debug trace, I got that : - - - -8<- - - - [EMAIL PROTECTED] apache]$ MOD_PERL_TRACE=all ./bin/httpd -f /home/bcaron/apache/conf/httpd.conf -X perl_parse args: '/dev/null' ...allocating perl interpreter...ok constructing perl interpreter...ok loading perl module 'DynaLoader'...ok ok running perl interpreter...ok mod_perl: 0 END blocks encountered during server startup loading perl module 'Apache'...loading perl module 'Apache::Constants::Exports'...ok ok loading perl module 'Tie::IxHash'...not ok perl_section: perl_section: perl_section: perl_section: perl_section: [EMAIL PROTECTED]' directive is ITERATE, (0 elements) default: iterating over @DirectoryIndex perl_section: [EMAIL PROTECTED]' directive is ITERATE, (0 elements) default: iterating over @PerlModule perl_section: - - - -8<- - - - If I try to start the server with a section only, it simply does not work ; the server try to start on the default port 80 and since it needs to work as a normal user, it stops there. I added : ServerType "standalone" ServerRoot "/home/bcaron/apache" Port 9000 To make it start on the Port 9000 and to make sur it use my local build in my $HOME. I'm working with mod_perl 1.29 and Apache 1.3.31. I compiled mod_perl and Apache like this : perl Makefile.PL APACHE_SRC=../apache_1.3.31/src/ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 ADD_MODULE=proxy,rewrite APACHE_PREFIX=/home/bcaron/apache PERL_TRACE=1 MOD_PERL_PREFIX=/home/bcaron/mod_perl Any idea what I'm doing wrong? I once did a configuration that did something like it, but the server was started "root" with sudo, and I would prefer not to do this now... Thanks for any help Benoit -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Problems with section
Ok, now I'm ashamed. After some more RTFM, I found that there was a missing-closing-parens festival going on in my configuration file... So, for the record and/or those who will find this message some debugging day : I followed the suggestion of Pratical Mod_perl, p.132 : I've added a a #!/usr/bin/perl and __END__ in my block. Then, I ran my configuration file with regular Perl : $ cd [in my apache server root] $ perl -cx conf/httpd.conf And Perl informed me a bit more about my stupidity. Anyway, I would like to mention that this would be really, really great if this kind of error would show up somewhere, at least when one is running in "Debug-mode" like I did... Is it something that is present in mod_perl v2 (from my readings, I would say No)? If not, could it be? For everyone that did read my messages, thanks! :) benoit wrote: Hello. I'm trying to build an Apache configuration that makes it possible for all the developpers in my group to work with their own Apache process. For doing so, I'm using sections that build the server configuration; changing the User/Group, dynamically ajusting the DocumentRoot and Port, etc. But however I try to do it, I just can't make it work. It's acting the same as if the perl sections where not taking in account when starting the server. But mod_perl is working, and it's seems to at least try to execute the directives : if I start it with debug trace, I got that : - - - -8<- - - - [EMAIL PROTECTED] apache]$ MOD_PERL_TRACE=all ./bin/httpd -f /home/bcaron/apache/conf/httpd.conf -X perl_parse args: '/dev/null' ...allocating perl interpreter...ok constructing perl interpreter...ok loading perl module 'DynaLoader'...ok ok running perl interpreter...ok mod_perl: 0 END blocks encountered during server startup loading perl module 'Apache'...loading perl module 'Apache::Constants::Exports'...ok ok loading perl module 'Tie::IxHash'...not ok perl_section: perl_section: perl_section: perl_section: perl_section: [EMAIL PROTECTED]' directive is ITERATE, (0 elements) default: iterating over @DirectoryIndex perl_section: [EMAIL PROTECTED]' directive is ITERATE, (0 elements) default: iterating over @PerlModule perl_section: - - - -8<- - - - If I try to start the server with a section only, it simply does not work ; the server try to start on the default port 80 and since it needs to work as a normal user, it stops there. I added : ServerType "standalone" ServerRoot "/home/bcaron/apache" Port 9000 To make it start on the Port 9000 and to make sur it use my local build in my $HOME. I'm working with mod_perl 1.29 and Apache 1.3.31. I compiled mod_perl and Apache like this : perl Makefile.PL APACHE_SRC=../apache_1.3.31/src/ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 ADD_MODULE=proxy,rewrite APACHE_PREFIX=/home/bcaron/apache PERL_TRACE=1 MOD_PERL_PREFIX=/home/bcaron/mod_perl Any idea what I'm doing wrong? I once did a configuration that did something like it, but the server was started "root" with sudo, and I would prefer not to do this now... Thanks for any help Benoit -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Problems with section
Stas Bekman wrote: > From Changes: =item 1.21_03 - March 15, 2000 new variable $Apache::Server::StrictPerlSections, if true, will croak section generates invalid Apache configuration syntax Does it do the trick? I'm not sure why it's not documented. Where should I put this? I've tried adding it in my single section, or even in a stand-alone block at the beginning of my httpd.conf, but if I intentionnally break my perl code, I come back with the problem I had, ie. a silent failing of httpd -X and a "could not bind to port 80" in the error_log. As for the documentation of this feature, the "Practical mod_perl" book (which I love, btw!) says "if you set this variable to a true value [snip] then mod_perl will not tolerate invalid Apache configuration syntax and will croak if it encounters invalid syntax." So, it should croak only if one use un-localized variable name (which it seems to do by default). But it's not a "padding" for possible _Perl_ syntax errors. Maybe now is the time when I should take my first peak under the hood of mod_perl, but I guess that those Perl sections are eval-ed, no? If it's the case, the @! could be catch and the error reported. Anyway, I would like to mention that this would be really, really great if this kind of error would show up somewhere, at least when one is running in "Debug-mode" like I did... Is it something that is present in mod_perl v2 (from my readings, I would say No)? If not, could it be? In mp2 sections errors are fatal by default (will be shortly) I'll try my broken configuration under mp2 when I'll find some time, to see how it behaves. I have'nt had time to play with it yet ; I'm just back in a mod_perl job after nearly 2 years of *gasp* PHP. :P -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Hanging apache child on fork
Hello.
I'm having trouble with a new setup on a RedHat Entreprise Linux 4 box.
The problem is that whenever there is perl code that fork to execute
something, the apache child hang.
The problem occur with a specific function is called. But the weird part
is that the hang don't occur when that function is called; it happened
later, when a call to an external program is made, like:
my ($x, $y) = MyFunc();
# anything else
$h = qx( /bin/hostname );
# hanged here.
When it hang, it will show up is ps like this:
$ ps axf
[]
10002 ?Ss 0:00 /usr/local/apache_backend-1.3.33/bin/httpd
10003 ?S 0:00 \_ usr/local/apache_backend-1.3.33/bin/httpd
10004 ?S 0:00 \_ usr/local/apache_backend-1.3.33/bin/httpd
10042 ?S 0:00 \_ [hostname]
If I strace the apache child, all I see is that the process is reading
something, but hanged there.
[...]
clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7ff7708) = 10009
close(10) = 0
close(8)= 0
read(9,
If I strace the hostname process, the process is released: the request
continue, the output is sent, and the apache child is released.
I've tried to isolate what it the function could cause or favorise the
hang: the function is used to setup a session using Apache::Session on
an NFS shared directory.
I've added some "return ({}, {});" here and there in the function to
find a specific place. But the spot I've found is pretty weird... It is
completely at the end of the function.
return ($zzz, $xxx) ; # with fake data; will work
return ($session, $params_cookie); # real data, will not work
So, if a add a return with empty hash-ref, or fake value hashref, it is
ok. But if I return the actual hashref, it will then hang later.
This is running on Apache 1.3.33, mod_perl 1.29, on a dual-processor
machine. Perl is 5.8.5, as shipped from RedHat. Apache and mod_perl is
compiled, with mod_perl as a compiled-in module. The same code is
running on 3 RHEL 3 without problems; it's only with RHEL4 that it does
not work, with everything compiled the same way.
Anyone have an idea what else I can test and/or try?
--
Benoit Caron
Administrateur système
Canoe inc.
I read the FM, and it didn't work.
signature.asc
Description: OpenPGP digital signature
Re: Hanging apache child on fork
Philippe M. Chiasson wrote: > Benoit Caron wrote: > >>Hello. >> >>I'm having trouble with a new setup on a RedHat Entreprise Linux 4 box. >>The problem is that whenever there is perl code that fork to execute >>something, the apache child hang. > > > Have you read: > > http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing_Subprocesses_from_mod_perl > > And looked into Apache::SubProcess ? > > http://search.cpan.org/dist/Apache-SubProcess/ > Yes, I did. The problem I have is not really to be able to fork efficiently or anything else. It really is the hang that bugs me. I'm wearing the sysadmin's hat now... The exemple I used for my test is done with /bin/hostname; I know of course that it would make a lot more sense to use Sys::Hostname to do this. But the problem I have happen with anything that fork. Another example of such problematic scripts is one of the admins tool for the sites that use cp and rsync: the performance is absolutely not a problem for a scripts that's called 3 times a day. I've continued my investigation: what I suspect is a bad interaction with the NFS shared dir that somehow "corrupted" the Apache process and later cause the hang. This problem happens only on my RHEL4 boxes; the RHEL3 are doing fine with the same code. What I would have really like is to someone familiar with the internals of all of this to help me find more test of investigation to do. I can take out that particular example (the hostname test) from the code and to the job another way, but it is hard to be sure that none of the code that run ou will run on the pool will use a backtick or a system call somewhere. The code that triggers the bug use Apache::Session::File, on an NFS share. Have anyone had problem with that? Do I have some special configuration to give to A::S::File to help it behave correctly on an NFS share? Any suggestion of a different method to share the session data between a pool of 6 servers? I've used Apache::Session::Oracle a few years ago, for another project, and the performance hit was way to big. The web site is using an Oracle database, but could it still be faster to use a MySQL server so store the sessions? I suppose that for the simple get/set that the sessions support needs, MySQL could be faster? Anyway, thanks for the help. -- Benoit Caron Administrateur système Canoe inc. [EMAIL PROTECTED] I don't find that being really up on all the latest technology ever does me any good. -- William Gibson signature.asc Description: OpenPGP digital signature
Error intercept.
Hi,
I'm trying to build an filter that will parse the output of
some application server (AKA the blackbox) and replace the errors messages
with something neater.
For that purpose i installed the following OutputFilter on the
reverse-proxy:
---8<
package MyApache2::FilterColdfusion;
use base qw(Apache2::Filter);
use strict;
use warnings FATAL => 'all', NONFATAL => 'redefine';
use Apache2::Filter ();
use Apache2::RequestRec ();
use Apache2::Log;
use APR::Table ();
use Apache2::Reload;
use Apache2::Const -compile => qw(OK DECLINED :log);
use APR::Const -compile => qw(:error SUCCESS);
my $error_page;
BEGIN {
# Load the generic response text:
local $/;
undef $/;
open IN, ";
}
sub handler { #: FilterRequestHandler FilterHasInitHandler(\&init) {
my $f = shift;
my $r = $f->r;
# Filter only generated text
if (($r->status() < 300) &&
$r->content_type() =~ /text\/html/) {
if (!$f->ctx()) {
# Test: randomly intercept:
$f->ctx ({intercept => int(rand() + .5)});
if ($f->ctx->{intercept}) {
$r->headers_out->unset('Content-Length');
# Record matched error
$r -> log_reason ("Intercepted Coldfusion
Error",$r->filename);
# print Error generic message
$f -> print ($error_page);
$r -> headers_out->set('Content-Length', length
$error_page);
# exit with OK
return Apache2::Const::OK;
}
} else {
if ($f->ctx->{intercept}) {
$r -> log_reason ("Intercepted since previously set to",
$r->filename);
return Apache2::Const::OK;
}
}
}
# Not an error => let mod_perl copy the text
return Apache2::Const::DECLINED;
}
1;
---8<
When using wget -SO - http://url/ things seem to be ok, i got the want
text, and
headers seems good to me:
HTTP/1.1 200 OK
Date: Thu, 22 Feb 2007 17:53:52 GMT
Server: Apache/1.3.33 (Debian GNU/Linux) AuthMySQL/4.3.9-2 mod_perl/1.29
Page-Completion-Status: Normal
Page-Completion-Status: Normal
Content-Type: text/html; charset=iso-8859-1
Content-Length: 2048
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Incident sur l'hebergement
Re: Error intercept.
Robert Landrum wrote: Given that this is in French, is it possible this is a UTF8 issue? Could length $error_page be returning a value that is inconsistent with the actual length of the message. If so, firefox might be ignoring some or all of the message. I could be wrong. I would try unsetting content length to see if that corrects the issue. In fact i did set content-length for the exact same reason, but there is no change in either case. Well if the content length is not exact links did cut the output, but as for FF, nothing changed Thanks for the reply anyway, -- Benoit
Re: Error intercept.
Perrin Harkins a écrit : On 2/22/07, Benoit Plessis <[EMAIL PROTECTED]> wrote: When using wget -SO - http://url/ things seem to be ok, i got the want text, and headers seems good to me: [...] Using links everything goes fine, but firefox do not show anything (and there is nothing in 'view source'). Why don't you compare the text of the requests these clients are sending and figure out which header or change makes it stop working? - Perrin Hell yes, i don't know why i focused on the script, it must be that mod_deflate isn't triggered by wget/links while it is by firefox. And there is many chances that it is triggered before my script. Thanks, i'll look into it. -- Benoit Plessis +33 4 67 36 42 59 <[EMAIL PROTECTED]> Ingénieur Réseau Responsable Infrastructure Système & Réseau. do|you|soft
Re: Error intercept.
Benoit Plessis a écrit : Perrin Harkins a écrit : On 2/22/07, Benoit Plessis <[EMAIL PROTECTED]> wrote: When using wget -SO - http://url/ things seem to be ok, i got the want text, and headers seems good to me: [...] Using links everything goes fine, but firefox do not show anything (and there is nothing in 'view source'). Why don't you compare the text of the requests these clients are sending and figure out which header or change makes it stop working? - Perrin Hell yes, i don't know why i focused on the script, it must be that mod_deflate isn't triggered by wget/links while it is by firefox. And there is many chances that it is triggered before my script. Thanks, i'll look into it. Well, it was linked to mod_deflate in all ways. It migrated to the bucket brigade interface and deflate seem to like much more. Thanks -- Benoit Plessis +33 4 67 36 42 59 <[EMAIL PROTECTED]> Ingénieur Réseau Responsable Infrastructure Système & Réseau. do|you|soft
[MP2] Handler for Proxying request
Hi, I'm actually using mod_rewrite in proxy mode and a perl script to do some LB/FO on our platform, additionnally, i have some mod_perl handler to tweak and intercept some error pages send by the application server. I'm wondering if it won't be possible to replace mod_rewrite + the perl script with a InputHandler which would do the same job. Since mod_rewrite does actualy control mod_proxy is suppose it's possible but i wanted to know if someone already tried this. regards -- Benoit Plessis
[mp2] crash when using EV::signal 'CHLD' and backtick operator at the same time
-8<-- Start Bug Report 8<--
1. Problem Description:
To reproduce the problem, start from Debian vanilla server (I used
testing (buster)).
Install apache2, libapache2-mod-perl2, libev-perl
(I also used development version of perl, mod_perl and EV with the
same result)
Create 2 perl files with following content:
handler1.pl:
#!/usr/bin/perl
my $pwd = `/bin/pwd`;
1;
handler2.pl:
#!/usr/bin/perl
use EV;
my $w = EV::signal 'CHLD', sub {
print "SIGCHLD received\n";
};
1;
Reference them in two PerlRequire directive, either
in /etc/apache2/apache2.conf or in a separate conf file
in /etc/apache2/conf-enabled:
# order is important
PerlRequire "/path/to/handler1.pl"
PerlRequire "/path/to/handler2.pl"
==> Apache will crash on startup.
I did an in-depth analysis of this bug. Here is what happens:
The backtick operator in handler1.pl internally calls waitpid, which
internally waits for the SIGCHLD signal.
EV::signal 'CHLD' installs a signal handler using sigaction (see
EV-4.22.0: libev/ev.c::ev_signal_start). There is no provision to remove
this signal handler. The handler is located in EV.so, loaded by the XS
loader.
apache2 goes through 3 stages on startup: pre-config, destroy-config,
create-config
In the pre-config stage, the 2 PerlRequire commands are executed and
the signal handler is installed at process level.
In the destroy-config stage, all modules are removed, including
mod_perl, which consists in removing all XS modules (see mod_perl:
src/modules/perl/modperl_interp.c::modperl_interp_destroy())
The removal of EV.so does not restore the signal handler as there is
no cleanup in EV.so.
At this point the signal handler is still registered at process level
but points to invalid memory!
In the create-config stage, the config is recreated, handler1.pl is
reloaded and the backtick operator triggers a SIGCHLD, which causes a
SIGEV because the signal handler is not in memory (the EV.so library
will only be loaded when the second PerlRequire is executed).
Conclusion:
Unloading the XS modules relies on the modules to cleanup the global
state properly but it's clearly not the case of the EV module.
I tested a fix that consists in skipping the unloading of the XS
modules. While it works for my case, it is not a proper solution either
as there are circumstances where it would cause other bugs.
Ideally the EV module should register a cleanup function to restore
the signal handlers on unload.
There are similar potential issues when an XS module register some op
checker in PL_check static array: unloading the XS module does not
remove the handler because Perl does not provide an API to do it.
Hopefully, in this case unloading mod_perl will normally causes
libperl to unload as well, which cleans the PL_check array.
Clearly, Perl is not designed to be unloaded-reloaded.
2. Used Components and their Configuration:
*** mod_perl version 2.11
*** using /home/ben/src/mod_perl-2.0/lib/Apache2/BuildConfig.pm
*** Makefile.PL options:
MP_APR_LIB => aprext
MP_APXS=> /usr/bin/apxs
MP_COMPAT_1X => 1
MP_GENERATE_XS => 1
MP_LIBNAME => mod_perl
MP_USE_DSO => 1
*** /usr/sbin/apache2 -V
Server version: Apache/2.4.34 (Debian)
Server built: 2018-07-27T19:37:37
Server's Module Magic Number: 20120211:79
Server loaded: APR 1.6.3, APR-UTIL 1.6.1
Compiled using: APR 1.6.3, APR-UTIL 1.6.1
Architecture: 64-bit
Server MPM: event
threaded: yes (fixed thread count)
forked: yes (variable process count)
Server compiled with
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=256
-D HTTPD_ROOT="/etc/apache2"
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="mime.types"
-D SERVER_CONFIG_FILE="apache2.conf"
*** /usr/bin/ldd /usr/sbin/apache2
linux-vdso.so.1 (0x7ffdc0dfa000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f9abcf5b000)
libaprutil-1.so.0 => /lib/x86_64-linux-gnu/libaprutil-1.so.0
(0x7f9abcd2f000)
libapr-1.so.0 => /lib/x86_64-linux-gnu/libapr-1.so.0
(0x7f9abccf6000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f9abccd5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f9abcb18000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f9abcb0f000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f9abcb03000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1
(0x7f9abcac9000)
