You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by William McKee <wi...@knowmad.com> on 2005/02/13 20:37:51 UTC
[mp2] make test errors
-------------8<---------- Start Bug Report ------------8<----------
1. Problem Description:
While installing mod_perl2 on a FreeBSD 5.3 jail environment, I received
the following test errors:
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/filter/both_str_con_add.t 4 3 75.00% 2-4
t/preconnection/note.t 1 1 100.00% 1
t/protocol/echo_block.t 3 2 66.67% 2-3
t/protocol/echo_filter.t 3 2 66.67% 2-3
t/protocol/pseudo_http.t 13 9 69.23% 3-8 11-13
18 tests skipped.
Failed 5/222 test scripts, 97.75% okay. 17/2105 subtests failed, 99.19% okay.
No output in the error_log indicated a problem. I subsequently ran each
failing test in verbose mode. Here is the failing output:
t/TEST t/filter/both_str_con_add.t -v
# expected: 2.0
# received:
not ok 3
# expected: rules
# received:
not ok 4
t/TEST t/preconnection/note.t -v
# testing : connection notes
# Failed test 1 in t/preconnection/note.t at line 16
# expected: 127.0.0.1
# received: 166.70.252.34
t/TEST t/protocol/echo_block.t -v
# Failed test 2 in t/protocol/echo_block.t at line 22
# expected: hello
# received:
# Failed test 3 in t/protocol/echo_block.t at line 22 fail #2
not ok 2
# expected: world
# received:
not ok 3
t/TEST t/protocol/echo_filter.t -v
# expected: HELLO
# received:
not ok 2
# Failed test 2 in t/protocol/echo_filter.t at line 22
# expected: WORLD
# received:
not ok 3
# Failed test 3 in t/protocol/echo_filter.t at line 22 fail #2
t/TEST t/protocol/pseudo_http.t -v
# send: HELO
# testing : login
# expected: Login:
# Failed test 3 in t/protocol/pseudo_http.t at line 63 fail #2
# received:
not ok 3
# send: stas
# testing : good password
# Failed test 4 in t/protocol/pseudo_http.t at line 63 fail #3
# expected: Password:
# Failed test 5 in t/protocol/pseudo_http.t at line 57
# received:
not ok 4
# Failed test 6 in t/protocol/pseudo_http.t at line 63 fail #4
# send: foobar
# Failed test 7 in t/protocol/pseudo_http.t at line 63 fail #5
# testing : banner
# Failed test 8 in t/protocol/pseudo_http.t at line 57 fail #2
# expected: Welcome to TestProtocol::pseudo_http
# received:
not ok 5
# testing : date
# expected: Available commands: date quit
# received:
not ok 6
# send: date
# testing : quit
# expected: (?-xism:The time is:)
# received:
not ok 7
# send: quit
# testing : end of transmission
# expected: Goodbye
# received:
not ok 8
ok 9
# testing : greeting
# expected: HELO
# received: HELO
ok 10
# send: HELO
# testing : login
# expected: Login:
# received:
# Failed test 11 in t/protocol/pseudo_http.t at line 63 fail #7
not ok 11
# send: stas
# testing : wrong password
# expected: Password:
# Failed test 12 in t/protocol/pseudo_http.t at line 63 fail #8
# Failed test 13 in t/protocol/pseudo_http.t at line 57 fail #3
# received:
not ok 12
# send: foObaR
# testing : end of transmission
# expected: Access Denied
# received:
not ok 13
2. Used Components and their Configuration:
*** mod_perl version 1.999021
*** using /stubs/usr_local/src/mod_perl-2.0.0-RC4/lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_APR_LIB => aprext
MP_AP_CONFIGURE => --with-mpm=prefork
MP_AP_PREFIX => /usr/local/src/httpd-2.0.53_perl
MP_COMPAT_1X => 1
MP_GENERATE_XS => 1
MP_LIBNAME => mod_perl
MP_USE_STATIC => 1
*** /usr/local/src/httpd-2.0.53_perl/httpd -V
Server version: Apache/2.0.53
Server built: Feb 13 2005 11:43:35
Server's Module Magic Number: 20020903:9
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses disabled)
-D APR_USE_FLOCK_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/usr/local/apache2"
-D SUEXEC_BIN="/usr/local/apache2/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
*** (apr|apu)-config linking info
-L/usr/local/src/httpd-2.0.53_perl/srclib/apr/.libs
-L/usr/local/src/httpd-2.0.53_perl/srclib/apr -lapr-0 -lm -lcrypt
-L/usr/local/src/httpd-2.0.53_perl/srclib/apr-util/.libs
-L/usr/local/src/httpd-2.0.53_perl/srclib/apr-util -laprutil-0 /usr/local/src/httpd-2.0.53_perl/srclib/apr-util/xml/expat/lib/libexpat.la
*** /usr/public/bin/perl -V
Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
Platform:
osname=freebsd, osvers=5.3-release-p5, archname=i386-freebsd-64int
uname='freebsd hobbiton.shire.net 5.3-release-p5 freebsd 5.3-release-p5 #3: thu feb 3 23:10:24 mst 2005 chad@bywater.shire.net:usrobjusrsrcsysbywater-smp i386 '
config_args='-sde -Dprefix=/usr/public -Dotherlibdirs=/usr/local/lib/perl5/5.8.6 -Darchlib=/usr/public/lib/perl5/5.8.6/mach -Dprivlib=/usr/public/lib/perl5/5.8.6 -Dman3dir=/usr/public/lib/perl5/5.8.6/perl/man/man3 -Dman1dir=/usr/public/man/man1 -Dsitearch=/usr/public/lib/perl5/site_perl/5.8.6/mach -Dsitelib=/usr/public/lib/perl5/site_perl/5.8.6 -Dscriptdir=/usr/public/bin -Dsiteman3dir=/usr/public/lib/perl5/5.8.6/man/man3 -Dsiteman1dir=/usr/public/man/man1 -Ui_malloc -Ui_iconv -Uinstallusrbinperl -Dcc=cc -Doptimize=-O -pipe -Duseshrplib -Dccflags=-DAPPLLIB_EXP="/usr/public/lib/perl5/5.8.6/BSDPAN" -Ud_dosuid -Ui_gdbm -Dusethreads=n -Dusemymalloc=y -Duse64bitint'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=undef
usemymalloc=y, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-DAPPLLIB_EXP="/usr/public/lib/perl5/5.8.6/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include',
optimize='-O -pipe ',
cppflags='-DAPPLLIB_EXP="/usr/public/lib/perl5/5.8.6/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include'
ccversion='', gccversion='3.4.2 [FreeBSD] 20040728', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -Wl,-E -L/usr/local/lib'
libpth=/usr/lib /usr/local/lib
libs=-lm -lcrypt -lutil
perllibs=-lm -lcrypt -lutil
libc=, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-R/usr/public/lib/perl5/5.8.6/mach/CORE'
cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_64_BIT_INT USE_LARGE_FILES
Locally applied patches:
SUIDPERLIO0 - fix PERLIO_DEBUG local root exploit (CAN-2005-0155)
SUIDPERLIO1 - fix PERLIO_DEBUG buffer overflow (CAN-2005-0156)
Built under freebsd
Compiled at Feb 12 2005 14:28:45
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
/usr/public/lib/perl5/site_perl/5.8.6/mach
/usr/public/lib/perl5/site_perl/5.8.6
/usr/public/lib/perl5/site_perl
/usr/public/lib/perl5/5.8.6/BSDPAN
/usr/public/lib/perl5/5.8.6/mach
/usr/public/lib/perl5/5.8.6
/usr/local/lib/perl5/5.8.6
.
*** Packages of interest status:
Apache::Request: -
CGI : 3.05
LWP : -
mod_perl : -
3. This is the core dump trace: (if you get a core dump):
[CORE TRACE COMES HERE]
This report was generated by t/REPORT on Sun Feb 13 17:45:16 2005 GMT.
-------------8<---------- End Bug Report --------------8<----------
Note: Complete the rest of the details and post this bug report to
modperl <at> perl.apache.org. To subscribe to the list send an empty
email to modperl-subscribe@perl.apache.org.
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by William McKee <wi...@knowmad.com>.
On Tue, Feb 15, 2005 at 06:41:04PM -0500, Stas Bekman wrote:
> I think there were a few similar reports posted here before (check the
> archives). Unfortunately no one running FreeBSD has volunteered to look at
> those. From what we have seen before all test failures seem to be caused
> by some socket problems in the underlying C libs.
That makes sense as I'm running inside a jailed process which has
limited access to sockets. I wonder if there's a way to test for this
condition and skip the failing tests. I'll check the archives and see
what I can learn.
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by William McKee <wi...@knowmad.com>.
On Wed, Feb 16, 2005 at 04:12:34PM -0500, Stas Bekman wrote:
> Don't forget that we are talking about APR socket API, not perl socket
> API, which aren't the same.
Oh, right, I hadn't really considered that. Hopefully it's at least
useful to see that the perl sockets are working.
> I've never said that it's the fact that your run in the jailed
> environment is the cause of the problem. It's just that we saw exactly
> the same reports earlier, that made me think of APR socket API, but it
> could be something else too.
Actually, I'm the one that postulated the jailed environment as the
cause of the problem. Socket support is limited inside of jailed
processes. However, since the perl socket API works, this may be an
issue with APR socket (or the test).
> you can add debug prints on the server side to see what goes wrong.
> Unfortunately no tracing is available for sockets IO, since it's
> impelemented entirely by Apache.
OK.
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> I didn't get very far with debugging the test (basically the test server
> got started and I lost control of the debugger). At any rate, I found
> some more information about sockets inside of jailed environments[1].
> Section 4.2.2 seems to indicate that the type of socket we are creating
> in the following code from A::TestRequest is OK:
>
> require IO::Socket;
> return IO::Socket::INET->new(%args);
Don't forget that we are talking about APR socket API, not perl socket
API, which aren't the same. I've never said that it's the fact that your
run in the jailed environment is the cause of the problem. It's just that
we saw exactly the same reports earlier, that made me think of APR socket
API, but it could be something else too.
you can add debug prints on the server side to see what goes wrong.
Unfortunately no tracing is available for sockets IO, since it's
impelemented entirely by Apache.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] make test errors
Posted by William McKee <wi...@knowmad.com>.
I didn't get very far with debugging the test (basically the test server
got started and I lost control of the debugger). At any rate, I found
some more information about sockets inside of jailed environments[1].
Section 4.2.2 seems to indicate that the type of socket we are creating
in the following code from A::TestRequest is OK:
require IO::Socket;
return IO::Socket::INET->new(%args);
As an alternate approach, I've created a test script that opens a socket
to the test webserver and prints the same strings from the test. First,
I start the test servers via t/TEST -start. Then I run my attached
script. The output is as expected. I think this is a good thing but
probably means there is a problem somewhere in the test scripts. Any
ideas for tracking this one down?
As for determing whether we are running inside of a jail, there are
several techniques. The simplest seems to be checking the output of 'df
/' to see if it reports being mounted on a different filesystem (e.g.,
/local/jails in my case). Other solutions require C code or additional
packages[2].
William
[1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/jail-restrictions.html
[2] http://memberwebs.com/nielsen/freebsd/jails/jailutils/
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by William McKee <wi...@knowmad.com>.
Stas (and anyone else using FreeBSD),
I tried searching the archives but didn't find anything that
specifically addressed the errors I'm having. As shown in my original
bug report, I'm using FreeBSD 5.3 in a jailed (chrooted) environment.
I'm willing to dig into the test errors if you can give me some
assistance (I've not much experience with the IO::* modules).
I've started with t/filter/both_str_con_add.t. This test opens a socket
using the following code:
my $module = "TestFilter::both_str_con_add";
my $socket = Apache::TestRequest::vhost_socket($module);
It then proceeds to print 3 strings to the socket and read the reply.
The first test works, the following two fail. It seems to me that if one
works, they all should work. If that's the case, then this error may be
pointing to more problems than missing socket support in a jailed
environment as I had originally surmised.
Can you give me any pointers for further testing? I'm going to try the
debugger to see what I can find but am not very familiar with the
codebase.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> -------------8<---------- Start Bug Report ------------8<----------
> 1. Problem Description:
>
> While installing mod_perl2 on a FreeBSD 5.3 jail environment, I received
> the following test errors:
>
> Failed Test Stat Wstat Total Fail Failed List of Failed
> -------------------------------------------------------------------------------
> t/filter/both_str_con_add.t 4 3 75.00% 2-4
> t/preconnection/note.t 1 1 100.00% 1
> t/protocol/echo_block.t 3 2 66.67% 2-3
> t/protocol/echo_filter.t 3 2 66.67% 2-3
> t/protocol/pseudo_http.t 13 9 69.23% 3-8 11-13
> 18 tests skipped.
> Failed 5/222 test scripts, 97.75% okay. 17/2105 subtests failed, 99.19% okay.
>
> No output in the error_log indicated a problem. I subsequently ran each
> failing test in verbose mode. Here is the failing output:
I think there were a few similar reports posted here before (check the
archives). Unfortunately no one running FreeBSD has volunteered to look at
those. From what we have seen before all test failures seem to be caused
by some socket problems in the underlying C libs.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] make test errors
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Wed, Feb 16, 2005 at 07:14:24PM -0500, Stas Bekman wrote:
>
>>>Yes, it is (though keep in mind that this is a virtual server running as
>>>a jailed process, not a separate machine).
>>
>>That could be the reason.
>
>
> But if I open a lynx session and surf over to localhost, my server comes
> up fine.
I've never said it was wrong. As you know when you assign your machine an
IP, it can still internally be accessed by loopback device which is always
127.0.0.1 or ::1 on ipv6 machines.
>>Well, basically you want to figure out how to make Apache-Test see the
>>same value as Apache. i.e. teach our_remote_addr() to get the same value.
>
>
> It's Apache::Connection which defines the remote_ip() function that is
> getting the full ip, as opposed to our_remote_addr() which gets the
> ip defined by localhost (127.0.0.1).
>
> Since the test is for pnotes, we could change the test. However, I
> suspect it'd be better to figure out what's causing the difference
> between the two functions. Is this the right place to file a bug report
> against Apache::Connection?
There is no problem with Apache::Connection. There is no "problem" at all.
As explained above both are correct. For the sake of the test all we want
is that they agree. That's why I have asked you to figure out how to match
our_remote_addr() with remote_ip(), since the latter can't be changed.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] make test errors
Posted by William McKee <wi...@knowmad.com>.
On Wed, Feb 16, 2005 at 07:14:24PM -0500, Stas Bekman wrote:
> >Yes, it is (though keep in mind that this is a virtual server running as
> >a jailed process, not a separate machine).
>
> That could be the reason.
But if I open a lynx session and surf over to localhost, my server comes
up fine.
> Well, basically you want to figure out how to make Apache-Test see the
> same value as Apache. i.e. teach our_remote_addr() to get the same value.
It's Apache::Connection which defines the remote_ip() function that is
getting the full ip, as opposed to our_remote_addr() which gets the
ip defined by localhost (127.0.0.1).
Since the test is for pnotes, we could change the test. However, I
suspect it'd be better to figure out what's causing the difference
between the two functions. Is this the right place to file a bug report
against Apache::Connection?
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Wed, Feb 16, 2005 at 04:06:39PM -0500, Stas Bekman wrote:
>
>>whereas Apache-Test sees 127.0.0.1. I suppose 166.70.252.34
>>is the external IP of the same machine.
>
>
> Yes, it is (though keep in mind that this is a virtual server running as
> a jailed process, not a separate machine).
That could be the reason.
>>Try to debug our_remote_addr() in Apache/TestConfig.pm to figure out why
>>there is a difference (most likely it defaults to resolving 'localhost')
>
> OK, here's a dump of the gethostbyname function:
>
> # ghbn = $VAR1 = [
> 'localhost',
> 'localhost.my.domain',
> 2,
> 4,
> ''
> ];
>
> The last item in the list is showing up in an odd format which I'm not
> able to reproduce here (perhaps this is an opaque string?). At any rate,
> remote_addr is empty so the value that is being returned by
> our_remote_addr() is coming from passing the iaddr value to
> Socket::inet_ntoa. Here's the relevant contents of my /etc/hosts:
>
> ::1 localhost localhost.my.domain
> 127.0.0.1 localhost localhost.my.domain
>
> I tried removing that first entry but it made no difference. This is
> definitly beyond my level of knowledge so hopefully you can give me some
> further pointers for what to look at next.
Well, basically you want to figure out how to make Apache-Test see the
same value as Apache. i.e. teach our_remote_addr() to get the same value.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] make test errors
Posted by William McKee <wi...@knowmad.com>.
On Wed, Feb 16, 2005 at 04:06:39PM -0500, Stas Bekman wrote:
> whereas Apache-Test sees 127.0.0.1. I suppose 166.70.252.34
> is the external IP of the same machine.
Yes, it is (though keep in mind that this is a virtual server running as
a jailed process, not a separate machine).
> Try to debug our_remote_addr() in Apache/TestConfig.pm to figure out why
> there is a difference (most likely it defaults to resolving 'localhost')
OK, here's a dump of the gethostbyname function:
# ghbn = $VAR1 = [
'localhost',
'localhost.my.domain',
2,
4,
''
];
The last item in the list is showing up in an odd format which I'm not
able to reproduce here (perhaps this is an opaque string?). At any rate,
remote_addr is empty so the value that is being returned by
our_remote_addr() is coming from passing the iaddr value to
Socket::inet_ntoa. Here's the relevant contents of my /etc/hosts:
::1 localhost localhost.my.domain
127.0.0.1 localhost localhost.my.domain
I tried removing that first entry but it made no difference. This is
definitly beyond my level of knowledge so hopefully you can give me some
further pointers for what to look at next.
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
BTW, this is a different issue:
> t/TEST t/preconnection/note.t -v
> # testing : connection notes
> # Failed test 1 in t/preconnection/note.t at line 16
> # expected: 127.0.0.1
> # received: 166.70.252.34
Here the Apache API:
my $ip = $c->remote_ip;
sees 166.70.252.34
whereas Apache-Test sees 127.0.0.1. I suppose 166.70.252.34
is the external IP of the same machine.
Try to debug our_remote_addr() in Apache/TestConfig.pm to figure out why
there is a difference (most likely it defaults to resolving 'localhost')
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] make test errors
Posted by William McKee <wi...@knowmad.com>.
On Wed, Feb 16, 2005 at 07:12:11PM -0500, Stas Bekman wrote:
> please look at your original report, William, it was failing the same 2
> sub-tests.
That's weird because it's only failing one if I run it by itself. This
obviously wasn't the case earlier when I reported the error. At any
rate, this appears to be a APR issue which I'll try to take up with the
appropriate developers.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> On Fri, Feb 18, 2005 at 05:35:56PM -0500, Stas Bekman wrote:
>
>>Joe, shouldn't the APR API emit some kind of errors in the situation like
>>William has with jail env+ac_cv_o_nonblock_inherited thingy, rather than
>>silently fail?
>
>
> The issue is that the configure test couldn't make a decision, but
> configure tests are always binary yes/no not yes/no/dunno and that's
> really the nature of the beast.
>
> The only viable solution to this type of problem in general is to ensure
> that the APR test suite catches it by checking that the determined
> behaviour matches the actual behaviour; then you can say to people who
> see these weird mod_perl failures "go run the APR test suite" and have a
> simpler path to diagnose the problem.
As you've seen, Joe, it's not obvious right away what the problem is, so
that proposal is not quite sufficient. Do you suggest that if an explicit
call to make a blocking IO is made and apr ignored it silently it's a
correct behavior? Or do you suggest that there is no possible way to
detect that that call has failed, and therefore it can't report the failure?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] make test errors
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Feb 18, 2005 at 05:35:56PM -0500, Stas Bekman wrote:
> Joe, shouldn't the APR API emit some kind of errors in the situation like
> William has with jail env+ac_cv_o_nonblock_inherited thingy, rather than
> silently fail?
The issue is that the configure test couldn't make a decision, but
configure tests are always binary yes/no not yes/no/dunno and that's
really the nature of the beast.
The only viable solution to this type of problem in general is to ensure
that the APR test suite catches it by checking that the determined
behaviour matches the actual behaviour; then you can say to people who
see these weird mod_perl failures "go run the APR test suite" and have a
simpler path to diagnose the problem.
Maybe it already *does* catch this problem, I don't know.
joe
Re: [mp2] make test errors
Posted by Stas Bekman <st...@stason.org>.
Joe, shouldn't the APR API emit some kind of errors in the situation like
William has with jail env+ac_cv_o_nonblock_inherited thingy, rather than
silently fail?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] make test errors
Posted by William McKee <wi...@knowmad.com>.
On Fri, Feb 18, 2005 at 10:15:19AM -0500, William McKee wrote:
> Actually, I suppose that I could try running the nonblock script first
> to see if that works.
I was able to get my hosting provider to run the nonblock program
outside of a jailed process and it works. We've been trying to figure
out why it is failing in a jail.
Interestingly, it is able to obtain a listener socket but when it goes
to get a client socket, it is failing. If instead of using the 0.0.0.0
sin_addr, I specify address as 127.0.0.1, the code works. We are
submitting this info to the freebsd developers. Will post back with more
info later.
Thanks for helping me track this down. It's been quite edifying to learn
more about the lower levels of the network model.
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by William McKee <wi...@knowmad.com>.
On Fri, Feb 18, 2005 at 01:40:44PM +0000, Joe Orton wrote:
> That confirms that the problem: you got a connect() failure when the
> configure test program attempted to a listener bound to 0.0.0.0
OK.
> You can try the standalone test program here to reproduce the failure:
Yes, that seems to be failing. Here's the output:
$ ./nonblock
bound to 0.0.0.0:11719
connect: Connection refused
> It could be some firewalling thing in how the machine is set up.
OK, so to bring us back around to the failing mod_perl tests, I belive
your next advice would be to compile and test it under a normal account
in a non-jail process to see if the same behavior manifests. I'll try to
do that soon and report back. Actually, I suppose that I could try
running the nonblock script first to see if that works.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Feb 17, 2005 at 03:05:31PM -0500, William McKee wrote:
> On Thu, Feb 17, 2005 at 04:53:45PM +0000, Joe Orton wrote:
> > Check for the result of the:
> >
> > "checking if O_NONBLOCK setting is inherited from listening sockets"
> >
> > test when you run the configure script.
>
> I wasn't sure if you were referring to the mod_perl or Apache configure
> script. When I ran the following command, the setting was no:
>
> perl Makefile.PL PREFIX=/usr/local MP_USE_STATIC=1
> MP_AP_PREFIX=/usr/local/src/httpd-2.0.53_perl
> MP_AP_CONFIGURE="--with-mpm=prefork --prefix=/usr/local/apache2_perl"
>
> The config.log file from that command is temporarily available here[1].
That confirms that the problem: you got a connect() failure when the
configure test program attempted to a listener bound to 0.0.0.0
You can try the standalone test program here to reproduce the failure:
http://www.apache.org/~jorton/nonblock.c
It could be some firewalling thing in how the machine is set up.
joe
Re: [mp2] make test errors
Posted by William McKee <wi...@knowmad.com>.
On Wed, Jun 08, 2005 at 12:00:01AM +1000, Stas Bekman wrote:
> Great! William, can you please write a new entry for the troubleshooting
> chapter? With a full diagnosis and the solution? Really it should belong
> to the Apache-Test troubleshooting, but as at the moment it doesn't exist,
> we will just put it into the mp2's one.
> http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html
Hi Stas,
I'm still alive; just been swamped. I'm not attaching this write-up as a
patch since I'm not sure where you'd want to put it within the
troubleshooting document. I'm not sure if I can provide a full diagnosis
as it's been awhile since I did this work, and I'm still having some
tests fail. It must have been the full moon and holding my tongue right
that made it work with no failures in my last report to you.
Nonetheless, the info below does clear up some of the errors I
originally reported back on Feb 13. If you can think of other details
that I should include, let me know and I'll dig up the messages from the
archives. BTW, I just built and tested mp 2.0.1 with Apache 2.0.54 on
FreeBSD 5.4 and all but 4 tests are passing.
-------------
Running tests inside a chroot environment
If you are building your Apache and mod_perl inside a chroot
environment, such as a FreeBSD jail, you may need to edit your
/etc/hosts file to add a localhost entry that resolves to to the ip
address of the jail rather than the default 127.0.0.1.
-------------
> >Also, the t/protocol/echo_filter.t test is failing. It runs tests 1 and
> >2 then keeps running until it fills up the disk space then dumps a
> >massive core file. I'm just skipping it for now.
>
> Yeah, I guess you are hitting again the non-blocking socket issue
> FreeBSD. Please check the archives (I think on the dev list) talking
> about passing some special flag while building libapr to make the
> sockets work right. Unfortunately it didn't end up in the docs and I
> don't have the info handy.
I've not been able to come across these messages which is too bad as the
4 failing tests (t/filter/both_str_con_ad, t/protocol/echo_block,
t/protocol/echo_filter, and t/protocol/pseudo_http) all seem to be
failing due to sockets. I noticed that 2.0.54 has APR 0.9.6 which
includes a FreeBSD-specific update from 0.9.5:
*) Fix apr_socket_opt_set with APR_IPV6_V6ONLY flag. Fixes httpd
Listen IPv6 socket behavior on FreeBSD 5.x, OpenBSD, NetBSD.
[Justin Erenkrantz]
Is this the one you were thinking of? I couldn't see where I needed to
pass any special flags to enable it.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> Stas,
>
> It's been awhile, but I'm back to working on these tests under FreeBSD
> 5.3 with mp2. I'm using the current release (2.0.0) with Apache 2.0.54.
> The root of many of my problems appears to be how Apache is resolving my
> localhost address. Apparently FBSD resolves localhost to my Jail IP.
> Apache is expecting the more usual 127.0.0.1. I was able to resolve the
> issues reported below by adding the following line to my /etc/hosts file
> above all other definitions:
>
> 192.168.1.1 localhost
Great! William, can you please write a new entry for the troubleshooting
chapter? With a full diagnosis and the solution? Really it should belong
to the Apache-Test troubleshooting, but as at the moment it doesn't exist,
we will just put it into the mp2's one.
http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html
> Assuming my jail ip was 192.168.1.1 this works and most tests are now
> pasing. Thanks for bearing with me while I came to an understanding
> about the behavior of localhost within a jail.
>
> Currently, I'm still having troubles with t/filter/both_str_con_add.t.
> Here's the output:
>
> t/filter/both_str_con_add....1..4
[...]
> In both cases, the first string works but the following ones are
> failing. My guess is that the culprit is
>
> my $socket = Apache::TestRequest::vhost_socket
>
> which is used across all three of the failing tests. I'll try to spend
> some more time on it later today.
>
> Also, the t/protocol/echo_filter.t test is failing. It runs tests 1 and
> 2 then keeps running until it fills up the disk space then dumps a
> massive core file. I'm just skipping it for now.
Yeah, I guess you are hitting again the non-blocking socket issue FreeBSD.
Please check the archives (I think on the dev list) talking about passing
some special flag while building libapr to make the sockets work right.
Unfortunately it didn't end up in the docs and I don't have the info handy.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] make test errors
Posted by William McKee <wi...@knowmad.com>.
Stas,
It's been awhile, but I'm back to working on these tests under FreeBSD
5.3 with mp2. I'm using the current release (2.0.0) with Apache 2.0.54.
The root of many of my problems appears to be how Apache is resolving my
localhost address. Apparently FBSD resolves localhost to my Jail IP.
Apache is expecting the more usual 127.0.0.1. I was able to resolve the
issues reported below by adding the following line to my /etc/hosts file
above all other definitions:
192.168.1.1 localhost
Assuming my jail ip was 192.168.1.1 this works and most tests are now
pasing. Thanks for bearing with me while I came to an understanding
about the behavior of localhost within a jail.
Currently, I'm still having troubles with t/filter/both_str_con_add.t.
Here's the output:
t/filter/both_str_con_add....1..4
# Running under perl version 5.008006 for freebsd
# Current time local: Thu Jun 2 05:03:50 2005
# Current time GMT: Thu Jun 2 09:03:50 2005
# Using Test.pm version 1.25
# Using Apache/Test.pm version 1.25
ok 1
# expected: mod_perl
# received: mod_perl
# Failed test 3 in t/filter/both_str_con_add.t at line 25 fail #2
# Failed test 4 in t/filter/both_str_con_add.t at line 25 fail #3
ok 2
# expected: 2.0
# received:
not ok 3
# expected: rules
# received:
not ok 4
FAILED tests 3-4
As well as t/protocol/echo_block.t with the following output:
t/protocol/echo_block....1..3
# Running under perl version 5.008006 for freebsd
# Current time local: Thu Jun 2 06:31:17 2005
# Current time GMT: Thu Jun 2 10:31:17 2005
# Using Test.pm version 1.25
# Using Apache/Test.pm version 1.25
ok 1
# expected: hello
# received: hello
ok 2
# Failed test 3 in t/protocol/echo_block.t at line 22 fail #2
# expected: world
# received:
not ok 3
FAILED test 3
Failed 1/3 tests, 66.67% okay
In both cases, the first string works but the following ones are
failing. My guess is that the culprit is
my $socket = Apache::TestRequest::vhost_socket
which is used across all three of the failing tests. I'll try to spend
some more time on it later today.
Also, the t/protocol/echo_filter.t test is failing. It runs tests 1 and
2 then keeps running until it fills up the disk space then dumps a
massive core file. I'm just skipping it for now.
William
On Fri, Feb 18, 2005 at 05:32:49PM -0500, Stas Bekman wrote:
> William McKee wrote:
> [...]
> >To recap, these are the results of the mp2 test (RC4) with the following
> >environment setting:
> >
> > export ac_cv_o_nonblock_inherited=yes
> [...]
> > # Failed test 2 in t/api/access2.t at line 15
> > # testing : no credentials passed
> > # expected: 401
> > # received: 403
> > not ok 2
>
> I'm not sure why this happens. It should be:
>
> # testing : no credentials passed
> # expected: 401
> # received: 401
> ok 2
>
> HTTP_FORBIDDEN is not returned by ap_get_basic_auth_pw. Try to dump the
> $rc code in that sub-test in t/response/TestAPI/access2.pm
>
> my($rc, $sent_pw) = $r->get_basic_auth_pw;
> warn "RC: $rc\n";
> return $rc if $rc != Apache::OK;
>
> > ok 3
> > ok 4
> > not ok 5
> > # Failed test 5 in t/api/access2.t at line 24
> > not ok 6
> > # Failed test 6 in t/api/access2.t at line 27
> > FAILED tests 2, 5-6
>
> What the error_log says about those two?
>
> It looks like a fileperms problem again. Try to make sure that the
> ownership of all files under t/ is the same.
>
> find t -type d -exec chmod u+rwx {} \;
> find t -type f -exec chmod u+rw {} \;
> find t -type d -exec chown uid.gid {} \;
> find t -type f -exec chown uid.gid {} \;
>
> where uid.gid is the id you use to run the tests with (e.g. nobody.nobody)
>
>
> --
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by Stas Bekman <st...@stason.org>.
Jie Gao wrote:
> Hi Stas,
>
> The documentation at http://perl.apache.org/docs/2.0/api/APR/OS.html
> has an inconsistency.
>
> In the example, it seems the method "thread_current" should actually be
> "current_thread_id".
Thanks Jie, committed.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] make test errors
Posted by Jie Gao <J....@isu.usyd.edu.au>.
Hi Stas,
The documentation at http://perl.apache.org/docs/2.0/api/APR/OS.html
has an inconsistency.
In the example, it seems the method "thread_current" should actually be
"current_thread_id".
Regard,
Jie
Re: [mp2] make test errors
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
[...]
> To recap, these are the results of the mp2 test (RC4) with the following
> environment setting:
>
> export ac_cv_o_nonblock_inherited=yes
[...]
> # Failed test 2 in t/api/access2.t at line 15
> # testing : no credentials passed
> # expected: 401
> # received: 403
> not ok 2
I'm not sure why this happens. It should be:
# testing : no credentials passed
# expected: 401
# received: 401
ok 2
HTTP_FORBIDDEN is not returned by ap_get_basic_auth_pw. Try to dump the
$rc code in that sub-test in t/response/TestAPI/access2.pm
my($rc, $sent_pw) = $r->get_basic_auth_pw;
warn "RC: $rc\n";
return $rc if $rc != Apache::OK;
> ok 3
> ok 4
> not ok 5
> # Failed test 5 in t/api/access2.t at line 24
> not ok 6
> # Failed test 6 in t/api/access2.t at line 27
> FAILED tests 2, 5-6
What the error_log says about those two?
It looks like a fileperms problem again. Try to make sure that the
ownership of all files under t/ is the same.
find t -type d -exec chmod u+rwx {} \;
find t -type f -exec chmod u+rw {} \;
find t -type d -exec chown uid.gid {} \;
find t -type f -exec chown uid.gid {} \;
where uid.gid is the id you use to run the tests with (e.g. nobody.nobody)
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] make test errors
Posted by William McKee <wi...@knowmad.com>.
On Thu, Feb 17, 2005 at 06:27:15PM -0500, Stas Bekman wrote:
> As for 'Can't open t/conf/perlsection.conf', do
>
> t/TEST -clean
To make a long story short, I had run the make test on the source as
root which caused the t/ directory to have its ownership changed to
nobody. So when I went to run my tests under my normal user account,
A::T was having problems cleaning up the test files. Simply fixing the
ownership did the job.
To recap, these are the results of the mp2 test (RC4) with the following
environment setting:
export ac_cv_o_nonblock_inherited=yes
With the above setting while building and testing mp2, I am still
getting errors. However, they are in different. Here's the results:
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/api/access2.t 6 3 50.00% 2 5-6
t/modperl/setupenv.t 63 6 9.52% 8 22 29 36 50 57
t/preconnection/note.t 1 1 100.00% 1
8 tests skipped.
Failed 3/222 test scripts, 98.65% okay. 10/2201 subtests failed, 99.55%
okay.
When I ran the individual tests that were failing, the failures in
setupenv.t and note.t were all attributable to problem of mod_perl
getting a different ip address than the remote_ip function in httpd (I
have a request to Apache developers about this issue as I could not
figure out where httpd is setting this value).
The access2.t, which didn't fail in my earlier testing, reports the
following:
# Running under perl version 5.008006 for freebsd
# Current time local: Fri Feb 18 12:04:57 2005
# Current time GMT: Fri Feb 18 17:04:57 2005
# Using Test.pm version 1.25
# Using Apache/Test.pm version 1.21
ok 1
# Failed test 2 in t/api/access2.t at line 15
# testing : no credentials passed
# expected: 401
# received: 403
not ok 2
ok 3
ok 4
not ok 5
# Failed test 5 in t/api/access2.t at line 24
not ok 6
# Failed test 6 in t/api/access2.t at line 27
FAILED tests 2, 5-6
Does this provide any further information to help us track down the
testing problems I'm seeing? Should I be using this version of the
binary instead of the one configured without the
ac_cv_o_nonblock_inherited setting?
Thanks!
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Thu, Feb 17, 2005 at 04:53:45PM +0000, Joe Orton wrote:
>
>>Check for the result of the:
>>
>>"checking if O_NONBLOCK setting is inherited from listening sockets"
>>
>>test when you run the configure script.
>
>
> I wasn't sure if you were referring to the mod_perl or Apache configure
> script. When I ran the following command, the setting was no:
Since you build a static Apache+mod_perl, running mod_perl is OK.
As for 'Can't open t/conf/perlsection.conf', do
t/TEST -clean
and check that t/conf/perlsection.conf is no longer there. Then do 'make
test'.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] make test errors
Posted by William McKee <wi...@knowmad.com>.
On Thu, Feb 17, 2005 at 04:53:45PM +0000, Joe Orton wrote:
> Check for the result of the:
>
> "checking if O_NONBLOCK setting is inherited from listening sockets"
>
> test when you run the configure script.
I wasn't sure if you were referring to the mod_perl or Apache configure
script. When I ran the following command, the setting was no:
perl Makefile.PL PREFIX=/usr/local MP_USE_STATIC=1
MP_AP_PREFIX=/usr/local/src/httpd-2.0.53_perl
MP_AP_CONFIGURE="--with-mpm=prefork --prefix=/usr/local/apache2_perl"
The config.log file from that command is temporarily available here[1].
> file and upload it somewhere so we can check it. Then try:
>
> export ac_cv_o_nonblock_inherited=yes
>
> or equivalent in your shell then re-run configure and re-build
> everything and re-run the mod_perl test suites.
Reran the above command followed by make && make test. Here is the
output (relevent error is Can't open t/conf/perlsection.conf; that file
exists and is 644 with nobody.nobody as owner.group):
waiting 120 seconds for server to start: .[Thu Feb 17 14:46:29 2005]
[info] 7 Apache:: modules loaded
[Thu Feb 17 14:46:29 2005] [info] 0 APR:: modules loaded
[Thu Feb 17 14:46:29 2005] [info] base server + 27 vhosts ready to run
tests
.Syntax error on line 51 of
/stubs/usr_local/src/mod_perl-2.0.0-RC4/t/conf/extra.last.conf:
Can't open
/stubs/usr_local/src/mod_perl-2.0.0-RC4/t/conf/perlsection.conf:
Permission denied at
/stubs/usr_local/src/mod_perl-2.0.0-RC4/t/conf/extra.last.conf line
53.\n
.......................................................................................................................
waiting 120 seconds for server to start: not ok
[ error] giving up after 121 secs. If you think that your system
is slow or overloaded try again with a longer timeout value.
by setting the environment variable APACHE_TEST_STARTUP_TIMEOUT
to a high value (e.g. 420) and repeat the last command.
[ error] server failed to start! (t/logs/error_log wasn't created,
start the server in the debug mode)
+--------------------------------------------------------+
| Please file a bug report: http://perl.apache.org/bugs/ |
+--------------------------------------------------------+
*** Error code 1
Stop in /stubs/usr_local/src/mod_perl-2.0.0-RC4.
> > > I presume that httpd+mod_perl were at least configured and built
> > > *outside* the chroot?
> >
> > No, it was built inside the jail. I have no access outside of my jail.
>
> I think this is a bit optimistic. I would use a proper FreeBSD 5.3
> machine somewhere else to build the software, then deploy prebuilt
> binaries on the production machine inside the jail.
Well, I'm going to be an optimist for now. If I run into production
problems (beyond these tests failing), I'll certainly go with your
recommendation. Unfortunately, I do not have access to a FreeBSD 5.3
server to run the tests outside of a jail to see if all are passing.
I'll try to setup one in the coming weeks.
Thanks,
William
[1] http://test.knowmad.com/~william/config.log
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Feb 17, 2005 at 09:18:31AM -0500, William McKee wrote:
> On Thu, Feb 17, 2005 at 10:39:46AM +0000, Joe Orton wrote:
> > That was all the non-blocking-vs-blocking stuff. First I'd ask whether
> > or not this fails in a non-chroot environment. A chroot will screw up
> > all kinds of stuff (e.g. the resolver libraries) unless you set it up
> > properly.
>
> Any pointers to how my host should properly configure the chroot would
> be appreciated. Considering that only 17 of 2106 tests failed, it must
> be pretty good. I've been running Apache 1.3.x under a jail for a couple
> years now without any problems (though I couldn't tell you if the tests
> passed; I doubt that they were being run by the Apachetoolbox utility
> that I was using to build my server). Is building and running Apache
> within a chroot environment going to be a problem under Apache2?
The configure script in 2.0 (actually, the APR library) does several
"dynamic" system check; the test in question which could make these
mod_perl tests needs to bind to a port on 127.0.0.1 and connect to it.
It sounds like you may have issues with that in your jail.
Check for the result of the:
"checking if O_NONBLOCK setting is inherited from listening sockets"
test when you run the configure script. It should be "yes" on FreeBSD.
If it's "no", then please preserve capture the srclib/apr/config.log
file and upload it somewhere so we can check it. Then try:
export ac_cv_o_nonblock_inherited=yes
or equivalent in your shell then re-run configure and re-build
everything and re-run the mod_perl test suites.
> > I presume that httpd+mod_perl were at least configured and built
> > *outside* the chroot?
>
> No, it was built inside the jail. I have no access outside of my jail.
I think this is a bit optimistic. I would use a proper FreeBSD 5.3
machine somewhere else to build the software, then deploy prebuilt
binaries on the production machine inside the jail.
joe
Re: [mp2] make test errors
Posted by William McKee <wi...@knowmad.com>.
On Thu, Feb 17, 2005 at 10:39:46AM +0000, Joe Orton wrote:
> That was all the non-blocking-vs-blocking stuff. First I'd ask whether
> or not this fails in a non-chroot environment. A chroot will screw up
> all kinds of stuff (e.g. the resolver libraries) unless you set it up
> properly.
Any pointers to how my host should properly configure the chroot would
be appreciated. Considering that only 17 of 2106 tests failed, it must
be pretty good. I've been running Apache 1.3.x under a jail for a couple
years now without any problems (though I couldn't tell you if the tests
passed; I doubt that they were being run by the Apachetoolbox utility
that I was using to build my server). Is building and running Apache
within a chroot environment going to be a problem under Apache2?
> I presume that httpd+mod_perl were at least configured and built
> *outside* the chroot?
No, it was built inside the jail. I have no access outside of my jail.
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Feb 16, 2005 at 07:12:11PM -0500, Stas Bekman wrote:
> Joe, do you have an idea why this doesn't work on FreeBSD 5.3 (in jail
> environment). I remember last time you've fixed something about some BSD
> flavor in APR socket lib. Thanks.
That was all the non-blocking-vs-blocking stuff. First I'd ask whether
or not this fails in a non-chroot environment. A chroot will screw up
all kinds of stuff (e.g. the resolver libraries) unless you set it up
properly.
I presume that httpd+mod_perl were at least configured and built
*outside* the chroot?
joe
Re: [mp2] make test errors
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Wed, Feb 16, 2005 at 04:08:45PM -0500, Stas Bekman wrote:
>
>>see if this patch helps:
>
>
> Uh-oh, from bad to worse. Now we're failing two tests (instead of only
> the last one):
please look at your original report, William, it was failing the same 2
sub-tests.
> # Running under perl version 5.008006 for freebsd
> # Current time local: Wed Feb 16 17:23:47 2005
> # Current time GMT: Wed Feb 16 22:23:47 2005
> # Using Test.pm version 1.25
> # Using Apache/Test.pm version 1.21
> ok 1
> # expected: hello
> # received:
> not ok 2
> # Failed test 2 in t/protocol/echo_block.t at line 22
> # expected: world
> # received:
> not ok 3
> # Failed test 3 in t/protocol/echo_block.t at line 22 fail #2
> FAILED tests 2-3
That means that my patch made no difference.
That most likely means that for your particular FreeBSD version may not
work properly under APR Sockets API (this is because there is hardly any
perl in this test, it just directly sends and reads from APR libs.
Joe, do you have an idea why this doesn't work on FreeBSD 5.3 (in jail
environment). I remember last time you've fixed something about some BSD
flavor in APR socket lib. Thanks.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] make test errors
Posted by William McKee <wi...@knowmad.com>.
On Wed, Feb 16, 2005 at 04:08:45PM -0500, Stas Bekman wrote:
> see if this patch helps:
Uh-oh, from bad to worse. Now we're failing two tests (instead of only
the last one):
# Running under perl version 5.008006 for freebsd
# Current time local: Wed Feb 16 17:23:47 2005
# Current time GMT: Wed Feb 16 22:23:47 2005
# Using Test.pm version 1.25
# Using Apache/Test.pm version 1.21
ok 1
# expected: hello
# received:
not ok 2
# Failed test 2 in t/protocol/echo_block.t at line 22
# expected: world
# received:
not ok 3
# Failed test 3 in t/protocol/echo_block.t at line 22 fail #2
FAILED tests 2-3
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [mp2] make test errors
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> t/TEST t/protocol/echo_block.t -v
> # Failed test 2 in t/protocol/echo_block.t at line 22
> # expected: hello
> # received:
> # Failed test 3 in t/protocol/echo_block.t at line 22 fail #2
> not ok 2
> # expected: world
> # received:
> not ok 3
see if this patch helps:
Index: t/protocol/TestProtocol/echo_block.pm
===================================================================
--- t/protocol/TestProtocol/echo_block.pm (revision 153514)
+++ t/protocol/TestProtocol/echo_block.pm (working copy)
@@ -33,6 +33,8 @@
or die "failed to set blocking mode";
}
+ $socket->opt_set(APR::SO_NONBLOCK, 0);
+
while ($socket->recv(my $buffer, BUFF_LEN)) {
die "recv() has returned untainted data:"
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com