Re: OSCON 2004 mod_perl BOFs
On Tue, 15 Jun 2004, Frank Wiles wrote: > mod_perl Advocacy and PR > Thursday 8-9pm Columbia Room Doh, same time as the Mason BOF. I hope this doesn't conflict for too many folks. Oh well, too many BOFs, too little time. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/ -- 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: Apache::Request
"David Hofmann" <[EMAIL PROTECTED]> writes: > I see that there a development version. Is there a stable version that > works for Mod Perl 2.0 or something the can be easily put in it's place? No, there isn't. My guess is that there will only be one more developer release in a few months, which will include the recent SSL bugfixes and full support for Apache::Request in CGI mode (libapreq2 already works with CGI; mp2 is being reshuffled a bit to allow Apache::Request to work there as well). I'd really like to see a stable release happen before November's Apachecon, and I don't expect Apache::Request to change much between now and then. Even so, now is a very good time to try it out, because you actually may want some things changed before we "stabilize" it :-). There are plenty of open issues in the httpd-apreq-2 STATUS file that would benefit from user-feedback. -- Joe Schaefer -- 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
XML::XSLT and mod_perl 2.0
I admit I have not tried this in mod_perl 1.x but I am really trying to
move towards developing and helping out the mod_perl 2.0 movement.
Hopefully someone has some pointers. Here's my problem:
I am struggling to get XML::XSLT to work under mod_perl 2.0. All it
takes is using the basic MyApache::Rocks module from the docs, and
adding the following line to cause the error, but I have tried it in
other various mod_perl 2.0 programs as well, all with the same results:
Error while parsing: \nsyntax error at line 1, column 0, byte 0 at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/XML/Parser.pm
line 187\n\ntest.xsl at /usr/lib/perl5/site_perl/5.8.0/XML/XSLT.pm line
1506.\n
The code my Perl module is referencing contains one simple call (along
with use XML::XSLT;):
my $xslt = XML::XSLT->new ('test.xsl', warnings => 1);
Doing a trace, that is what is generating the error, and it seems to
fail in XML::Parser::Expat's ParseString() call. "test.xsl" contains
the basic test xsl script from w3schools.com:
http://www.w3.org/1999/XSL/Transform";>
My CD Collection
Title
Artist
When I run this under mod_perl I get the syntax error. When I run it
as a regular perl script it runs fine without any errors. I have
searched every resource I can find and can't seem to find anyone else
with this problem. Does anyone have any suggestions on where I could
go from here? It seems really weird that mod_perl would even affect
something as simple as parsing an xml file.
-Jesse
--
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
Apache::Request
I'm currently in the process of switching from Mod Perl 1.26 to 2.0. One of the programs I use a lot is Apache:Request. Upon attempting to install it from CPAN I found that it only supports up to mod_perl version 1.99. I see that there a development version. Is there a stable version that works for Mod Perl 2.0 or something the can be easily put in it's place? David _ Get fast, reliable Internet access with MSN 9 Dial-up now 3 months FREE! http://join.msn.click-url.com/go/onm00200361ave/direct/01/ -- 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
Apache::Request
I'm currently in the process of switching from Mod Perl 1.26 to 2.0. One of the programs I use a lot is Apache:Request. Upon attempting to install it from CPAN I found that it only supports up to mod_perl version 1.99. I see that there a development version. Is there a stable version that works for Mod Perl 2.0 or something the can be easily put in it's place? David _ MSN 9 Dial-up Internet Access fights spam and pop-ups now 3 months FREE! http://join.msn.click-url.com/go/onm00200361ave/direct/01/ -- 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: perl 5.8 safe signals and broken pipes in apache
Great! It's always nice to have multiple solutions to a problem. I
believe Stas Bekman also pointed to the POSIX sigaction solution when he
first pointed me in the right direction in solving this problem, but
setting $ENV{PERL_SIGNALS} = "unsafe"; got me going with perl 5.8 very
quickly.
I might give the POSIX sigaction solution a try myself since I too
wasn't incredibly comfortable with resorting to old signal handling for
my entire httpd servers. My guess is that your POSIX sigaction solution
would work with perl5.8.0 unlike the $ENV{PERL_SIGNALS} solution which
is not supported until perl5.8.1.
Assuming your solution also solves this problem, it should also be
included in any documentation regarding "safe signals" and apache/mod_perl.
Eric wrote:
Jim,
Thank you! This was a big help to me in that I ran into this problem from two directions recently, with a perl daemon and with Apache::SIG.. I did find some info about fixing this for real rather than using unsafe signals. They mostly seemed to point to using the POSIX sigaction methods rather Perl's.
I did end up getting my daemon to work without either dying after the first command or spawning endless children that would not die, those were my two choices before :) Only a part of this was related to the signal problem, but it was the hard part for a while.
The child signal was what was causing me big problems. I know this is far from a complete answer, but I hope it might send someone off on the right path if they don't want to set the ENV var. I was worried about doing it that way, because what happens a year from now when I upgrade my server and we somehow forget about that little detail? I know me and I will manage to mess it up if I can :)
Below are some examples from the POSIX module, it should work :). I found most of this
somewhere when doing research on perl daemons but the child one I added on and I am
currently using all of the below, I just did some cutting of other things.
use POSIX ();
use POSIX 'WNOHANG';
use FindBin ();
use File::Basename ();
use File::Spec::Functions;
my $script = File::Basename::basename($0);
my $SELF = catfile $FindBin::Bin, $script;
my $sigset = POSIX::SigSet->new();
my $action = POSIX::SigAction->new('sigHUP_handler',
$sigset,
&POSIX::SA_NODEFER);
my $action_alrm = POSIX::SigAction->new('sigALRM_handler',
$sigset,
&POSIX::SA_NODEFER);
my $action_child = POSIX::SigAction->new('sigCHLD_handler',
$sigset,
&POSIX::SA_NODEFER);
POSIX::sigaction(&POSIX::SIGHUP, $action);
POSIX::sigaction(&POSIX::SIGALRM, $action_alrm);
POSIX::sigaction(&POSIX::SIGCHLD, $action_child);
sub sigHUP_handler {
print "got SIGHUP\n";
exec($SELF, @ARGV) or die "Couldn't restart: $!\n";
}
sub sigALRM_handler {
print "got ALARM timeout\n";
}
sub sigCHLD_handler {
while (my $reaperpid = waitpid(-1,WNOHANG)>0) {
}
}
## do your while (1) and fork etc...
I wish I could paste in my whole daemon thing, but it is too far along with to many things specific to my bosses application..
Thanks,
Eric
At 02:55 PM 6/15/2004, Jim Albert wrote:
Last week I had a problem where I could not get my Apache2/mod_perl2/perl5.8.3 web
server to catch a SIGPIPE signal in a timely manner. I was asked to post a
description of this problem and solution to this list so that it might be included in
future mod_perl documentation.
Feel free to adjust this description as necessary when integrating it into the
appropriate documentation.
The Problem:
Use a PerlFixupHandler to catch when the pipe from browser to httpd server has been
broken such as when the user presses the browser stop button.
In conf.d/perl.conf
PerlFixupHandler Apache::SIG2
where Apache::SIG2.pm is defined in this example as:
--
package Apache::SIG2;
# This package adapted by Jim Albert from the original mod_perl1
# Apache::SIG.pm by Doug MacEachern and Doug Bagley
# This PerlHandler can be used to prevent httpd children from killing
# off non-mod-perled CGIs when the user presses the Stop button.
use strict;
use Apache::RequestRec;
use ModPerl::Util;
use Apache::Const;
sub handler {
my $r = shift;
if (!$r->main) {
$SIG{PIPE} = \&PIPE;
}
return OK;
}
sub PIPE {
my($signal) = @_;
print STDERR ("User pressed stop button.\n");
# Kill off the httpd child before it can kill any running CGIs.
# Or do whatever other cleanup is appropriate.
CORE::exit();
}
1;
--
With the introduction of perl 5.8.0, this handler no longer works as expected because
of the introduction of perl safe signals.
See:
http://www.perldoc.com/perl5.8.4/pod/perlipc.html#Deferred-Signals
perl 5.8 safe signals and broken pipes in apache
Last week I had a problem where I could not get my
Apache2/mod_perl2/perl5.8.3 web server to catch a SIGPIPE signal in a
timely manner. I was asked to post a description of this problem and
solution to this list so that it might be included in future mod_perl
documentation.
Feel free to adjust this description as necessary when integrating it
into the appropriate documentation.
The Problem:
Use a PerlFixupHandler to catch when the pipe from browser to httpd
server has been broken such as when the user presses the browser stop
button.
In conf.d/perl.conf
PerlFixupHandler Apache::SIG2
where Apache::SIG2.pm is defined in this example as:
--
package Apache::SIG2;
# This package adapted by Jim Albert from the original mod_perl1
# Apache::SIG.pm by Doug MacEachern and Doug Bagley
# This PerlHandler can be used to prevent httpd children from killing
# off non-mod-perled CGIs when the user presses the Stop button.
use strict;
use Apache::RequestRec;
use ModPerl::Util;
use Apache::Const;
sub handler {
my $r = shift;
if (!$r->main) {
$SIG{PIPE} = \&PIPE;
}
return OK;
}
sub PIPE {
my($signal) = @_;
print STDERR ("User pressed stop button.\n");
# Kill off the httpd child before it can kill any running CGIs.
# Or do whatever other cleanup is appropriate.
CORE::exit();
}
1;
--
With the introduction of perl 5.8.0, this handler no longer works as
expected because of the introduction of perl safe signals.
See:
http://www.perldoc.com/perl5.8.4/pod/perlipc.html#Deferred-Signals-(Safe-Signals)
What happens with perl 5.8 and safe signals is that the apache httpd
child does receive the SIGPIPE, but it is delayed and the perl CGI
program has already been killed. The httpd child does not act on the
SIGPIPE until it receives the next httpd request.
The Solution:
An Apache server_startup.pl script can be used to turn off perl safe
signals with the following line:
$ENV{PERL_SIGNALS} = "unsafe";
The server_startup.pl script can be included via the following line in
perl.conf:
PerlRequire conf/server_startup.pl
The ability to revert back to "unsafe" signals is available as of perl
5.8.1.
--
Jim Albert
--
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: [mp2] Authen handler with htgroup authorization
John D Groenveld wrote: In message <[EMAIL PROTECTED]>, Geoffrey Young writes: can you try current CVS if you get the chance? Done. dumps core at the same function in mod_auth. Server: Apache/2.0.49 (Unix) mod_perl/1.99_15-dev Perl/v5.8.4 DAV/2 The core dump shows that neither mod_perl nor Perl are involved. I suppose Geoff was suggesting to try the cvs version of Apache? It seems to be a pure Apache problem. Try to get all the mod_perl parts away from your config and see if you can reproduce the problem using mod_cgi or similar. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- 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: [mp2] Authen handler with htgroup authorization
In message <[EMAIL PROTECTED]>, Geoffrey Young writes:
>can you try current CVS if you get the chance?
Done. dumps core at the same function in mod_auth.
Server: Apache/2.0.49 (Unix) mod_perl/1.99_15-dev Perl/v5.8.4 DAV/2
>I'll try to investigate it this week. is your PerlAuthenHandler just
>returning OK? and I am assuming that the mp2 test suite passes ok as well?
Yes.
sub handler {
my($r) = @_;
return Apache::OK unless $r->is_initial_req;
my($status, $password) = $r->get_basic_auth_pw;
return $status unless $status == Apache::OK;
return Apache::OK;
}
John
[EMAIL PROTECTED]
--
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: reverse IP lookup for check all doimains on the server
Maxipoint Rep Office wrote: Why this is off-topic? Why I can not with Perl parse into their script/database? I must not have their technology, if this is so complicated.. Because this list deals expicitly with *mod_perl* issues, not Perl any other more general topic. There are forums that deal specifically with the questions of that kind. Take a look at: http://perl.apache.org/maillist/email-etiquette.html#General_Perl_and_Apache_questions -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- 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: reverse IP lookup for check all doimains on the server
Why this is off-topic? Why I can not with Perl parse into their script/database? I must not have their technology, if this is so complicated.. -Original Message- From: Glenn [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 6:18 PM To: [EMAIL PROTECTED] Subject: Re: reverse IP lookup for check all doimains on the server On Tue, Jun 15, 2004 at 12:36:35PM +0200, Maxipoint Rep Office wrote: > > but how http://whois.webhosting.info has some script for that?? > > I wish see all domains pointed to ANY IP like by > http://whois.webhosting.info/anyIPnumber > > try any server IP like: http://whois.webhosting.info/207.44.194.79 > > http://whois.webhosting.info/64.5.48.155 Read and understand http://www.webhosting.info/about/profile/ The answers have been there since your first post. Now can we please kill this off-topic thread? Thanks. Glenn -- 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 -- 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: reverse IP lookup for check all doimains on the server
On Tue, Jun 15, 2004 at 12:36:35PM +0200, Maxipoint Rep Office wrote: > > but how http://whois.webhosting.info has some script for that?? > > I wish see all domains pointed to ANY IP like by > http://whois.webhosting.info/anyIPnumber > > try any server IP like: http://whois.webhosting.info/207.44.194.79 > > http://whois.webhosting.info/64.5.48.155 Read and understand http://www.webhosting.info/about/profile/ The answers have been there since your first post. Now can we please kill this off-topic thread? Thanks. Glenn -- 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: OSCON 2004 mod_perl BOFs
Frank Wiles wrote: Hi Everyone, O'Reilly has setup our two BOFs at OSCON. Here is the info: Thanks Frank! mod_perl Users and Usage (general mod_perl BOF) Wednesday 7-8pm Salon H I have to be at the "Meet the Authors" event at the Exhibit Hall 6:15 - 7:15 pm, so I'll join you once it's over. mod_perl Advocacy and PR Thursday 8-9pm Columbia Room More info can be found at: http://conferences.oreillynet.com/pub/w/29/bof.html Hopefully these times work for everyone who wants to attend. The rest is fine with me :) -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- 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
OSCON 2004 mod_perl BOFs
Hi Everyone, O'Reilly has setup our two BOFs at OSCON. Here is the info: mod_perl Users and Usage (general mod_perl BOF) Wednesday 7-8pm Salon H mod_perl Advocacy and PR Thursday 8-9pm Columbia Room More info can be found at: http://conferences.oreillynet.com/pub/w/29/bof.html Hopefully these times work for everyone who wants to attend. - Frank Wiles <[EMAIL PROTECTED]> http://frank.wiles.org - -- 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: [mp2] modperl test failed
Alex Oboimov wrote: Many thanks, Stas! Unfortunately (?) I hasted a bit and have upgraded my perl package to 5.8.4-10.mdk before your post arrived. Now modperl configured and build ok and all tests passed including rflush.t. Cool. Though now I have problem building my DBI & DBD::InterBase modules :((( Now I hesitate - should I DEGRADE my system to find out what was wrong with my perl-5.8.1-1.RC4.mdk? Probably there is no point in trying to fix an outdated thing. Just figure out why the 5.8.4 package has problems. Contact its maintainer with a full description of the problems that you have. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- 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
[mp2] modperl test failed
Many thanks, Stas! Unfortunately (?) I hasted a bit and have upgraded my perl package to 5.8.4-10.mdk before your post arrived. Now modperl configured and build ok and all tests passed including rflush.t. Though now I have problem building my DBI & DBD::InterBase modules :((( Now I hesitate - should I DEGRADE my system to find out what was wrong with my perl-5.8.1-1.RC4.mdk? Regards, Alex ___ALL-NEW Yahoo! Messenger - so many all-new ways to express yourself http://uk.messenger.yahoo.com -- 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: reverse IP lookup for check all doimains on the server
Looks like they have created their own database. It's not all that accurate either. I have a few IPs with websites on them which just turned up "no data available". For example, www.perl.org is on 63.251.223.172 but it does not come up at http://whois.webhosting.info/63.251.223.172 Andrew On Jun 15, 2004, at 6:36 AM, Maxipoint Rep Office wrote: but how http://whois.webhosting.info has some script for that?? I wish see all domains pointed to ANY IP like by http://whois.webhosting.info/anyIPnumber try any server IP like: http://whois.webhosting.info/207.44.194.79 http://whois.webhosting.info/64.5.48.155 -GP -Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 9:01 AM To: Maxipoint Rep Office Cc: Brian Reichert; [EMAIL PROTECTED] Subject: Re: reverse IP lookup for check all doimains on the server On 11 Jun 2004, at 23:49, Maxipoint Rep Office wrote: RE: yes I wish reverse lookup from IPs on any server at the web! any help? :-) Sure. What you want to do isn't possible. DNS maps host names to IPs, not generally the other way around. You can lookup $reverse_ip.in-addr.arpa, and hope to get a hostname, but it won't be all hostnames on the IP address - it'll just be one hostname, and possibly not even one that will get you a web site. Sorry. The only way I can think of you even getting moderately close is to crawl through the .com domain zone file, checking each one for a web site at the other end and putting the IP into a DB of your own. Then you can do the reverse mapping on your web site. As you might imagine this only gets you moderately close to a solution. Matt. -- 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 -- 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: A CGI.pm script
Larry Leszczynski wrote: Hi David - MOD_PERL=mod_perl/1.99_07-dev [cut] It runs fine when accessed with http://hostname/cgi-bin/graffiti.pl. However, when accessed with http://hostname/cgi-perl/graffiti.pl, I get: Server error! The server encountered an internal error and was unable to complete your request. Error message: Failed opening session state file ./STATES/259344: No such file or directory at /var/www/cgi-perl/graffiti.pl line 104. That's a really old version of mod_perl 2. I think for that version, ModPerl::Registry did not chdir to the script directory before running the script (because of some thread-related problems). And it still doesn't do that. It can't do that, since under threads it'll wreak havoc - as chdir affects all threads: http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Registry___C_Apache__PerlRun__and_Friends http://perl.apache.org/docs/2.0/user/coding/coding.html#Thread_environment_Issues http://perl.apache.org/docs/2.0/user/porting/compat.html#C__r_E_gt_chdir_file_ The most recent version of FindBin should work for mod_perl. So instead of requiring a file relatively use FindBin to find where the script's dir is. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- 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: reverse IP lookup for check all doimains on the server
but how http://whois.webhosting.info has some script for that?? I wish see all domains pointed to ANY IP like by http://whois.webhosting.info/anyIPnumber try any server IP like: http://whois.webhosting.info/207.44.194.79 http://whois.webhosting.info/64.5.48.155 -GP -Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 9:01 AM To: Maxipoint Rep Office Cc: Brian Reichert; [EMAIL PROTECTED] Subject: Re: reverse IP lookup for check all doimains on the server On 11 Jun 2004, at 23:49, Maxipoint Rep Office wrote: > RE: yes I wish reverse lookup from IPs on any server at the web! > > any help? > > :-) Sure. What you want to do isn't possible. DNS maps host names to IPs, not generally the other way around. You can lookup $reverse_ip.in-addr.arpa, and hope to get a hostname, but it won't be all hostnames on the IP address - it'll just be one hostname, and possibly not even one that will get you a web site. Sorry. The only way I can think of you even getting moderately close is to crawl through the .com domain zone file, checking each one for a web site at the other end and putting the IP into a DB of your own. Then you can do the reverse mapping on your web site. As you might imagine this only gets you moderately close to a solution. Matt. -- 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: [mp2] modperl test failed
Alex Oboimov wrote: Hello Stas, After configuring with MP_DEBUG=1 I've encountered segfault during configuration itself so it definitely smells like some perl problem, since confuguration doesn't involve anything but pure perl. After doing so: (gdb) bt #0 0x4032fa74 in Perl_pp_leavesub () from /usr/lib/perl5/5.8.1/i386-linux-thread-multi/CORE/libperl.so #1 0x082ea5e0 in ?? () #2 0x0918e994 in ?? () Still the same trace with misterious addresses. As I dare guess the fault is not on the modperl side but on the perl's one. So I rather dwell on reinstallation of perl, but my early investigation show that it is uneasy task bearing in mind complex dependencies of mdk packages. One advice is to run two perls - one for system needs and another for apache-perl-modperl tier. Is this advisable? You certainly could, but if it's a bug in perl, may be you better figure out what it is and have mandrake release a fixed version. As proposed earlier you could figure out the exact trace, by starting httpd from within gdb, so when the former segfaults you get a good trace. In one console run: % gdb /path/to/httpd gdb> run -d /usr/local/src/mod_perl-1.99_14/t -f /usr/local/src/mod_perl-1.99_14/t/conf/httpd.conf -D APACHE2 -DPERL_USEITHREADS (or you can even do the simple: % t/TEST -d and it'll do the same thing for you) now in another console run: % t/TEST -run -verbose api/rflush.t sure, take your time. but please follow up to the list. Sorry Stas, I press automatically the Respond button and realized it was your private account afterwards... will never repeat this. No worries, Alex. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- 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
[mp2] modperl test failed
Hello Stas,
After configuring with MP_DEBUG=1 I've encountered segfault duringconfiguration itself the diagnostic being exactly the same as duringt/TEST (except for damns :). And after make & t/TEST I've got:
[EMAIL PROTECTED] mod_perl-1.99_14]# t/TEST -verbose api/rflush.t[warning] setting ulimit to allow core filesulimit -c unlimited; /usr/bin/perl5.8.1 /usr/local/src/mod_perl-1.99_14/t/TEST -verbose 'api/rflush.t'[warning] root mode: changing the files ownership to 'nobody' (65534:65534)[warning] testing whether 'nobody' is able to -rwx /usr/local/src/mod_perl-1.99_14/t"/usr/bin/perl5.8.1" -Mlib=/usr/local/src/mod_perl-1.99_14/Apache-Test/lib -MApache::TestRun -e 'eval { Apache::TestRun::run_root_fs_test(65534, 65534, q[/usr/local/src/mod_perl-1.99_14/t]) }';
[warning] result: OK[warning] the client side drops 'root' permissions and becomes 'nobody'/usr/local/apache2/bin/httpd -d /usr/local/src/mod_perl-1.99_14/t -f /usr/local/src/mod_perl-1.99_14/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADSusing Apache/2.0.49 (prefork MPM)
waiting 120 seconds for server to start: .[Tue Jun 15 11:53:23 2004] [info] 27 Apache:: modules loaded[Tue Jun 15 11:53:23 2004] [info] 5 APR:: modules loaded[Tue Jun 15 11:53:23 2004] [info] base server + 17 vhosts ready to run testswaiting 120 seconds for server to start: ok (waited 51 secs)server localhost.localdomain:8529 startedserver localhost.localdomain:8530 listening (TestModperl::merge)server localhost.localdomain:8531 listening (TestModperl::perl_options)server localhost.localdomain:8532 listening (TestModperl::setupenv)server localhost.localdomain:8533 listening (TestVhost::config)server localhost.localdomain:8534 listening (TestProtocol::echo_filter)server localhost.localdomain:8535 listening (TestProtocol::echo_timeout)server localhost.localdomain:8536 listening (TestProtocol::echo_block)server localhost.localdomain:8537 listening
(TestPreConnection::note)server localhost.localdomain:8538 listening (TestHooks::stacked_handlers2)server localhost.localdomain:8539 listening (TestHooks::startup)server localhost.localdomain:8540 listening (TestFilter::in_bbs_inject_header)
# Running under perl version 5.008001 for linux# Current time local: Tue Jun 15 11:54:01 2004# Current time GMT: Tue Jun 15 06:54:01 2004# Using Test.pm version 1.24# testing : rflush creates bucket brigades# expected: [][]# received: []not ok 1# Failed test 1 in t/api/rflush.t at line 13FAILED test 1 Failed 1/1 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/api/rflush.t 1 1 100.00% 1 Failed 1/1 test scripts,
0.00% okay. 1/1 subtests failed, 0.00% okay. [warning] server localhost.localdomain:8529 shutdown [warning] port 8529 still in use... ...done [ error] error running tests (please examine t/logs/error_log) [ info] an old core file has been found: /usr/local/src/mod_perl-1.99_14/t/core.29457 [ error] oh dangnabit, server dumped core [ error] for stacktrace, run: gdb /usr/local/apache2/bin/httpd -core /usr/local/src/mod_perl-1.99_14/t/core.29626 After doing so:(gdb) bt#0 0x4032fa74 in Perl_pp_leavesub () from /usr/lib/perl5/5.8.1/i386-linux-thread-multi/CORE/libperl.so
#1 0x082ea5e0 in ?? () #2 0x0918e994 in ?? ()
As I dare guess the fault is not on the modperl side but on the perl's one. So I rather dwell on reinstallation of perl, but my early investigation show that it is uneasy task bearing in mind complex dependencies of mdk packages. One advice is to run two perls - one for system needs and another for apache-perl-modperl tier. Is this advisable?
>>sure, take your time. but please follow up to the list.
Sorry Stas, I press automatically the Respond button and realized itwas your private account afterwards... will never repeat this.
Best regards, Alex Oboimov
ALL-NEW
Yahoo! Messenger - so many
all-new ways to express yourself
Re: Updating Apache and Mod_Perl
I have a simple howto for downloading, building and installing apache 2.0 + mp2 + some extras here: http://shaderlab.com/mod_perl/server_mod_perl_config.txt y David Arnold wrote: All, I've been encouraged on this list to update my versions of Apache and mod_perl, which I think a good suggestion. However, I am no operating system guru (just a math teacher), so I get quite fearful with these updates. Still, I do have an office machine that is quite behind the times, operating system wise: [EMAIL PROTECTED] root]# cat /proc/version Linux version 2.4.18-3 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 Note the Red Hat Linux 7.3. It's my intent to update the operating system on this machine this summer, so this would be a good machine on which to do an experimental update of Apache and mod_perl. If I mangle things badly, I can just resinstall a new version of Red Hat. However, what is the best way to proceed. On Windows, I go the the Uninstall Software tool in the control panel and remove the older piece of software before installing the update. In linux, particularly RedHat, I know that the Apache installation is spread out all over the distribution tree, which is probably far from ideal (why do they do that). To conserve disk space, I'd rather not have two distributions of Apache on the hard drive. So, how do I uninstall the older version before installing the new one? I know it probably has something to do with the rpm utility, but from what I've read over the years, what will probably happen is I will get asked a bunch of questions like "you'll have to remove this or that" which I never know whether to answer "yes" or "no." So, can anyone offer some step-by-step help about uninstalling the older versions of Apache and mod_perl on this machine. Secondly, what do I need to do after that (remember, I have Red Hat 7.3) prior to installing the latest versions of Apache and mod_perl. Once I get to this spot, I think I'll be OK, as the instructions for installing Apache and mod_perl seem pretty good. What I need help with is the uninstall and the other preparation that will be needed before starting the install of Apache and mod_perl. Thanks to anyone kind enough to help me out with this. :-) -- 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: Updating Apache and Mod_Perl
Hi, I would download apache, perl and mod_perl and compile it my own. I would not uninstall anything from your 7.3-rpm-packages. You said that you want to switch to a newer OS version. Please also keep in mind if you want to switch e.g. to Fedora, Mandrake, SuSE that they ship with apache2 + mod_perl2 as standard-apaches. You should develop your mp2-modules for this target platform else you maybe have to port them when switching :-(. The additional diskspace needed is not very big: apache-1.3: ~12MB apache-2.0: ~27MB perl-5.8.4+CPAN-Modules: ~50MB + 10-20MB You could run the apache e.g. on port 8080 instead of the standard port 80. Tom David Arnold wrote: All, I've been encouraged on this list to update my versions of Apache and mod_perl, which I think a good suggestion. However, I am no operating system guru (just a math teacher), so I get quite fearful with these updates. Still, I do have an office machine that is quite behind the times, operating system wise: [EMAIL PROTECTED] root]# cat /proc/version Linux version 2.4.18-3 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 Note the Red Hat Linux 7.3. It's my intent to update the operating system on this machine this summer, so this would be a good machine on which to do an experimental update of Apache and mod_perl. If I mangle things badly, I can just resinstall a new version of Red Hat. However, what is the best way to proceed. On Windows, I go the the Uninstall Software tool in the control panel and remove the older piece of software before installing the update. In linux, particularly RedHat, I know that the Apache installation is spread out all over the distribution tree, which is probably far from ideal (why do they do that). To conserve disk space, I'd rather not have two distributions of Apache on the hard drive. So, how do I uninstall the older version before installing the new one? I know it probably has something to do with the rpm utility, but from what I've read over the years, what will probably happen is I will get asked a bunch of questions like "you'll have to remove this or that" which I never know whether to answer "yes" or "no." So, can anyone offer some step-by-step help about uninstalling the older versions of Apache and mod_perl on this machine. Secondly, what do I need to do after that (remember, I have Red Hat 7.3) prior to installing the latest versions of Apache and mod_perl. Once I get to this spot, I think I'll be OK, as the instructions for installing Apache and mod_perl seem pretty good. What I need help with is the uninstall and the other preparation that will be needed before starting the install of Apache and mod_perl. Thanks to anyone kind enough to help me out with this. :-) -- 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: reverse IP lookup for check all doimains on the server
On 11 Jun 2004, at 23:49, Maxipoint Rep Office wrote: RE: yes I wish reverse lookup from IPs on any server at the web! any help? :-) Sure. What you want to do isn't possible. DNS maps host names to IPs, not generally the other way around. You can lookup $reverse_ip.in-addr.arpa, and hope to get a hostname, but it won't be all hostnames on the IP address - it'll just be one hostname, and possibly not even one that will get you a web site. Sorry. The only way I can think of you even getting moderately close is to crawl through the .com domain zone file, checking each one for a web site at the other end and putting the IP into a DB of your own. Then you can do the reverse mapping on your web site. As you might imagine this only gets you moderately close to a solution. Matt. -- 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
