Re: Recent perl-frameworks broke 1.3 testing..?
On Thu, 3 Jan 2002, Rodent of Unusual Size wrote: > Stas Bekman wrote: > > > > Found the problem, temporary replace > > > > $child_pid = open $child_in_pipe, "|$cmd"; > > > > with: > > > > system "$cmd &"; > > > > in Apache-Test/lib/Apache/TestServer.pm > > Thanks, I'll try that.. > > > Any ideas why this doesn't work with 1.3? Something goes wrong > > with the spawned process. > > Not at the moment; I lack context (like the value of $cmd). the value of $cmd is what get printed, e.g. with 1.3: /home/stas/httpd/1.3/bin/httpd -X -d /home/stas/apache.org/httpd-test/perl-framework/t -f /home/stas/apache.org/httpd-test/perl-framework/t/conf/httpd.conf -DAPACHE1 -DPERL_USEITHREADS now you have the context :) , also see my last email, there is a difference between how apache restarts with 1.x and 2.x. > > BTW, how do you build your 1.3? For some reason I don't get support > > utils built with 'make' have to cd to support and make again. > > The utils are built by 'make install' not by 'make', ISTR. well they don't seem to get built for me. I have to do it manually. Could be some libtool problem. So what are you build args so I can try them? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Recent perl-frameworks broke 1.3 testing..?
On Fri, 4 Jan 2002, Stas Bekman wrote:
> Found the problem, temporary replace
>
> $child_pid = open $child_in_pipe, "|$cmd";
>
> with:
>
> system "$cmd &";
>
> in Apache-Test/lib/Apache/TestServer.pm
>
> the way it was before (well sort of, it's not good in failure cases, but
> at least it starts)
>
> this is because of my latest patch to make t/TEST immediately detect
> failures. Any ideas why this doesn't work with 1.3? Something goes wrong
> with the spawned process.
This seems to work with 1.3 and 2.0:
my $pid = fork();
unless ($pid) {
my $status = system "$cmd";
if ($status) {
$status = $? >> 8;
error "httpd didn't start! $status";
}
CORE::exit $status;
}
instead of system "$cmd &" as it was originally. In this case I can get to
the return status' value with CHLD sighandler.
Surprisingly for 2.0 it's enough to say:
$status = system "httpd ...";
and everything is cool, since system returns almost immediately. Not with
1.3, though it restarts the same way (I guess not exactly the same).
please test this patch (against current cvs) and if it's good I'll commit
it. (it includes all my latest status propagation work, which is not
committed)
Index: Apache-Test/lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.80
diff -u -r1.80 TestRun.pm
--- Apache-Test/lib/Apache/TestRun.pm 31 Dec 2001 09:09:43 - 1.80
+++ Apache-Test/lib/Apache/TestRun.pm 3 Jan 2002 19:14:55 -
@@ -17,6 +17,7 @@
use Config;
use constant STARTUP_TIMEOUT => 300; # secs (good for extreme debug cases)
+use subs qw(exit_shell exit_perl);
my %core_files = ();
@@ -137,7 +138,7 @@
my @invalid_argv = @{ $self->{argv} };
if (@invalid_argv) {
error "unknown opts or test names: @invalid_argv";
-exit;
+exit_perl 0;
}
}
@@ -258,16 +259,17 @@
return unless $_[0] =~ /^Failed/i; #dont catch Test::ok failures
$server->stop(1) if $opts->{'start-httpd'};
$server->failed_msg("error running tests");
+exit_perl 0;
};
$SIG{INT} = sub {
if ($caught_sig_int++) {
warning "\ncaught SIGINT";
-exit;
+exit_perl 0;
}
warning "\nhalting tests";
$server->stop if $opts->{'start-httpd'};
-exit;
+exit_perl 0;
};
#try to make sure we scan for core no matter what happens
@@ -383,17 +385,19 @@
for (@exit_opts) {
next unless exists $self->{opts}->{$_};
my $method = "opt_$_";
-exit if $self->$method();
+exit_perl $self->$method();
}
if ($self->{opts}->{'stop-httpd'}) {
+my $ok = 1;
if ($self->{server}->ping) {
-$self->{server}->stop;
+$ok = $self->{server}->stop;
+$ok = $ok < 0 ? 0 : 1; # adjust to 0/1 logic
}
else {
warning "server $self->{server}->{name} is not running";
}
-exit;
+exit_perl $ok ;
}
}
@@ -407,7 +411,7 @@
($test_config->{APXS} ?
"an apxs other than $test_config->{APXS}" : "apxs").
" or put either in your PATH";
-exit 1;
+exit_perl 0;
}
my $opts = $self->{opts};
@@ -427,7 +431,8 @@
}
if ($opts->{'start-httpd'}) {
-exit 1 unless $server->start;
+my $status = $server->start;
+exit_perl 0 unless $status;
}
elsif ($opts->{'run-tests'}) {
my $is_up = $server->ping
@@ -436,7 +441,7 @@
&& $server->wait_till_is_up(STARTUP_TIMEOUT));
unless ($is_up) {
error "server is not ready yet, try again.";
-exit;
+exit_perl 0;
}
}
}
@@ -464,7 +469,7 @@
sub stop {
my $self = shift;
-$self->{server}->stop if $self->{opts}->{'stop-httpd'};
+return $self->{server}->stop if $self->{opts}->{'stop-httpd'};
}
sub new_test_config {
@@ -491,13 +496,10 @@
}
close $sh;
-open $sh, "|$binsh" or die;
-my @cmd = ("ulimit -c unlimited\n",
- "exec $0 @ARGV");
-warning "setting ulimit to allow core [EMAIL PROTECTED]";
-print $sh @cmd;
-close $sh;
-exit; #exec above will take over
+my $command = "ulimit -c unlimited; $0 @ARGV";
+warning "setting ulimit to allow core files\n$command";
+exec $command;
+die "exec $command has failed"; # shouldn't be reached
}
sub set_ulimit {
@@ -548,13 +550,13 @@
warning "forcing Apache::TestConfig object save";
$self->{test_config}->save;
warning "run 't/TEST -clean' to clean up before continuing";
-exit 1;
+exit_perl 0;
}
}
if ($self->{opts}->{config
Re: Cookie Patch for Flood
On Thu, Jan 03, 2002 at 06:56:16AM -0800, Aaron Bannert wrote: > There's some good info on this site for developers: http://dev.apache.org/ > You'll be particular interested in: http://dev.apache.org/patches.html FWIW, please point people at: http://www.apache.org/dev/ http://httpd.apache.org/dev/ More specifically: http://httpd.apache.org/dev/patches.html Joshua made a commit to change dev.apache.org, but he never updated it. The front page for dev.apache.org now says it is obsolete. I wish that site would just die. -- justin
Re: Recent perl-frameworks broke 1.3 testing..?
Stas Bekman wrote: > > Found the problem, temporary replace > > $child_pid = open $child_in_pipe, "|$cmd"; > > with: > > system "$cmd &"; > > in Apache-Test/lib/Apache/TestServer.pm Thanks, I'll try that.. > Any ideas why this doesn't work with 1.3? Something goes wrong > with the spawned process. Not at the moment; I lack context (like the value of $cmd). > BTW, how do you build your 1.3? For some reason I don't get support > utils built with 'make' have to cd to support and make again. The utils are built by 'make install' not by 'make', ISTR. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "All right everyone! Step away from the glowing hamburger!"
Re: Recent perl-frameworks broke 1.3 testing..?
Found the problem, temporary replace $child_pid = open $child_in_pipe, "|$cmd"; with: system "$cmd &"; in Apache-Test/lib/Apache/TestServer.pm the way it was before (well sort of, it's not good in failure cases, but at least it starts) this is because of my latest patch to make t/TEST immediately detect failures. Any ideas why this doesn't work with 1.3? Something goes wrong with the spawned process. Tomorrow I'll work on it again, good night :) BTW, how do you build your 1.3? For some reason I don't get support utils built with 'make' have to cd to support and make again. To answer your question I can reproduce the problem with 1.3 now. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Recent perl-frameworks broke 1.3 testing..?
Stas Bekman wrote:
>
> it says that the code hangs on line 570 in
> Apache-Test/lib/Apache/TestRun.pm. But sometimes compiler get confused
> by a few lines, so I'm not sure where exactly the problem is. Can you
> please check if it hangs after $self->start()? e.g. add die() after it:
>
> $self->start;
>
> $self->run_tests;
>
> or put the compiler line counter hint before $self->start():
>
> #line 568
> $self->start;
>
> $self->run_tests;
Did this (the #line), and applied your exit-fix patch to TestRun.pm as well.
(Exit status after the SIGUSR2 was 255.) Here's what it says:
using Apache/1.3.23-dev
waiting for server to start: ok (waited 0 secs)
server localhost:8529 started
server localhost:8530 listening (mod_headers)
server localhost:8531 listening (mod_vhost_alias)
caught SIGUSR2! at t/TEST line 19
main::__ANON__('USR2') called at
/home/coar/httpd-test/perl-framework/t/../Apache-Test/lib/Apache/TestRun.pm
line 570
Apache::TestRun::run('Apache::TestRun=HASH(0x8588ef0)', '-v',
'modules/access') called at t/TEST line 22
> probably need to add an alarm or see if we need to supply a timeout for
> UserAgent calls.
Tell me what you want me to add. Can you reproduce this with
your own vanilla framework and Apache 1.3 server?
> Also can you please try again with the patch I've sent in a few
> hours ago?
That was included in this.
> > BTW, it hung all night last night -- like for over 7 hours. I
> > started it before I went to bed.
>
> well, once it hangs it hangs :)
I thought there might be a timeout I was too impatient to be
hitting..
--
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
flood's handling of pool lifetimes/data scoping
I've been thinking about how to handle data lifetime scoping in flood and have come up with a solution, but I want some feedback before I jump in and do it. Theoretically, one instance of flood might need data that is scoped at each of the following lifetimes: all farms each farm all farmers each farmer all profiles each profile and possibly also: each use of a urllist each url in a urllist and maybe even: each flood (global per-process level) Potentially, a lower-level iterator like a profile may want to store data at a higher level like a farm. I don't see it working the other way around, since farms don't know much about their farmers other than when they start and stop. So the question is: How do the lower-level iterators get access to the higher-level scopes (aka pools)? Since we'll always have this hierarchy, perhaps we can take advantage of that somehow to allow a lower level access to it's "parent's" pool? Ideas? -aaron
Re: Cookie Patch for Flood
On Thu, Jan 03, 2002 at 10:02:31AM -0500, Chris Williams wrote: > Yes it is. I will review those links for the next time. Cool, I'll test and commit. Keep 'em comming! :) -aaron
RE: Cookie Patch for Flood
Yes it is. I will review those links for the next time.
Thanks!
Chris
> -Original Message-
> From: Aaron Bannert [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 03, 2002 9:56 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Cookie Patch for Flood
>
>
> On Thu, Jan 03, 2002 at 09:43:48AM -0500, Chris Williams wrote:
> > I found a bug in flood_round_robin.c. The apr_pstrcat on line
> 146 should
> > have NULL as the last argument. I am new to submitting patches so if
> > someone could let me know the correct way to do it, I will
> repost. Without
> > this, you get a bunch of garbage in the cookie string if there
> is more that
> > one cookie.
>
> Thanks for the find! Typically patches are posted as context diffs. If
> you can manage it with your mail, it's best to attach the patches inline
> (as opposed to a mime/uuencoded attachment).
>
> There's some good info on this site for developers: http://dev.apache.org/
> You'll be particular interested in: http://dev.apache.org/patches.html
>
> So is this what you meant?
>
>
> Index: flood_round_robin.c
> ===
> RCS file: /home/cvs/httpd-test/flood/flood_round_robin.c,v
> retrieving revision 1.19
> diff -u -u -r1.19 flood_round_robin.c
> --- flood_round_robin.c 3 Oct 2001 01:24:01 - 1.19
> +++ flood_round_robin.c 3 Jan 2002 14:55:43 -
> @@ -143,7 +143,7 @@
> while (cook)
> {
> if (cook != p->cookie)
> -cookies = apr_pstrcat(p->pool, cookies, ";");
> +cookies = apr_pstrcat(p->pool, cookies, ";", NULL);
>
> cookies = apr_pstrcat(p->pool, cookies, cook->name, "=",
>cook->value, NULL);
>
>
>
Re: Cookie Patch for Flood
On Thu, Jan 03, 2002 at 09:43:48AM -0500, Chris Williams wrote:
> I found a bug in flood_round_robin.c. The apr_pstrcat on line 146 should
> have NULL as the last argument. I am new to submitting patches so if
> someone could let me know the correct way to do it, I will repost. Without
> this, you get a bunch of garbage in the cookie string if there is more that
> one cookie.
Thanks for the find! Typically patches are posted as context diffs. If
you can manage it with your mail, it's best to attach the patches inline
(as opposed to a mime/uuencoded attachment).
There's some good info on this site for developers: http://dev.apache.org/
You'll be particular interested in: http://dev.apache.org/patches.html
So is this what you meant?
Index: flood_round_robin.c
===
RCS file: /home/cvs/httpd-test/flood/flood_round_robin.c,v
retrieving revision 1.19
diff -u -u -r1.19 flood_round_robin.c
--- flood_round_robin.c 3 Oct 2001 01:24:01 - 1.19
+++ flood_round_robin.c 3 Jan 2002 14:55:43 -
@@ -143,7 +143,7 @@
while (cook)
{
if (cook != p->cookie)
-cookies = apr_pstrcat(p->pool, cookies, ";");
+cookies = apr_pstrcat(p->pool, cookies, ";", NULL);
cookies = apr_pstrcat(p->pool, cookies, cook->name, "=",
cook->value, NULL);
Cookie Patch for Flood
I found a bug in flood_round_robin.c. The apr_pstrcat on line 146 should have NULL as the last argument. I am new to submitting patches so if someone could let me know the correct way to do it, I will repost. Without this, you get a bunch of garbage in the cookie string if there is more that one cookie. Thanks Chris
Re: Recent perl-frameworks broke 1.3 testing..?
Rodent of Unusual Size wrote:
* On 2002-01-03 at 08:07,
Stas Bekman <[EMAIL PROTECTED]> excited the electrons to say:
Whenever you have a hanging problem in Perl, the solution is very
simple. Put into your code this:
:
and then kill the process with:
% kill -USR2 PID
And the printed trace will tell you exactly where the code hangs.
Okey, I'll try it -- but I'm not sure which of this
frickin' modules to put it in.. so I'll put it in t/TEST.
That's fine. this is a global sighandler.
Here's what it shows (the bogus ETag value is part of what I'm
trying to test):
server localhost:8530 listening (mod_headers)
server localhost:8531 listening (mod_proxy)
server localhost:8532 listening (mod_vhost_alias)
GET http://localhost:8529/index.html:
User-Agent: libwww-perl/5.62
HTTP/1.1 200 OK
Connection: close
Date: Thu, 03 Jan 2002 13:31:37 GMT
Accept-Ranges: bytes
ETag: ""
Server: Apache/1.3.23-dev (Unix)
Content-Length: 26
Content-Type: text/html
Last-Modified: Mon, 30 Jul 2001 19:37:14 GMT
Client-Date: Thu, 03 Jan 2002 13:31:38 GMT
Client-Peer: 127.0.0.1:8529
caught SIGUSR2! at /tmp/httpd-test/perl-framework/t/TEST line 19
main::__ANON__('USR2') called at
/tmp/httpd-test/perl-framework/t/../Apache-Test/lib/Apache/TestRun.pm line 570
Apache::TestRun::run('Apache::TestRun=HASH(0x85e5ff8)', '-d=lwp', 2,
'apache/limits') called at /tmp/httpd-test/perl-framework/t/TEST line 22
Not very revealing to me..
it says that the code hangs on line 570 in
Apache-Test/lib/Apache/TestRun.pm. But sometimes compiler get confused
by a few lines, so I'm not sure where exactly the problem is. Can you
please check if it hangs after $self->start()? e.g. add die() after it:
$self->start;
$self->run_tests;
or put the compiler line counter hint before $self->start():
#line 568
$self->start;
$self->run_tests;
probably need to add an alarm or see if we need to supply a timeout for
UserAgent calls.
Also can you please try again with the patch I've sent in a few hours ago?
BTW, it hung all night last night -- like for over 7 hours. I started
it before I went to bed.
well, once it hangs it hangs :)
--
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Recent perl-frameworks broke 1.3 testing..?
Rodent of Unusual Size wrote: * On 2002-01-03 at 08:07, William A. Rowe, Jr. <[EMAIL PROTECTED]> excited the electrons to say: t/TEST -d=lwp 2 should show you where things stall, in a bit more detail. Tried that, not very revealing; it just shows the GET of /index.html after the fragment of output I reported earlier. so it hangs while testing whether the server is ready to serve. Can you try to issue some requests with a different user agent to the test server? e.g. lynx --dump http://localhost:8529/index.html does it respond? if could be a server problem. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Recent perl-frameworks broke 1.3 testing..?
* On 2002-01-03 at 08:07,
Stas Bekman <[EMAIL PROTECTED]> excited the electrons to say:
>
> Whenever you have a hanging problem in Perl, the solution is very
> simple. Put into your code this:
:
> and then kill the process with:
>
> % kill -USR2 PID
>
> And the printed trace will tell you exactly where the code hangs.
Okey, I'll try it -- but I'm not sure which of this
frickin' modules to put it in.. so I'll put it in t/TEST.
Here's what it shows (the bogus ETag value is part of what I'm
trying to test):
server localhost:8530 listening (mod_headers)
server localhost:8531 listening (mod_proxy)
server localhost:8532 listening (mod_vhost_alias)
GET http://localhost:8529/index.html:
User-Agent: libwww-perl/5.62
HTTP/1.1 200 OK
Connection: close
Date: Thu, 03 Jan 2002 13:31:37 GMT
Accept-Ranges: bytes
ETag: ""
Server: Apache/1.3.23-dev (Unix)
Content-Length: 26
Content-Type: text/html
Last-Modified: Mon, 30 Jul 2001 19:37:14 GMT
Client-Date: Thu, 03 Jan 2002 13:31:38 GMT
Client-Peer: 127.0.0.1:8529
caught SIGUSR2! at /tmp/httpd-test/perl-framework/t/TEST line 19
main::__ANON__('USR2') called at
/tmp/httpd-test/perl-framework/t/../Apache-Test/lib/Apache/TestRun.pm line 570
Apache::TestRun::run('Apache::TestRun=HASH(0x85e5ff8)', '-d=lwp', 2,
'apache/limits') called at /tmp/httpd-test/perl-framework/t/TEST line 22
Not very revealing to me..
BTW, it hung all night last night -- like for over 7 hours. I started
it before I went to bed.
--
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
Re: Recent perl-frameworks broke 1.3 testing..?
* On 2002-01-03 at 08:07, William A. Rowe, Jr. <[EMAIL PROTECTED]> excited the electrons to say: > > t/TEST -d=lwp 2 > > should show you where things stall, in a bit more detail. Tried that, not very revealing; it just shows the GET of /index.html after the fragment of output I reported earlier. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "All right everyone! Step away from the glowing hamburger!"
[patch] (was Re: perl-framework server startup)
On Thu, 3 Jan 2002, Stas Bekman wrote:
> Rodent of Unusual Size wrote:
>
> > Was this feedback useful, Stas?
>
> Yes, yes. I can reproduce the problem. The respawned shell to set the
> ulimit loses the return status. I'm looking into it. It's a nasty one.
OK, Ken, please try this patch. If it works for you please try it in
various possible failure situations so we can close this issue. Thanks.
this patch changes two "things":
1. uses exec() to call itself for setting ulimit (this solves the lost
status problem). Hope this is portable.
2. directs all exit() calls in PerlRun.pm into one place for two reasons.
- Enable easier debug in the future
- functions like server->stop don't return 0/1 but -1..N, so it helps to
handle the exit arguments properly.
in addition all exit() calls ends in exit_shell, to which you may want to
pass a real return status which can have quite a few values.
Index: Apache-Test/lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.80
diff -u -r1.80 TestRun.pm
--- Apache-Test/lib/Apache/TestRun.pm 31 Dec 2001 09:09:43 - 1.80
+++ Apache-Test/lib/Apache/TestRun.pm 3 Jan 2002 12:27:49 -
@@ -17,6 +17,7 @@
use Config;
use constant STARTUP_TIMEOUT => 300; # secs (good for extreme debug cases)
+use subs qw(exit_shell exit_perl);
my %core_files = ();
@@ -137,7 +138,7 @@
my @invalid_argv = @{ $self->{argv} };
if (@invalid_argv) {
error "unknown opts or test names: @invalid_argv";
-exit;
+exit_perl 0;
}
}
@@ -258,16 +259,17 @@
return unless $_[0] =~ /^Failed/i; #dont catch Test::ok failures
$server->stop(1) if $opts->{'start-httpd'};
$server->failed_msg("error running tests");
+exit_perl 0;
};
$SIG{INT} = sub {
if ($caught_sig_int++) {
warning "\ncaught SIGINT";
-exit;
+exit_perl 0;
}
warning "\nhalting tests";
$server->stop if $opts->{'start-httpd'};
-exit;
+exit_perl 0;
};
#try to make sure we scan for core no matter what happens
@@ -383,17 +385,19 @@
for (@exit_opts) {
next unless exists $self->{opts}->{$_};
my $method = "opt_$_";
-exit if $self->$method();
+exit_perl $self->$method();
}
if ($self->{opts}->{'stop-httpd'}) {
+my $ok = 1;
if ($self->{server}->ping) {
-$self->{server}->stop;
+$ok = $self->{server}->stop;
+$ok = $ok < 0 ? 0 : 1; # adjust to 0/1 logic
}
else {
warning "server $self->{server}->{name} is not running";
}
-exit;
+exit_perl $ok ;
}
}
@@ -407,7 +411,7 @@
($test_config->{APXS} ?
"an apxs other than $test_config->{APXS}" : "apxs").
" or put either in your PATH";
-exit 1;
+exit_perl 0;
}
my $opts = $self->{opts};
@@ -427,7 +431,7 @@
}
if ($opts->{'start-httpd'}) {
-exit 1 unless $server->start;
+exit_perl 0 unless $server->start;
}
elsif ($opts->{'run-tests'}) {
my $is_up = $server->ping
@@ -436,7 +440,7 @@
&& $server->wait_till_is_up(STARTUP_TIMEOUT));
unless ($is_up) {
error "server is not ready yet, try again.";
-exit;
+exit_perl 0;
}
}
}
@@ -464,7 +468,7 @@
sub stop {
my $self = shift;
-$self->{server}->stop if $self->{opts}->{'stop-httpd'};
+return $self->{server}->stop if $self->{opts}->{'stop-httpd'};
}
sub new_test_config {
@@ -491,13 +495,10 @@
}
close $sh;
-open $sh, "|$binsh" or die;
-my @cmd = ("ulimit -c unlimited\n",
- "exec $0 @ARGV");
-warning "setting ulimit to allow core [EMAIL PROTECTED]";
-print $sh @cmd;
-close $sh;
-exit; #exec above will take over
+my $command = "ulimit -c unlimited; $0 @ARGV";
+warning "setting ulimit to allow core files\n$command";
+exec $command;
+die "exec $command has failed"; # shouldn't be reached
}
sub set_ulimit {
@@ -548,13 +549,13 @@
warning "forcing Apache::TestConfig object save";
$self->{test_config}->save;
warning "run 't/TEST -clean' to clean up before continuing";
-exit 1;
+exit_perl 0;
}
}
if ($self->{opts}->{configure}) {
warning "reconfiguration done";
-exit;
+exit_perl 1;
}
$self->try_exit_opts;
@@ -770,5 +771,18 @@
}
+# in idiomatic perl functions return 1 on success 0 on
+# failure. Shell expects the opposite behavior. So this function
+# reverses the status.
+sub exit_perl {
+exit_shell $_[0] ? 0 : 1;
+}
+
+# expects shell's exit status values (0==success)
+sub exit_shell {
+#require Car
Re: perl-framework server startup
Rodent of Unusual Size wrote: Was this feedback useful, Stas? Yes, yes. I can reproduce the problem. The respawned shell to set the ulimit loses the return status. I'm looking into it. It's a nasty one. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Recent perl-frameworks broke 1.3 testing..?
Sorry I'm not using that bug_report.pl (or whatever it
was) script, Stas, but it doesn't appear to be part of
the httpd-test repository. Apologies also for not being
much help in debugging these things, but I just can't
trace my way through the Deep Magic variety of Perl
used here..
It's moved. Now it's autogenerated and named t/REPORT.
Whenever you have a hanging problem in Perl, the solution is very
simple. Put into your code this:
use Carp ();
$SIG{'USR2'} = sub {
Carp::confess("caught SIGUSR2!");
};
and then kill the process with:
% kill -USR2 PID
And the printed trace will tell you exactly where the code hangs.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Recent perl-frameworks broke 1.3 testing..?
From: "Rodent of Unusual Size" <[EMAIL PROTECTED]> Sent: Wednesday, January 02, 2002 10:47 PM > Maybe it's because of all the attention on 2.0, but suddenly > t/TEST is hanging when run against a 1.3 server. This is > new behaviour since 2 December 2001, when it was working > fine. t/TEST -d=lwp 2 should show you where things stall, in a bit more detail.
Recent perl-frameworks broke 1.3 testing..?
Maybe it's because of all the attention on 2.0, but suddenly t/TEST is hanging when run against a 1.3 server. This is new behaviour since 2 December 2001, when it was working fine. What I get now is: % t/TEST setting ulimit to allow core files ulimit -c unlimited exec t/TEST -v apache/etags /tmp/ap1/bin/httpd -X -d /home/coar/httpd-test/perl-framework/t -f /home/coar/httpd-test/perl-framework/t/conf/httpd.conf -DAPACHE1 using Apache/1.3.23-dev waiting for server to start: ok (waited 0 secs) server localhost:8529 started server localhost:8530 listening (mod_headers) server localhost:8531 listening (mod_proxy) server localhost:8532 listening (mod_vhost_alias) and there it sits. It sat there for longer than ten minutes. This is repeatable, and I don't know what it's waiting for -- I can telnet to localhost:8529 and 'HEAD / HTTP/1.0' just fine. This is with a completely vanilla checkout of the test framework, and a slightly patched server. I *believe* I tested it with a completely vanilla server, too, but I'm not positive. Sorry I'm not using that bug_report.pl (or whatever it was) script, Stas, but it doesn't appear to be part of the httpd-test repository. Apologies also for not being much help in debugging these things, but I just can't trace my way through the Deep Magic variety of Perl used here.. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "All right everyone! Step away from the glowing hamburger!"
Outch - what a tangled web.
I've been diagnosing our failures of httpd.
My Win32 machine has the usual, bogus computer name (v505, in my case.)
There is no 'magic' DNS going on, Win32 is usually clueless. And since
I cannot convice my machine to look in any DNS other than the 'blessed
Windows Domain Server' [I have none], I'd created a few entries in the
local HOSTS file that map my www#.rowe-clan.net addresses to their true
IP addresses. Now Win32 and the rest of the world can agree on names.
A typical machine with a BSD-derrived stack should do the following;
use Socket ();
my $lip = Socket::inet_aton('localhost');
my $slip = join('.', unpack("C4",$lip));
print "localhost is at $slip\n";
my $lname = gethostbyaddr($lip, Socket::AF_INET());
print "$slip is named $lname\n";
my $rip = Socket::inet_aton($lname);
my $srip = join('.', unpack("C4",$rip));
print "$lname is at $srip\n";
my $rname = gethostbyaddr($rip, Socket::AF_INET());
print "$srip is named $rname\n";
The results?
localhost is at 127.0.0.1
127.0.0.1 is named localhost
localhost is at 127.0.0.1
127.0.0.1 is named localhost
But Windows is a different beast;
localhost is at 127.0.0.1
127.0.0.1 is named v505
v505 is at 208.176.192.147
208.176.192.147 is named www2.rowe-clan.net
That's a leap, wouldn't you say?
This is what is causing the httpd-tests for t/modules/access.t to fail,
since the machine isn't sure which stack its on.
This has some pretty big ramifications, I think, when we start to look
at a big picture. The following little patch solves the problems.
Index: Apache-Test/lib/Apache/TestConfig.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.118
diff -u -r1.118 TestConfig.pm
--- Apache-Test/lib/Apache/TestConfig.pm 31 Dec 2001 06:39:30 - 1.118
+++ Apache-Test/lib/Apache/TestConfig.pm 3 Jan 2002 00:29:49 -
@@ -478,6 +478,13 @@
sub default_servername {
my $self = shift;
$localhost ||= $self->default_localhost;
+if (WIN32) {
+my $ip = Socket::inet_aton($localhost);
+if ($ip ne pack('C4', 127, 0, 0, 1)) {
+$localhost = gethostbyaddr($ip, 'localhost');
+}
+}
+$localhost;
}
#XXX: could check if the port is in use and select another if so
And all tests begin to fly :) So I took this a step further, and thought,
heck, why not the remote name?
Index: Apache-Test/lib/Apache/TestConfig.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.118
diff -u -r1.118 TestConfig.pm
--- Apache-Test/lib/Apache/TestConfig.pm 31 Dec 2001 06:39:30 - 1.118
+++ Apache-Test/lib/Apache/TestConfig.pm 3 Jan 2002 00:31:02 -
@@ -478,6 +478,13 @@
sub default_servername {
my $self = shift;
$localhost ||= $self->default_localhost;
+if (WIN32) {
+my $ip = Socket::inet_aton($localhost);
+if ($ip ne pack('C4', 127, 0, 0, 1)) {
+$localhost = gethostbyaddr($ip, Socket::AF_INET());
+}
+}
+$localhost;
}
#XXX: could check if the port is in use and select another if so
Which should do pretty much the same bit, and uses my www2.rowe-clan.net name.
Unfortuantely, that bites. Fails vhost_alias and all SSL tests. So now we know
this affecting the perl tests, and vhosts through APR.
I don't have any quick solutions, but I figured I better draw this out before it
begins to bite others.
So
Bill
