Re: Syntax issue in Apache/TestConfig.pm TestUtil.pm
Stas Bekman wrote:
William A. Rowe, Jr. wrote:
What I'm trying (failing?) to point out is that on BSD and other platforms, if
they have a bug, they can munge *PERL*, not ApacheTest, not each and every perl
script which creates perl files, with an effective value of $Config{startperl}.
What you are missing Bill, is that there is no bug in perl or perl
installation. It's a shell limitation documented here:
# see: http://en.wikipedia.org/wiki/Shebang
# http://homepages.cwi.nl/~aeb/std/shebang/
Right - I'm not disagreeing with the problem, I'm stating $Config{startperl}
when used by every program against your perl is either right, or it's wrong.
When Wrong, it's wrong for every program. Ergo; bug is MakeMaker's to fix,
not ours, and...
I don't have a BSD box in front of me; but if ApacheTest used
$Config{startperl}
rather than all of this other mechanics, then it would be up to BSD folks
to help the entire Perl community by fixing this ONCE with MakeMaker,
and be
done with it. By messing with constructing what MakeMaker's done
since 5.0005
we are putting more work on ourselves, no?
I think there are two somewhat unrelated issues that are being discussed
here -
1) using $Config{startperl} vs $Config{perlpath},
2) the issue with shebang code generation
...startperl is declared with a shebang, perl -e "print $Config{startperl};"
in your own environment :) So the two are -one-in-the-same-
I think Geoff is thinking that Bill is suggesting to tackle #1, whereas
Bill is only talking about #2.
I'm stating use startperl; both of you want the shebang bug (not ours) fixed,
so as I...
Bill, mind to post a patch of what you think should work?
Yes, revert this patch, and replace these lines with = $Config{startperl}.
When I have a clean patch against head I'll post it. I'll also look at the
state of MakeMaker to see if this issue -was- addressed there.
...propose to throw away the gross hack, it's only fair if I show you also the
perl patch to create a *valid* MakeMaker $Config{startperl} result for those
on these shebang-constrained platforms. Let's fix the bug, not a symptom.
Bill
Re: Syntax issue in Apache/TestConfig.pm TestUtil.pm
Stas Bekman wrote:
William A. Rowe, Jr. wrote:
I don't think the reporter understood the concept of
#!/usr/bin/perl
eval 'exec $Config{perlpath} -S \$0 \${1+"\$@"}'
if \$running_under_some_shell;
which is a noop under perl, and invokes a shell exec command under shell. Perl
never invokes the exec ($running_under_some_shell is undef and therefore noop).
In this case, /usr/bin/perl is running their script, even if perlpath pointed
to /usr/local/perl5.8/bin/perl - and that's the last possible scenario we want.
If the reporter wanted this hack to work, #!/bin/sh was the proper line one.
You mean:
sub make_shebang {
# if perlpath is longer than 62 chars, some shells on certain
# platforms won't be able to run the shebang line, so when seeing
# a long perlpath use the eval workaround.
# see: http://en.wikipedia.org/wiki/Shebang
# http://homepages.cwi.nl/~aeb/std/shebang/
my $shebang = length $Config{perlpath} < 62
? "#!$Config{perlpath}\n"
: <
Good point ;-)
In any case, this sort of hack should be left to the value of $Config{startperl}
where it belongs, not a dozen workarounds in a dozen different projects.
I'm not following you, how $Config{startperl} solves the problem of the
long path, if just as you say it makes the script run under the wrong perl?
$Config{sh}, $Config{perlpath}, and $Config{perl} comes from -this- perl, right?
#/usr/bin/perl is a hardcode to an arbitrary perl installed at that location.
What I'm trying (failing?) to point out is that on BSD and other platforms, if
they have a bug, they can munge *PERL*, not ApacheTest, not each and every perl
script which creates perl files, with an effective value of $Config{startperl}.
I don't have a BSD box in front of me; but if ApacheTest used $Config{startperl}
rather than all of this other mechanics, then it would be up to BSD folks
to help the entire Perl community by fixing this ONCE with MakeMaker, and be
done with it. By messing with constructing what MakeMaker's done since 5.0005
we are putting more work on ourselves, no?
Bill, mind to post a patch of what you think should work?
Yes, revert this patch, and replace these lines with = $Config{startperl}.
When I have a clean patch against head I'll post it. I'll also look at the
state of MakeMaker to see if this issue -was- addressed there.
Bill
Re: Syntax issue in Apache/TestConfig.pm TestUtil.pm
I don't think the reporter understood the concept of
#!/usr/bin/perl
eval 'exec $Config{perlpath} -S \$0 \${1+"\$@"}'
if \$running_under_some_shell;
which is a noop under perl, and invokes a shell exec command under shell. Perl
never invokes the exec ($running_under_some_shell is undef and therefore noop).
In this case, /usr/bin/perl is running their script, even if perlpath pointed
to /usr/local/perl5.8/bin/perl - and that's the last possible scenario we want.
If the reporter wanted this hack to work, #!/bin/sh was the proper line one.
In any case, this sort of hack should be left to the value of $Config{startperl}
where it belongs, not a dozen workarounds in a dozen different projects.
Bill
Stas Bekman wrote:
Geoffrey Young wrote:
William A. Rowe, Jr. wrote:
Both lib/Apache/TestConfig.pm and lib/Apache/TestUtil.pm twist off their
own shebang lines from $Config{perlpath}, which is wrong.
I think part of this stems from this
http://www.gossamer-threads.com/lists/modperl/dev/86017
Mike's patch used the original $Config{perlpath}, so no change there.
They should simply pull $Config{startperl} which defines the
shebang/command
on a platform basis. See startperl= assignment from Config.pm.
You mean using $Config{startperl} instead of the hardcoded
#!/usr/bin/perl when the path is too long? I think that value makes no
difference. At least not according to these resources:
# see: http://en.wikipedia.org/wiki/Shebang
# http://homepages.cwi.nl/~aeb/std/shebang/
If you have better ideas that would be wonderful :)
Re: Syntax issue in Apache/TestConfig.pm TestUtil.pm
Geoffrey Young wrote:
ack and discuss :) let's hold off on making any changes until we are really
sure we won't be breaking old platforms. speaking of breakage, which
platform is giving your grief with this? randy reported success with win32
so it's something else?
Something else. My perl/bin/perl script fixes up the libpath info to openssl,
the current install location of perl, etc. So without the $Config{startperl}
location to invoke perl-as-shell (I had a horrid time with shebang syntax on
non-bash older /bin/sh shells using perlscript) - I'll continue to have
difficulty testing parallel installs.
Your point to perl versions is good; the make_shebang is a hack around something
that can be trivially hacked into the base perl instead (in Config.pm). Since
perl 'figures this out', my preference is for perl to get it right (or wrong,
and therefore fixed once per platform/deployment strategy.)
So the question; how far back? I just went to a box with an honest to goodness
5.005.03 sun4-solaris distribution of perl and lo and behold,
startperl='#!/usr/bin/perl' is there.
Which brings up another aspect of tweaking startperl, that is, when meaning to
test several parallel flavors of perl. But coming back on point, yes I quite
believe this will work across the board.
Bill
Syntax issue in Apache/TestConfig.pm TestUtil.pm
Both lib/Apache/TestConfig.pm and lib/Apache/TestUtil.pm twist off their
own shebang lines from $Config{perlpath}, which is wrong.
They should simply pull $Config{startperl} which defines the shebang/command
on a platform basis. See startperl= assignment from Config.pm.
Please ack / discuss / commit?
Thanks,
Bill
Re: Reading post data from separate handlers
Blayne Bayer wrote: I have a problem that hopefully somebody has encountered or can point me in the right direction. We use the latest embperl 1.xxx release on linux. I have created a handler to do authentication before the embperl handler is run. This new handler needs to read data from the post each request. However once read is called on the Apache object you cannot call it again. This in turns cripples embperl because it no longer has the post data. Is there any way to be able to read the post data from multiple handlers? If you are part of the filter stack, you can 'sniff' - read ahead and set aside - the data coming in from the client. Other filters installed after your filter will repeatedly call, and you return the set-aside data. You can look at the apreq2 library with httpd-2 to assist you with this.
Re: identifying mod_perl process at runtime
Daniel McBrearty wrote: If I have a library which is used for both mod_perl and standard cgi processes, and I want to know at runtime which, how can I do that? does ARGV[0] tell you? I'd expect it to be 'httpd' for apache/modperl.
Re: restart_count() on Win32
Foo Ji-Haw wrote: Hello William, Thanks for the insight into the inner workings of mp2 on Win32. I'd like to read up more on the parent-child setup, and digging through perl.apache.org (mostly in http://perl.apache.org/docs/2.0/) I don't seem to be able to get any information on mp2 on Win32. Can you share your source of information on this issue? Thanks. Sure, the httpd source code, server/mpm/win32/*.c files - well that and I've committed and fixed a rather large chunk of code to that tree. As far as modperl, and how win32 mpm impacts modper, the modperl team actually is sharper than I am. Bill
Re: restart_count() on Win32
Foo Ji-Haw wrote: I am trying my luck again on this issue, which I never quite understood/ resolved. The log file shows this when Apache starts: 1 (parent/healthcheck process) 2 (parent/healthcheck process) 1 (child/real server process) 2 (child/real server process) In 1.3, the child 'owned' the logs and overwrote everthing. 2.0 uses locking to allow the parent's log entries to be preserved. The win32 'parent' never serves a request. It's resources are also not really inherited by the child, so each child must 'do it's own thing' with respect to fully initializing the server. And the log file shows this when Apache restarts: 3 (parent/healthcheck process) 1 (child/real server process) 2 (child/real server process) The parent signals the 'old child' to begin to shut down (and quit listening for new connections) while it spawns up a new full blown child process, with the same child behavior as you noted on first-start.
Re: nmake test problem on Windows
Goehring, Chuck wrote: modperlers, Firstly apxs does not apply on Windows, right? see http://www.apache.org/dist/perl/win32-bin/apxs_win32.tar.gz
Re: [mp2] make test fails to start httpd on AIX 5.2, IHS 2.
Question, any hope you could use something more recent than a 2 year old distribution of httpd, and let us know if the modern version reproduces the problem? http://httpd.apache.org/dev/dist/ happens to contain what we hope will become an official 2.0.55 release, with some new AIX build fixes, give it a whirl if you can find some time to test, and see if this remains a problem. Thanks! Bill [EMAIL PROTECTED] wrote: 1. Problem Description: make test fails to start httpd on AIX 5.2 Maintenance Level 2 with IBM HTTP Server 2.0.47.1. The HTTP startup process times out.
Re: Apache::Test not finding global config file
On Wed, Aug 31, 2005 at 06:19:10PM -0400, Geoffrey Young wrote: > if you can do me the favor of trying a few different configuration scenarios > (including 1.3, non-apxs, /usr/local/apache, etc) and making sure nothing > breaks, that would be great. the box where my matrix used to live had a > hard drive failure, so I'm slowly rebuilding it as I find the time. Besides testing under Apache2, I've tested with /usr/local/apache (this was an Apache1 server and was non-apxs). That's all I have at my disposal. > I've been thinking a bit about this and I think the attached is a better > patch. basically, I think A-T goes through a lot of effort to separate the > current filesystem configuration from the hard-coded stuff in httpd in an > effort to make it easy to roll up an httpd install, move it someplace else, > and still have A-T be able to create a worthy configuration. using > HTTPD_ROOT like that kinda breaks all of that for people expecting the > current behavior, so I'd rather use it as a last-ditch effort than off the > bat. > > can you give it a whirl? I removed your original patch and added this one then tested it under the two systems above. Looks good. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Apache::Test not finding global config file
On Wed, Aug 31, 2005 at 11:54:57AM -0400, Geoffrey Young wrote:
> $self->{httpd_basedir}, which looks to be calculated based on the location
> of the httpd binary. but it looks like it ought to be using HTTPD_ROOT
> instead. at least if it's defined.
>
> try this (completely untested)
Perfect! That worked just fine. How can we get it added to A::T?
Thanks,
William
PS: Sorry I missed you at YAPC this year. Perrin will tell you that I
tried my best to track you down. Next time...
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Apache::Test not finding global config file
On Thu, Aug 25, 2005 at 06:56:57PM -0400, Philip M. Gollucci wrote: > >From the trace below, you can see that A::T thinks the config file is > >'/usr/conf/httpd2.conf': > > [ debug] isolated httpd_defines HTTPD_ROOT = /etc/httpd/2.0 > > [ debug] isolated httpd_defines SERVER_CONFIG_FILE = conf/httpd2.conf > I guess that should be > /etc/httpd/2.0/conf/httpd2.conf > > then right ? > What is the actual path you want it to find ? I want it to find /etc/httpd/2.0/conf/httpd2.conf but it is finding: [ debug] isolated httpd_defines HTTPD_ROOT = /etc/httpd/2.0 [ debug] isolated httpd_defines SERVER_CONFIG_FILE = conf/httpd2.conf [ debug] inheriting config file: /usr/conf/httpd2.conf I'd love to figure out where it's grabbing '/usr' to append to the SERVER_CONFIG_FILE that it finds. Any ideas? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Apache::Test not finding global config file
On Thu, Aug 25, 2005 at 06:59:56PM -0400, Philip M. Gollucci wrote: > To answer your original quesiton, > you want: > in A-T source, Thanks for the reference. Some further investigating showed that calling t/TEST -clean is when I lose the -httpd_config setting which explains why `./Build test` is finding the wrong config file. I'm putting some debug statements into lib/Apache/TestConfigParse.pm::inherit_config() to see if I can track down where A::T is getting that bad location for the config file. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Apache::Test not finding global config file
I was able to get a trace from a failing case after using './Build && t/TEST'. Calling just 't/TEST' finds the config file correctly. So it appears that calling ./Build is where the trouble occurs for me (though I've never seen this behavior before). From the trace below, you can see that A::T thinks the config file is '/usr/conf/httpd2.conf': [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl5.8.5 /home/www/www.calendarkidz.com/CalendarKidz/t/TEST 't/apache/calendarkidz/process_upload.t' -v -trace=debug [ debug] loading custom config data from: '/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Apache/TestConfigData.pm' [ debug] configuring httpd [ debug] Using httpd: /usr/sbin/httpd2 [ debug] isolated httpd_info VERSION = Apache-AdvancedExtranetServer/2.0.50 [ debug] isolated httpd_info BUILT = Jul 25 2005 14:04:55 [ debug] isolated httpd_info MODULE_MAGIC_NUMBER = 20020903:8 [ debug] isolated httpd_defines APACHE_MPM_DIR = server/mpm/prefork [ debug] isolated httpd_defines APR_HAS_SENDFILE = 1 [ debug] isolated httpd_defines APR_HAS_MMAP = 1 [ debug] isolated httpd_defines APR_HAVE_IPV6 (IPv4-mapped addresses enabled) = 1 [ debug] isolated httpd_defines APR_USE_FCNTL_SERIALIZE = 1 [ debug] isolated httpd_defines APR_USE_PTHREAD_SERIALIZE = 1 [ debug] isolated httpd_defines SINGLE_LISTEN_UNSERIALIZED_ACCEPT = 1 [ debug] isolated httpd_defines APR_HAS_OTHER_CHILD = 1 [ debug] isolated httpd_defines AP_HAVE_RELIABLE_PIPED_LOGS = 1 [ debug] isolated httpd_defines HTTPD_ROOT = /etc/httpd/2.0 [ debug] isolated httpd_defines SUEXEC_BIN = /usr/sbin/apache2-suexec [ debug] isolated httpd_defines DEFAULT_PIDLOG = /var/run/httpd.pid [ debug] isolated httpd_defines DEFAULT_SCOREBOARD = logs/apache_runtime_status [ debug] isolated httpd_defines DEFAULT_LOCKFILE = /var/run/accept.lock [ debug] isolated httpd_defines DEFAULT_ERRORLOG = logs/error_log [ debug] isolated httpd_defines AP_TYPES_CONFIG_FILE = conf/mime.types [ debug] isolated httpd_defines SERVER_CONFIG_FILE = conf/httpd2.conf [ debug] inheriting config file: /usr/conf/httpd2.conf [ debug] Matched Apache revision Apache-AdvancedExtranetServer/2.0.50 2 Thanks for any ideas, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Apache::Test not finding global config file
On Thu, Aug 25, 2005 at 04:04:13PM -0400, Philip M. Gollucci wrote: > >I've looked through the Apache::TestConfig.pm file to try to find where > >the problem may be but cannot figure out where that module obtains the > >configuration file or how to dump out the configuration file it is > >automatically finding. > ~/.apache-test/TestConfigData.pm, then @INC/lib/Apache/TestConfigData.pm Hi Phillip, Thanks for the response. I've looked through the TestConfigData.pm file but no httpd_conf is defined. I do not have a ~/.apache-test directory. I was actually trying to get some feedback about what sub in the TestConfig.pm module is responsible for tracking down the config file. > ./TEST -trace=debug (anyone of the apache error log levels are valid) Thanks for the pointer! Actually the output shows where that config file is being found. In fact, I found that everything works fine when I run t/TEST. However, when running ./Build test, the LoadModule directives are not being found. Do you know if there a way to pass the trace setting thru ./Build so I can figure out why it's having troubles finding my config file? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Apache::Test not finding global config file
Hey folks, I'm having a bit of a struggle with Apache::Test on a Mandriva Linux 10.1 server. I'm using A::T v1.26 with Apache2.0.50 + mod_perl2.0.1. For some reason, the configuration process is not finding the global config file which causes my tests which are working under a Debian workstation to fail. I've tried tracking down the problem and found that I could pass in -httpd_conf to the t/TEST command to get the config file recognized. This trick doesn't work if I try './Build test' or 'make test'. I've looked through the Apache::TestConfig.pm file to try to find where the problem may be but cannot figure out where that module obtains the configuration file or how to dump out the configuration file it is automatically finding. Looking at the output of httpd -V, I'd think there'd be no problem: Server version: Apache-AdvancedExtranetServer/2.0.50 Server built: Jul 25 2005 14:04:55 Server's Module Magic Number: 20020903:8 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 enabled) -D APR_USE_FCNTL_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/etc/httpd/2.0" -D SUEXEC_BIN="/usr/sbin/apache2-suexec" -D DEFAULT_PIDLOG="/var/run/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="/var/run/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd2.conf" Also, I noticed the use of a debug function in several places in the TestConfig.pm but couldn't figure out where this function is defined so that I can get it to output to STDERR. Does anyone know what module defines that function and what flags I need to pass in to get it to output its data? Using '-v' didn't seem to work. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
'make test' fails for mp2 under HP-UX
Sorry, the subject on my first post probably obscured the fact that this was a new problem post. -8<-- Start Bug Report 8<-- 1. Problem Description: make test fails on t/modperl/request_rec_tie_api.t . # Running under perl version 5.006002 for hpux # Current time local: Mon Aug 22 16:22:54 2005 # Current time GMT: Mon Aug 22 20:22:54 2005 # Using Test.pm version 1.24 # Using Apache/Test.pm version 1.25 FAILED before any test output arrived Failed Test Stat Wstat Total Fail Failed List of Failed --- t/modperl/request_rec_tie_api.t ?? ?? % ?? Failed 1/1 test scripts, 0.00% okay. 3/3 subtests failed, 0.00% okay. [warning] server localhost:8529 shutdown [ error] error running tests (please examine t/logs/error_log) [ error] oh crap, server dumped core I've tinkered around with request_rec_tie_api.pm and the line it dies on looks innocent enough: my $fileno = fileno STDOUT; fileno on STDERR or STDIN return the expected results. The same code under plain perl works fine. If I change the line to: my $fileno = 1; just to get past the problem everything works fine. 2. Used Components and their Configuration: *** mod_perl version 2.01 *** using /opt/local/wrfopt/build/mod_perl-2.0.1/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB => aprext MP_APXS=> /usr/opt/httpd-2.0.54/bin/apxs MP_CCOPTS => -I/usr/opt/mod_perl-2.0.1/include -I/opt/default/include +z +DA1.1 MP_COMPAT_1X => 1 MP_DEBUG => 1 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_TRACE => 1 MP_USE_DSO => 1 *** /usr/opt/httpd-2.0.54/bin/httpd -V Server version: Apache/2.0.54 Server built: Aug 22 2005 15:11:53 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 enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/usr/opt/httpd-2.0.54" -D SUEXEC_BIN="/usr/opt/httpd-2.0.54/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/opt/httpd-2.0.54/lib -laprutil-0 -lc -ldb-4.3 -lexpat -liconv -L/usr/opt/httpd-2.0.54/lib -lapr-0 -lm -lnsl -lpthread -ldld *** /usr/opt/perl-5.6.2/bin/perl -V Summary of my perl5 (revision 5.0 version 6 subversion 2) configuration: Platform: osname=hpux, osvers=11.11, archname=PA-RISC1.1 uname='hp-ux cars-l b.11.11 u 9000800 134921527 unlimited-user license ' config_args='-O -Ubincompat5005 -Uuselargefiles -Uuseithreads -Darchname=PA-RISC1.1 -Accflags=+z -Accflags=-DPERL_POLLUTE -Accflags=+DA1.1 -Dcccdlflags=+z -Dprefix=/usr/opt/perl-5.6.2 -Doptimize=-g -Dloclibpth=/usr/opt/perl-5.6.2/lib /lib /usr/lib /usr/ccs/lib /usr/opt/libiconv-1.9.1/lib /usr/opt/readline-5.0/lib /usr/opt/openssl-0.9.8/lib /usr/opt/ncurses-5.4/lib /usr/opt/gettext-0.12.1/lib /usr/opt/jpeg.v6b/lib /opt/informix/lib /usr/opt/zlib-1.2.3/lib /usr/opt/db-4.3.27/lib /usr/opt/expat-1.95.8/lib /usr/opt/gzip-1.2.4/lib /usr/opt/freetds-0.63RC10/lib /usr/opt/libpng-1.2.8/lib /usr/opt/bzip2-1.0.2/lib /usr/opt/gdbm-1.8.3/lib /usr/opt/freetype-2.1.7/lib /usr/opt/gd-2.0.15/lib /usr/opt/tiff-3.7.1/lib -Dlocincpth=/usr/opt/perl-5.6.2/include /include /usr/include /usr/ccs/include /usr/opt/libiconv-1.9.1/include /usr/opt/readline-5.0/include /usr/opt/openssl-0.9.8/include /usr/opt/ncurses-5.4/include /usr/opt/gettext-0.12.1/include /usr/opt/jpeg.v6b/include /opt/informix/incl /usr/opt/zlib-1.2.3/include /usr/opt/db-4.3.27/include /usr/opt/expat-1.95.8/include /usr/opt/gzip-1.2.4/include /usr/opt/freetds-0.63RC10/include /usr/opt/libpng-1.2.8/include /usr/opt/bzip2-1.0.2/include /usr/opt/gdbm-1.8.3/include /usr/opt/freetype-2.1.7/include /usr/opt/gd-2.0.15/include /usr/opt/tiff-3.7.1/include -Dcc=/opt/ansic/bin/cc -Dlibs= -lnm -lndbm -lgdbm -ldb -lmalloc -ldld -lm -lcrypt -lsec -lpthread -lc -lcl -lCsup -e -s -d' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='/opt/ansic/bin/cc', ccflags ='-Ae -D_HPUX_SOURCE -Wl,+vnocompatwarnings +z -DPERL_POLLUTE +DA1.1 -DDEBUGGING -I/usr/opt/libiconv-1.9.1/include -I/usr/opt/readline-5.0/include -I/usr/opt/openssl-0.9.8/include -I/usr/opt/ncurses-5.4/include -I/usr/opt/gettext-0.12.1/include -I/usr/opt/jpeg.v6b/include -I/opt/informix/incl -I/usr/o
Re: Fw: [mp2] 'make test' fails
-8<-- Start Bug Report 8<-- 1. Problem Description: make test fails on t/modperl/request_rec_tie_api.t . # Running under perl version 5.006002 for hpux # Current time local: Mon Aug 22 16:22:54 2005 # Current time GMT: Mon Aug 22 20:22:54 2005 # Using Test.pm version 1.24 # Using Apache/Test.pm version 1.25 FAILED before any test output arrived Failed Test Stat Wstat Total Fail Failed List of Failed --- t/modperl/request_rec_tie_api.t ?? ?? % ?? Failed 1/1 test scripts, 0.00% okay. 3/3 subtests failed, 0.00% okay. [warning] server localhost:8529 shutdown [ error] error running tests (please examine t/logs/error_log) [ error] oh crap, server dumped core I've tinkered around with request_rec_tie_api.pm and the line it dies on looks innocent enough: my $fileno = fileno STDOUT; fileno on STDERR or STDIN return the expected results. The same code under plain perl works fine. If I change the line to: my $fileno = 1; just to get past the problem everything works fine. 2. Used Components and their Configuration: *** mod_perl version 2.01 *** using /opt/local/wrfopt/build/mod_perl-2.0.1/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB => aprext MP_APXS=> /usr/opt/httpd-2.0.54/bin/apxs MP_CCOPTS => -I/usr/opt/mod_perl-2.0.1/include -I/opt/default/include +z +DA1.1 MP_COMPAT_1X => 1 MP_DEBUG => 1 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_TRACE => 1 MP_USE_DSO => 1 *** /usr/opt/httpd-2.0.54/bin/httpd -V Server version: Apache/2.0.54 Server built: Aug 22 2005 15:11:53 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 enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/usr/opt/httpd-2.0.54" -D SUEXEC_BIN="/usr/opt/httpd-2.0.54/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/opt/httpd-2.0.54/lib -laprutil-0 -lc -ldb-4.3 -lexpat -liconv -L/usr/opt/httpd-2.0.54/lib -lapr-0 -lm -lnsl -lpthread -ldld *** /usr/opt/perl-5.6.2/bin/perl -V Summary of my perl5 (revision 5.0 version 6 subversion 2) configuration: Platform: osname=hpux, osvers=11.11, archname=PA-RISC1.1 uname='hp-ux cars-l b.11.11 u 9000800 134921527 unlimited-user license ' config_args='-O -Ubincompat5005 -Uuselargefiles -Uuseithreads -Darchname=PA-RISC1.1 -Accflags=+z -Accflags=-DPERL_POLLUTE -Accflags=+DA1.1 -Dcccdlflags=+z -Dprefix=/usr/opt/perl-5.6.2 -Doptimize=-g -Dloclibpth=/usr/opt/perl-5.6.2/lib /lib /usr/lib /usr/ccs/lib /usr/opt/libiconv-1.9.1/lib /usr/opt/readline-5.0/lib /usr/opt/openssl-0.9.8/lib /usr/opt/ncurses-5.4/lib /usr/opt/gettext-0.12.1/lib /usr/opt/jpeg.v6b/lib /opt/informix/lib /usr/opt/zlib-1.2.3/lib /usr/opt/db-4.3.27/lib /usr/opt/expat-1.95.8/lib /usr/opt/gzip-1.2.4/lib /usr/opt/freetds-0.63RC10/lib /usr/opt/libpng-1.2.8/lib /usr/opt/bzip2-1.0.2/lib /usr/opt/gdbm-1.8.3/lib /usr/opt/freetype-2.1.7/lib /usr/opt/gd-2.0.15/lib /usr/opt/tiff-3.7.1/lib -Dlocincpth=/usr/opt/perl-5.6.2/include /include /usr/include /usr/ccs/include /usr/opt/libiconv-1.9.1/include /usr/opt/readline-5.0/include /usr/opt/openssl-0.9.8/include /usr/opt/ncurses-5.4/include /usr/opt/gettext-0.12.1/include /usr/opt/jpeg.v6b/include /opt/informix/incl /usr/opt/zlib-1.2.3/include /usr/opt/db-4.3.27/include /usr/opt/expat-1.95.8/include /usr/opt/gzip-1.2.4/include /usr/opt/freetds-0.63RC10/include /usr/opt/libpng-1.2.8/include /usr/opt/bzip2-1.0.2/include /usr/opt/gdbm-1.8.3/include /usr/opt/freetype-2.1.7/include /usr/opt/gd-2.0.15/include /usr/opt/tiff-3.7.1/include -Dcc=/opt/ansic/bin/cc -Dlibs= -lnm -lndbm -lgdbm -ldb -lmalloc -ldld -lm -lcrypt -lsec -lpthread -lc -lcl -lCsup -e -s -d' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='/opt/ansic/bin/cc', ccflags ='-Ae -D_HPUX_SOURCE -Wl,+vnocompatwarnings +z -DPERL_POLLUTE +DA1.1 -DDEBUGGING -I/usr/opt/libiconv-1.9.1/include -I/usr/opt/readline-5.0/include -I/usr/opt/openssl-0.9.8/include -I/usr/opt/ncurses-5.4/include -I/usr/opt/gettext-0.12.1/include -I/usr/opt/jpeg.v6b/include -I/opt/informix/incl -I/usr/opt/zlib-1.2.3/include -I/usr/opt/db-4.3.27/include -I/usr/opt/expat-1.95.8/include -I/usr/opt/free
Re: [mp2] make test errors
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: [Patch WIN32 apxs]
Randy, thanks for all you efforts on this! Question before folks trip, was your 0.3 specific to httpd.exe and the apr-1 layout, or did you finish making this generic to both Apache 2.0 and 2.1-dev+? A warning on the website might be in order, if 0.3 applies right now only to httpd-2.1 Bill Randy Kobes wrote: On Fri, 22 Jul 2005, William A. Rowe, Jr. wrote: For users of Randy's apxs win32 (v 0.2) here's my gross hack to get it working again for 2.1-dev, 2.2. The binary has changed from apache.exe to httpd.exe, causing some pain. However, it's specific, I started generic but ran out of time (libapr-1.dll for example.) Sorry for the crosspost, expect a few on each list to be most interested in this. Would like to see this in httpd 2.2 final. It looks like a wee bit of overkill, and apr / apr-util / httpd really should each deposit their own droppings in bin/, build/. Just no time to refactor this week (hmmm... vacation time ahead ;-) Bill Thanks, Bill! I've incorporated these changes in a new version, apxs_win32-0.3.tar.gz, at http://www.apache.org/dyn/closer.cgi/perl/win32-bin/ Please let me know of any problems.
[Patch WIN32 apxs]
For users of Randy's apxs win32 (v 0.2) here's my gross hack to get
it working again for 2.1-dev, 2.2. The binary has changed from
apache.exe to httpd.exe, causing some pain. However, it's specific,
I started generic but ran out of time (libapr-1.dll for example.)
Sorry for the crosspost, expect a few on each list to be most
interested in this.
Would like to see this in httpd 2.2 final. It looks like a wee bit
of overkill, and apr / apr-util / httpd really should each deposit
their own droppings in bin/, build/. Just no time to refactor this
week (hmmm... vacation time ahead ;-)
Bill
diff -u3 apxs/Configure.pl apxs-win32/Configure.pl
--- apxs/Configure.pl Tue Mar 16 17:42:30 2004
+++ apxs-win32/Configure.pl Fri Jul 22 13:14:04 2005
@@ -13,8 +13,9 @@
die 'This script is intended for Win32' unless $^O =~ /Win32/i;
}
-my ($apache, $help);
+my ($apache, $progname, $help);
GetOptions( 'with-apache2=s' => \$apache,
+ 'with-apache-prog=s' => \$progname,
'help' => \$help,
) or usage($0);
usage($0) if $help;
@@ -22,7 +23,10 @@
my @path_ext;
path_ext();
$apache ||= search();
+$progname ||= "Apache.exe";
+push @ARGV, "--with-apache-prog=$progname";
+
for my $file (qw(apxs_win32.pl apr_win32.pl apu_win32.pl) ) {
push @ARGV, "--with-apache2=$apache";
unless (my $return = do $file) {
@@ -34,10 +38,20 @@
sub search {
my $apache;
-if (my $bin = which('Apache')) {
-(my $candidate = dirname($bin)) =~ s!bin$!!;
-if (-d $candidate and check($candidate)) {
+my $candidate;
+my $bin;
+if ($bin = which('Apache.exe')) {
+($candidate = dirname($bin)) =~ s!bin$!!;
+if (-d $candidate and check($candidate, "Apache.exe")) {
+$apache = $candidate;
+$progname = "Apache.exe";
+}
+}
+elsif ($bin = which('httpd.exe')) {
+($candidate = dirname($bin)) =~ s!bin$!!;
+if (-d $candidate and check($candidate, "httpd.exe")) {
$apache = $candidate;
+$progname = "httpd.exe";
}
}
unless ($apache and -d $apache) {
diff -u3 apxs/README apxs-win32/README
--- apxs/README Fri Jul 22 14:56:33 2005
+++ apxs-win32/README Tue Mar 16 22:36:36 2004
@@ -10,14 +10,3 @@
Randy Kobes <[EMAIL PROTECTED]>
March 17, 2004
-
-If you are building for Apache 2.1-dev/2.2, you will discover
-that it's now httpd.exe, not Apache.exe.
-
- perl Configure.pl --with-apache-prog=httpd.exe
-
-will provide the results you hoped for.
-
-Bill Rowe
-July 22, 2005
-
diff -u3 apxs/apr_win32.pl apxs-win32/apr_win32.pl
--- apxs/apr_win32.pl Tue Mar 16 21:55:52 2004
+++ apxs-win32/apr_win32.pl Fri Jul 22 12:13:28 2005
@@ -45,7 +45,7 @@
$prefix);
}
die "Can't find a suitable Apache2 installation!"
-unless (-d $prefix and check($prefix));
+unless (-d $prefix and check_apr($prefix));
$prefix = Win32::GetShortPathName($prefix);
diff -u3 apxs/apu_win32.pl apxs-win32/apu_win32.pl
--- apxs/apu_win32.pl Tue Mar 16 21:56:52 2004
+++ apxs-win32/apu_win32.pl Fri Jul 22 12:13:47 2005
@@ -45,7 +45,7 @@
$prefix);
}
die "Can't find a suitable Apache2 installation!"
-unless (-d $prefix and check($prefix));
+unless (-d $prefix and check_apu($prefix));
$prefix = Win32::GetShortPathName($prefix);
diff -u3 apxs/apxs_win32 apxs-win32/apxs_win32
--- apxs/apxs_win32 Tue Mar 16 22:25:16 2004
+++ apxs-win32/apxs_win32 Fri Jul 22 13:18:24 2005
@@ -687,7 +687,7 @@
# the used tools
APXS=apxs
-APACHECTL=Apache.exe -k
+APACHECTL=$progname -k
# additional defines, includes and libraries
#DEFS=-Dmy_define=my_value
diff -u3 apxs/apxs_win32.pl apxs-win32/apxs_win32.pl
--- apxs/apxs_win32.pl Tue Mar 16 22:13:44 2004
+++ apxs-win32/apxs_win32.plFri Jul 22 13:16:45 2005
@@ -7,8 +7,9 @@
use ExtUtils::MakeMaker;
use File::Spec::Functions;
require 'util.pl';
-my ($apache, $help);
+my ($apache, $progname, $help);
GetOptions( 'with-apache2=s' => \$apache,
+ 'with-apache-prog=s' => \$progname,
'help' => \$help,
) or usage($0);
usage($0) if $help;
@@ -18,7 +19,7 @@
$apache);
}
die "Can't find a suitable Apache2 installation!"
-unless (-d $apache and check($apache));
+unless (-d $apache and check_httpd($apache, $progname));
$apache = Win32::GetShortPathName($apache);
@@ -166,7 +167,7 @@
ab_LTFLAGS =
checkgid_LTFLAGS =
APACHECTL_ULIMIT =
-progname = Apache.exe
+progname = httpd.exe
MPM_LIB = server/mpm/winnt/
OS = win32
OS_DIR = win32
diff -u3 apxs/util.pl apxs-win32/util.pl
--- apxs/util.plWed Aug 20 22:59:52 2003
+++ apxs-win32/util.pl Fri Jul 22 13:19:56 2005
@@ -3,11 +3,13 @@
print <<"END";
Usage: perl $script [--with-apache2=C:\Path\to\Apache2]
+perl $script [--with-apache-prog=httpd.exe]
perl $script --help
Options:
--with-apache2=C:\Path\to\Apache2 : specify the
Re: Revisions to Testing POD
Well, I posted too fast. Scratch that first diff for this version which
has a bit more detail about how the UPLOAD function is working.
William
--
Knowmad Services Inc.
http://www.knowmad.com
--- testing.pod.orig2005-07-06 09:21:53.0 -0400
+++ testing.pod 2005-07-06 15:26:19.0 -0400
@@ -1099,8 +1099,8 @@
my $data = GET_BODY $url;
ok t_cmp(
- "Amazing!",
$data,
+ "Amazing!",
"basic test",
);
@@ -1501,8 +1501,8 @@
my $expected = "COOL";
ok t_cmp(
- $expected,
$received,
+ $expected,
"testing TestApache::cool",
);
@@ -1740,7 +1740,7 @@
=back
-These are two special methods added by the C framework:
+These are two special methods added by the C framework:
=over
@@ -1755,6 +1755,12 @@
UPLOAD $location, filename => $filename, 'X-Header-Test' => 'Test';
+This function sends the form data in a POST response. To insert additional
+parameters, append them as 'key' => 'value' elements as in the following
+example:
+
+ UPLOAD $location, filename => $filename, 'my_file_name' => 'Test.txt',
'username' => 'Captain Kirk', 'password' => 'beam me up';
+
To upload a string as a file, use:
UPLOAD $location, content => 'some data';
@@ -1986,8 +1992,8 @@
my $first = req($same_interp, $url);
my $second = req($same_interp, $url);
ok t_cmp(
- 1,
$first && $second && ($second - $first),
+ 1,
"the closure problem is there",
);
sub req {
@@ -2449,19 +2455,19 @@
be always called no matter whether the first argument will evaluate to
a true or a false value. For example, if you had a function:
- ok t_cmp($expected, $received, $comment);
+ ok t_cmp($received, $expected, $comment);
and now you want to run this sub-test if module C is
available, changing it to:
my $should_skip = eval { require HTTP::Date } ? "" : "missing HTTP::Date";
- skip $should_skip, t_cmp($expected, $received, $comment);
+ skip $should_skip, t_cmp($received, $expected, $comment);
will still run C even if C is not
available. Therefore it's probably better to code it in this way:
if (eval {require HTTP::Date}) {
- ok t_cmp($expected, $received, $comment);
+ ok t_cmp($received, $expected, $comment);
}
else {
skip "Skip HTTP::Date not found";
@@ -2612,7 +2618,7 @@
eval {foo();}
if ($@) {
- ok t_cmp(qr/^expecting foo/, $@, "func eval");
+ ok t_cmp($@, qr/^expecting foo/, "func eval");
}
which is the same as:
Revisions to Testing POD
I've been working with adding upload tests to my script and have a few
additions to make to the testing.pod file which are attached. I've also
updated all the t_cmp() examples to indicate the new format of received,
expected, comment.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
--- testing.pod.orig2005-07-06 09:21:53.0 -0400
+++ testing.pod 2005-07-06 15:19:33.0 -0400
@@ -1099,8 +1099,8 @@
my $data = GET_BODY $url;
ok t_cmp(
- "Amazing!",
$data,
+ "Amazing!",
"basic test",
);
@@ -1501,8 +1501,8 @@
my $expected = "COOL";
ok t_cmp(
- $expected,
$received,
+ $expected,
"testing TestApache::cool",
);
@@ -1740,7 +1740,7 @@
=back
-These are two special methods added by the C framework:
+These are two special methods added by the C framework:
=over
@@ -1755,6 +1755,10 @@
UPLOAD $location, filename => $filename, 'X-Header-Test' => 'Test';
+Or additional parameters:
+
+ UPLOAD $location, filename => $filename, 'username' => 'Captain Kirk',
'password' => 'beam me up';
+
To upload a string as a file, use:
UPLOAD $location, content => 'some data';
@@ -1986,8 +1990,8 @@
my $first = req($same_interp, $url);
my $second = req($same_interp, $url);
ok t_cmp(
- 1,
$first && $second && ($second - $first),
+ 1,
"the closure problem is there",
);
sub req {
@@ -2449,19 +2453,19 @@
be always called no matter whether the first argument will evaluate to
a true or a false value. For example, if you had a function:
- ok t_cmp($expected, $received, $comment);
+ ok t_cmp($received, $expected, $comment);
and now you want to run this sub-test if module C is
available, changing it to:
my $should_skip = eval { require HTTP::Date } ? "" : "missing HTTP::Date";
- skip $should_skip, t_cmp($expected, $received, $comment);
+ skip $should_skip, t_cmp($received, $expected, $comment);
will still run C even if C is not
available. Therefore it's probably better to code it in this way:
if (eval {require HTTP::Date}) {
- ok t_cmp($expected, $received, $comment);
+ ok t_cmp($received, $expected, $comment);
}
else {
skip "Skip HTTP::Date not found";
@@ -2612,7 +2616,7 @@
eval {foo();}
if ($@) {
- ok t_cmp(qr/^expecting foo/, $@, "func eval");
+ ok t_cmp($@, qr/^expecting foo/, "func eval");
}
which is the same as:
Re: [MP2] Bug Report - Segfault when using Image::Magick
On Tue, Jun 07, 2005 at 11:40:49PM +1000, Stas Bekman wrote: > Something is not right here. Your perl is not threaded: > > However the segfault shows threads operation: Yeah, it's bizarre. > >#0 0x882fa1d7 in kill () from /lib/libc.so.5 > >(gdb) bt > >#0 0x882fa1d7 in kill () from /lib/libc.so.5 > >#1 0x882ef27e in raise () from /lib/libc.so.5 > >#2 0x88361627 in abort () from /lib/libc.so.5 > >#3 0x885d9c3f in _thread_exit () from /usr/lib/libc_r.so.5 > >#4 0x885d8311 in _thread_init () from /usr/lib/libc_r.so.5 > >#5 0x885cf1cc in _thread_init_hack () from /usr/lib/libc_r.so.5 > >#6 0x885db322 in _find_thread () from /usr/lib/libc_r.so.5 > > Have you built that module with that same perl? Try rebuilding it, first > nuking any preinstalled instance of it (especially .so files). Which module are you referring to? mod_perl or Perl or Image::Magick? I'm not sure which .so files I need to nuke and rebuild. Looking at the segfault, it seems to occur in Perl rather than mod_perl. I've rebuilt mod_perl many times but it still segfaults (even with the mod_perl I just built with debugging flags enabled). Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: [MP2] Bug report - errors when compiling with MP_DEBUG flag
On Tue, Jun 07, 2005 at 11:35:46PM +1000, Stas Bekman wrote:
> That's OK, William. But you aren't after defined symbols in .so, you are
> after the APR_HAS_THREADS define which should be undef. Moreover, you are
> building a static version so the symbols aren't coming from .so but .a/.la
> archives.
OK, that's useful to know.
> If you look at the linking command that you've pasted in the original
> report it had:
>
> /usr/local/src/httpd-2.0.54/srclib/apr/libapr-0.la
>
> which is the one that you need to check.
Actually, I had taken a look in that file but there's nothing being
defined in there.
> >I then grepped by mod_perl and httpd source directories for header files
> >which defined APR_HAS_THREADS. I changed srclib/apr/include/apr.h and
> >srclib/apr/include/apr.hnw then reconfigured mod_perl but it still
> >failed.
>
> Please find all occurences of apr.h and check the value of APR_HAS_THREADS.
OK, I ran the following command and have found the file which set that
value to 1:
find / -name *apr.h -print -exec grep APR_HAS_THREADS {} \;
After setting it to 0, I reran the build process. That appears to be
working now but I'm still having some problems with tests failing :(.
The important thing is the debug flags should be on for this build. I
can live with some of the tests failing.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
[MP2] Bug Report - Segfault when using Image::Magick
-8<-- Start Bug Report 8<-- 1. Problem Description: When using Image::Magick (either 6.1.9.4 or 6.2.3) under mod_perl, the server segfaults. Used at the command line or under mod_cgi there are no errors. A core dump is attached. This is my first attempt at extracting a backtrace from a core dump. I only rebuilt mod_perl with debugging enabled so am not sure if it is sufficient for debugging this problem. It looks to me that the system is calling thread-enabled libraries which does not make sense given that my perl binary is not threaded. My hosting provided and I used ldd to check the httpd binary and the perl binary but neither were linked with lib_r which he says is the older pthreads under FreeBSD. This may be a continuation of a problem I reported earlier regarding building a debug version of mod_perl. For some reason, my system is finding APR_HAS_THREADS defined. Perhaps if I could figure out why that is defined and make it undefined, this segfault will disappear. 2. Used Components and their Configuration: *** mod_perl version 2.00 *** using /stubs/usr_local/src/mod_perl-2.0.0/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB => aprext MP_AP_CONFIGURE => --with-mpm=prefork --prefix=/usr/local/apache2_perl --enable-rewrite=static MP_AP_PREFIX=> /usr/local/src/httpd-2.0.54 MP_COMPAT_1X=> 1 MP_DEBUG=> 1 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_TRACE=> 1 MP_USE_STATIC => 1 *** The httpd binary was not found *** (apr|apu)-config linking info -L/usr/local/src/httpd-2.0.54/srclib/apr-util/.libs -L/usr/local/src/httpd-2.0.54/srclib/apr-util -laprutil-0 -lexpat -L/usr/local/src/httpd-2.0.54/srclib/apr/.libs -L/usr/local/src/httpd-2.0.54/srclib/apr -lapr-0 -lm -lcrypt *** /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 [EMAIL PROTECTED]:usrobjusrsrcsysbywater-smp i386 ' config_args='-sde -Dprefix=/usr/public/ -Dotherlibdirs=/usr/public//lib/perl5/site_perl/5.8.6/mach:/usr/public//lib/perl5/site_perl/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 -Dscriptdir=/usr/public//bin -Dsitearch=/usr/local/lib/perl5/site_perl/5.8.6/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.8.6 -Dsiteman3dir=/usr/local/lib/perl5/5.8.6/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsitebin=/usr/local/bin -Dsitescript=/usr/local/bin -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/i386-freebsd-64int/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 15 2005 07:22:27 %ENV: PERL_LWP_USE_HTTP_10="1" @INC: /usr/local/lib/perl5/site_perl/5.8.6/mach /usr/local/lib/perl5/site_perl/5.8.6 /usr/local/lib/perl5/site_perl /usr/public//lib/perl5/5.8.6/BSDPAN /usr/public/lib/p
Re: [MP2] Bug report - errors when compiling with MP_DEBUG flag
On Tue, Jun 07, 2005 at 09:34:29AM +1000, Stas Bekman wrote: > William, as you can see from the source src/modules/perl/modperl_util.h > > #if defined(MP_TRACE) && defined(APR_HAS_THREADS) > #define MP_TRACEf_TID "/tid 0x%lx" > #define MP_TRACEv_TID (unsigned long)apr_os_thread_current() > > The symbol is available if APR_HAS_THREADS is defined. So the apr header > containing this definition found by mod_perl says that APR_HAS_THREADS is > defined, whereas the library it tries to link against was compiled with > threads disabled. Meaning that you have more than one libapr on your > system and the wrong library gets linked. Stas, Thanks for the references. I tried searching for libaprutil-0.so but couldn't see any in the path. I used nm on every libaprutil-0.so file I could find but turned up no instances of a library which had the apr_os_thread_current function. I then grepped by mod_perl and httpd source directories for header files which defined APR_HAS_THREADS. I changed srclib/apr/include/apr.h and srclib/apr/include/apr.hnw then reconfigured mod_perl but it still failed. Once I commented out the defines in modperl_util.h, it appears to have worked. I'll submit my bug report in a separate email. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: [MP2] Bug report - errors when compiling with MP_DEBUG flag
On Sat, Jun 04, 2005 at 09:29:53PM +1000, Stas Bekman wrote: > >/stubs/usr_local/src/mod_perl-2.0.0/src/modules/perl/modperl_util.c:472: > >undefined reference to `apr_os_thread_current' > >*** Error code 1 > > William, please try: > http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#undefined_symbol__apr_table_compress Stas, Thanks for the link. Unfortunately the error is occurring during the make process so I never get a blib/arch/auto/APR/APR.so being created. I tried running nm on the libapr-0.so.9 in my httpd-2.0.54 source directory. nm /usr/local/src/httpd-2.0.54/srclib/apr/.libs/libapr-0.so.9 | grep os_thread_current However, running that command without _current returns the following: 00015f3c T apr_os_thread_get 00015f48 T apr_os_threadkey_get While debugging last week, I seem to remember reading that apr_os_thread_get is synonymous with apr_os_thread_current. I wonder why the later would not be defined? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Migration to mod_perl 2.0: Problems with CGI.pm
On Thu, Jun 02, 2005 at 03:59:50PM +0100, Johannes Kilian wrote: > I try to migrate to mod_perl 2.0 from mod_perl 1.99 RC4 (WinXP, > ActiveState Perl 5.8.6) > > Running my old scripts the following error occurs in Module cgi.pm: > Can't locate Apache/Response.pm in @INC Did you read the Migrating to mod_perl 2.0 renaming doc[1]? Are you using the right version of CGI? A proper bug report using mp2bug would have let us know. William [1] http://perl.apache.org/docs/2.0/rename.html -- Knowmad Services Inc. http://www.knowmad.com
[MP2] Bug report - errors when compiling with MP_DEBUG flag
-8<-- Start Bug Report 8<-- 1. Problem Description: While trying to track down a segfault that is occurring with Image::Magick, I went to build a version of mod_perl with debugging flags. Unfortunately this does not build for me under FreeBSD 5.3. Here is the error I receive during make: /usr/local/src/httpd-2.0.54/srclib/apr/libtool --silent --mode=link gcc -D_REENTRANT -D_THREAD_SAFE -DAP_HAVE_DESIGNATED_INITIALIZER -I/usr/local/src/httpd-2.0.54/srclib/apr/include -I/usr/local/src/httpd-2.0.54/srclib/apr-util/include -I/usr/local/include -I. -I/usr/local/src/httpd-2.0.54/os/unix -I/usr/local/src/httpd-2.0.54/server/mpm/prefork -I/usr/local/src/httpd-2.0.54/modules/http -I/usr/local/src/httpd-2.0.54/modules/filters -I/usr/local/src/httpd-2.0.54/modules/proxy -I/usr/local/src/httpd-2.0.54/include -I/usr/local/src/httpd-2.0.54/modules/generators -I/usr/local/src/httpd-2.0.54/modules/dav/main -export-dynamic -L/usr/local/lib -o httpd modules.lo /stubs/usr_local/src/mod_perl-2.0.0/src/modules/perl/mod_perl.a modules/aaa/mod_access.la modules/aaa/mod_auth.la modules/filters/mod_include.la modules/loggers/mod_log_config.la modules/metadata/mod_env.la modules/metadata/mod_setenvif.la modules/http/mod_http.la modules/http/mod_mime.la modules/generators/mod_status.la modules/generators/mod_autoindex.la modules/generators/mod_asis.la modules/generators/mod_cgi.la modules/mappers/mod_negotiation.la modules/mappers/mod_dir.la modules/mappers/mod_imap.la modules/mappers/mod_actions.la modules/mappers/mod_userdir.la modules/mappers/mod_alias.la modules/mappers/mod_rewrite.la modules/mappers/mod_so.la server/mpm/prefork/libprefork.la server/libmain.la os/unix/libos.la /usr/local/src/httpd-2.0.54/srclib/pcre/libpcre.la -Wl,-R/usr/public/lib/perl5/5.8.6/i386-freebsd-64int/CORE -Wl,-E -L/usr/local/lib /usr/public/lib/perl5/5.8.6/i386-freebsd-64int/auto/DynaLoader/DynaLoader.a -L/usr/public/lib/perl5/5.8.6/i386-freebsd-64int/CORE -lperl -lm -lcrypt -lutil /usr/local/src/httpd-2.0.54/srclib/apr-util/libaprutil-0.la -lexpat /usr/local/src/httpd-2.0.54/srclib/apr/libapr-0.la -lm -lcrypt /stubs/usr_local/src/mod_perl-2.0.0/src/modules/perl/mod_perl.a(modperl_util.o)(.text+0x14a8): In function `modperl_perl_call_list': /stubs/usr_local/src/mod_perl-2.0.0/src/modules/perl/modperl_util.c:472: undefined reference to `apr_os_thread_current' *** Error code 1 Stop in /stubs/usr_local/src/httpd-2.0.54. *** Error code 1 Stop in /stubs/usr_local/src/httpd-2.0.54. *** Error code 1 Stop in /stubs/usr_local/src/mod_perl-2.0.0. 2. Used Components and their Configuration: *** mod_perl version 2.00 *** using /stubs/usr_local/src/mod_perl-2.0.0/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB => aprext MP_AP_CONFIGURE => --with-mpm=prefork --prefix=/usr/local/apache2_perl --enable-rewrite=static MP_AP_PREFIX=> /usr/local/src/httpd-2.0.54 MP_COMPAT_1X=> 1 MP_DEBUG=> 1 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_TRACE=> 1 MP_USE_STATIC => 1 *** The httpd binary was not found *** (apr|apu)-config linking info -L/usr/local/src/httpd-2.0.54/srclib/apr-util/.libs -L/usr/local/src/httpd-2.0.54/srclib/apr-util -laprutil-0 -lexpat -L/usr/local/src/httpd-2.0.54/srclib/apr/.libs -L/usr/local/src/httpd-2.0.54/srclib/apr -lapr-0 -lm -lcrypt *** /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 [EMAIL PROTECTED]:usrobjusrsrcsysbywater-smp i386 ' config_args='-sde -Dprefix=/usr/public/ -Dotherlibdirs=/usr/public//lib/perl5/site_perl/5.8.6/mach:/usr/public//lib/perl5/site_perl/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 -Dscriptdir=/usr/public//bin -Dsitearch=/usr/local/lib/perl5/site_perl/5.8.6/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.8.6 -Dsiteman3dir=/usr/local/lib/perl5/5.8.6/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsitebin=/usr/local/bin -Dsitescript=/usr/local/bin -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_FL
Re: [MP2] pseudo_http.pm tests fail under FreeBSD/Jail
Ken, Thanks for the explanation. For better or worse, after a rebuild of mod_perl all of my tests are now working. I don't know what I changed but I've logged out and back onto the system and rebuilt from scratch. Everything is running perfectly which is great. Now to see if my segfault with Image::Magick (which is the real reason I got back to working on these tests) has gone away. Regards, William -- Knowmad Services Inc. http://www.knowmad.com
Re: [MP2] pseudo_http.pm tests fail under FreeBSD/Jail
On Thu, Jun 02, 2005 at 09:37:51AM -0700, Ken Simpson wrote: > It _may_ (just because I have a gut feeling, not because of actual > consideration) be a socket options issue that may be related to your > platform. I had a very similar problem with OpenBSD last summer > wherein the socket blocking status could not be changed. The fix was a > very simple change to the configure setup for APR. Yes, in all the tests that are failing for me, I see where it is checking for OpenBSD or Apache >2.0.52 which must have been when the bug was fixed. > Here's the patch that fixed that problem -- I haven't been able to > find the discussion thread yet. Thanks for the link. My version of apr_hints.m4 already has this code applied. In fact, in another thread back in February, Joe had asked me to set the ac_cv_o_nonblock_inherited value before running the tests but it did not help. Can you tell me more about the bug you had? What does a "socket options issue" mean? Do you know what ac_cv_o_nonblock_inherited is doing when it gets set? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
[MP2] pseudo_http.pm tests fail under FreeBSD/Jail
-8<-- Start Bug Report 8<-- 1. Problem Description: Following on the heels of my previous post to Stas regarding an old thread, I've another test failure report. This one is for t/protocol/pseudo_http.pm. It is failing because the connection to the server is immediately closed down. If I start the test server and try to connect via telnet, I get the following log message in t/logs/error_log: [Thu Jun 02 10:57:45 2005] [error] APR::Socket::recv: (35) Resource temporarily unavailable at /stubs/usr_local/src/mod_perl-2.0.0/t/protocol/TestProtocol/pseudo_http.pm line 118 Any suggestions on figuring out what resource is unavailable would be appreciated. I'm not to familiar with socket ops. I know that icmp is disabled inside my jail environment. 2. Used Components and their Configuration: *** mod_perl version 2.00 *** using /stubs/usr_local/src/mod_perl-2.0.0/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB => aprext MP_AP_CONFIGURE => --with-mpm=prefork --prefix=/usr/local/apache2_perl --enable-rewrite=static MP_AP_PREFIX=> /usr/local/src/httpd-2.0.54 MP_COMPAT_1X=> 1 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_USE_STATIC => 1 *** /usr/local/src/httpd-2.0.54/httpd -V Server version: Apache/2.0.54 Server built: Jun 1 2005 11:46:40 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_perl" -D SUEXEC_BIN="/usr/local/apache2_perl/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.54/srclib/apr-util/.libs -L/usr/local/src/httpd-2.0.54/srclib/apr-util -laprutil-0 -lexpat -L/usr/local/src/httpd-2.0.54/srclib/apr/.libs -L/usr/local/src/httpd-2.0.54/srclib/apr -lapr-0 -lm -lcrypt *** /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 [EMAIL PROTECTED]:usrobjusrsrcsysbywater-smp i386 ' config_args='-sde -Dprefix=/usr/public/ -Dotherlibdirs=/usr/public//lib/perl5/site_perl/5.8.6/mach:/usr/public//lib/perl5/site_perl/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 -Dscriptdir=/usr/public//bin -Dsitearch=/usr/local/lib/perl5/site_perl/5.8.6/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.8.6 -Dsiteman3dir=/usr/local/lib/perl5/5.8.6/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsitebin=/usr/local/bin -Dsitescript=/usr/local/bin -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/i386-freebsd-64int/CORE' cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_
Re: [mp2] make test errors
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_add1..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_block1..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 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
--
Knowmad Services Inc.
http://www.knowmad.com
Re: DirectoryIndex ignored when using perl-handler
On Mon, Apr 25, 2005 at 01:51:23PM -0400, Geoffrey Young wrote: > that code is essentially right. well, except that the above example sets > $r->handler instead of comparing it. adding the code at the bottom of this > mail essentially makes your tests pass, except that I think your last test > is wrong - your DirectoryIndex puts the index script ahead of everything > else, so the results should match "Hello" and not "welcome". Indeed you are correct about the bad test. I've incorporated the new fixup handler into my production config and it's working like a champ. Thanks! William -- Knowmad Services Inc. http://www.knowmad.com
Re: DirectoryIndex ignored when using perl-handler
On Wed, Apr 13, 2005 at 08:21:46PM -0400, Geoffrey Young wrote:
> hmm. I'm sorry I didn't get back to you today, but I had something
> unexpected come up. I'll be rolling rc5 tomorrow, but if you want to create
> a bug tarball for me I'll look into it with whatever resources I can
> scrounge up.
Hi Geoff,
I've finally found a chance to create the bug report tarball[1] for the
directory index problems I'm seeing. The important stuff is in
t/conf/extra.conf.in where the settings are causing the tests to fail.
Perhaps I'm doing something wrong in my settings, but as I've reported
before, these used to work under mp1.
> SetHandler is forcing the handler to be mod_perl, but really mod_dir needs
> to step in and handle the / -> DirectoryIndex conversion. so... what I would
> do is alter that fixup handler to do something like this
>
> if ($r->handler('perl-script') && -d $r->filename && $r->is_initial_req) {
> $r->hander(Apache2::Const::DIR_MAGIC_TYPE);
> }
>
> or somesuch. basically, what you want to happen is for mod_dir to apply the
> directory index and issue it's normal internal_direct to mod_perl. un-doing
> mod_mime's SetHandler for just the main request ought to do that.
I tried adding the above code to Apache::Dir (I fixed the $r->hander to
$r->handler) and found that I needed to include a 'use
Apache::RequestRec' statement (yes, I'm still on RC4 at the moment).
Now, the server is returning a 403 error with the following entry in the
error log when I try to retrieve the index.html:
[Mon Apr 25 09:48:17 2005] [error] file permissions deny server
execution /home/william/Apache-Test-skeleton-mp2/t/htdocs/index.html
This is followed by the usual error about not being able to serve the
directory when I try to GET '/' in t/01basic.t. It looks like the gist
is that the suggested patch didn't work or was incorrectly applied.
Thanks,
William
[1] http://66.151.211.202/~william/apache2-directoryindex-error.tgz
(let me know if you have any problems retrieving that file; it may be
behind a firewall)
--
Knowmad Services Inc.
http://www.knowmad.com
Re: DirectoryIndex ignored when using perl-handler
On Tue, Apr 12, 2005 at 08:33:59PM -0400, Geoffrey Young wrote: > for a good discussion, and a fixup handler that will likely fix your > problem. you can also search the archives for the Apache::Dir discussion > that (IIRC) yielded that document. Geoff, I tried using Apache::Dir. The current version on CPAN only supports mp1. Adding support for mp2 was easy enough but yielded no beneficial results (i.e., I still get 404 errors and the Apache log error). I wrote to David W. who maintains the module; he had no further suggestions so I did some further debugging. It turns out that I'm not having a problem with appending a trailing slash; Apache seems to be doing this just fine with or without the Apache::Dir module. The problem I'm having is that Apache is not setting the DirectoryIndex to a valid filename. It is instead complaining that it's trying to serve a directory. This is probably because ModPerl::Registry is handling the directory as turning off the SetHandler allows those indexes to be served (albeit I'm getting the script displayed as a text file instead of run as a perl script). I also searched the archives for Apache::Dir as well as the Apache log error but could not find a discussion about this issue. Any more ideas for me? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: DirectoryIndex ignored when using perl-handler
On Tue, Apr 12, 2005 at 08:33:59PM -0400, Geoffrey Young wrote: > yes, because mp1 is configured to handle requests of type DIR_MAGIC_TYPE > whereas mp2 is not. this is a bug or a feature, depending on whether you > think mp1 was correct or not :) OK, that makes sense. I was beginning to worry about my sanity :). > see > > http://www.masonhq.com/?HandlingDirectoriesWithDhandlers > > for a good discussion, and a fixup handler that will likely fix your > problem. you can also search the archives for the Apache::Dir discussion > that (IIRC) yielded that document. Oddly, the last line of the document (before the comments) says: So none of the above solutions should be necessary in mod_perl 2, but as of this writing, I doubt that Mason handles directories with mod_perl 2 at all. I presume that's in relation to Mason. Do you think that the --permute-module would option work in my case? Any reason to use Apache::Dir in favor of reordering the modules (assuming that one has complete control over the httpd binary)? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
DirectoryIndex ignored when using perl-handler
Hi, This message is probably coming at a bad time with the recent release of RC5. I'm still in the process of migrating from mp1 to mp2-RC4 at the moment. I have a directory which is setup to be served via ModPerl::Registry. When I try to open the path with only the directory name (e.g., http://localhost/), I receive a 404 error in my browser and get errors in my log like the following: Attempt to serve directory: /home/path/to/document/root/ If I put a filename in the url (e.g., http://localhost/index) or disable perl-handler, Apache is correctly serving the index file. Any ideas on why Apache would appear to be ignoring my DirectoryIndex setting? Here's the relevant part of my httpd.conf: AllowOverride None Options ExecCGI MultiViews -Indexes SymLinksIfOwnerMatch IncludesNoExec DirectoryIndex index login index.html # default handler is perl-script PerlSendHeader On SetHandler perl-script PerlResponseHandler ModPerl::Registry SetHandler None SetHandler None This configuration had been working under mp1. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Apache Segfault because of mod_perl?
On Thu, Mar 31, 2005 at 12:33:21PM +0200, Peter Roosdorp wrote: > Any ideas? Where can I get help with this? Hi Peter, Start with filling out a bug report[1]. William [1] http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems -- Knowmad Services Inc. http://www.knowmad.com
Re: [mp1] "Can't locate object method 'handler' via package 'handler'..."
On Fri, Mar 18, 2005 at 09:10:11AM +, Andrew Green wrote: > I fear that the fact that the problem is really very intermittent might > hamper this, however. I should also probably have pointed out that > there's a PostReadRequestHandler and a TransHandler in the config as > well, which I guess may make a huge difference! Hi Andrew, I've had good luck tracking down these kind of bugs using the Apache::Test[1] framework which allows me to configure a test server the same way as my production server and run multiple tests or do start/restart testing (with the aid of some shell scripts) or do concurrency testing. There is a skeleton[2] that you can use to help get started. Good luck, William [1] http://perl.apache.org/docs/general/testing/testing.html [2] http://perl.apache.org/~geoff/Apache-Test-skeleton-mp1.tar.gz -- Knowmad Services Inc. http://www.knowmad.com
Re: shared memory
On Tue, Mar 15, 2005 at 05:31:28PM -0500, Perrin Harkins wrote: > BerkeleyDB, MySQL, or SQLite3, but I don't think BDB works in Win32. Please don't tell my code that :). It's been using the BerkeleyDB module on a daily basis for nearly a year with few problems. The module is available as a PPM on the theoryx5 server. I wrote up a node on PerlMonks last year about handling concurrency when using BerkeleyDB[1]. Before that, I'd never used it but would pick up it again in a heartbeat due to its ease, speed and to Perrin's recommendations (in the appropriate situation, of course). William [1] http://perlmonks.org/?node_id=330510 -- Knowmad Services Inc. http://www.knowmad.com
Re: ModPerl performance on BSDs
On Thu, Mar 10, 2005 at 04:15:38PM -0500, Jonathan Vanasco wrote: > I've been looking mostly at NetBSD, FreeBSD and OpenBSD -- has anyone > had remarkable success or misfortune with modperl2 under these > environments in regards to speed or running? Hi Jonathan, I've been running mp1 under FreeBSD 4.9 for several years without incident (was using Apachetoolkit to compile from scratch). Recently I've been working on getting mp2 installed under FreeBSD 5.3. Outside of some issues with the tests running inside of a jailed process[1], I've seen no problems. I haven't gone into production with mp2 nor have I done any benchmark comparisons. However, I have noticed that my web pages can sometimes load faster off the live server that sits halfway across the US vs. my local Linux server (it's a bit of an unfair comparison as the hardware on the production server is far more powerful). HTH, William [1] Stas, I'm still working on tracking down the issues. Just been sidetracked by my work lately. -- Knowmad Services Inc. http://www.knowmad.com
Tagging svn modperl2 releases?
svn co http://svn.apache.org/repos/asf/perl/modperl/tags/1_999_21 modperl2 Fetching external item into 'modperl2\docs' actually fetches from https:// - it jumps scope, breaks non-ssl clients. Fetching external item into 'modperl2\Apache-Test' svn: URL 'https://svn.apache.org/repos/asf/httpd/test/trunk/perl-framework/Apache-Test' doesn't exist also fetches from https:// but worse, Apache-Test moved. This isn't a workable scenario, since 1_999_21 is a tag, but tries to grab these moving targets which can't be traced back at the time. I'm not certain what the right answer is, but I suspect it involves breaking the 'checkout other' association and making an svn copy of these dependencies into the release tag. This seems like the purest solution, and such tag copies are cheap. If the desire is to use some specific version of Apache-Test or docs, it's simply to copy that tags/ tree instead of the trunk/. I did check https://svn.apache.org/repos/asf/httpd/test/tags/ and https://svn.apache.org/repos/asf/perl/Apache-Test/tags/ and did not see anything corresponding to 1_999_21 (although earlier releases obviously did tag these files appropriately.) If I had a vote, it would be most definitely -1 for the RC4 tarball, simply due to this inability to track what it contained. I'm working from 1_999_21 and yesterday's Apache-Test, and will evaluate the general results in anticipation of an RC5. Definitely think 2.0 is overdue, but these versioning issues aught to be resolved first. Bill
Re: Foolish Q - 2.0_RC4?
At 07:05 PM 3/9/2005, Geoffrey Young wrote: >> official releases are also always on >> >> http://svn.apache.org/viewcvs.cgi/perl/modperl/ > >blarg, cut and paste error. I meant > > http://perl.apache.org/dist/ I hope you ment http://www.apache.org/dist/perl/ since that's what our mirrors capture. That said, I always work from the repositories, so thanks for the pointer :)
Foolish Q - 2.0_RC4?
I can't seem to locate the source repository point for _RC4... Looked in; http://svn.apache.org/repos/asf/perl/modperl/tags/ as well as http://cvs.apache.org/viewcvs.cgi/ (which I see modperl2 is now gone.) Any pointers? Would like to give this a thorough drubbing so I can toss my ++ into the ring for release :) Bill
Re: [mp2] make test errors
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
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 TestStat Wstat Total Fail Failed List of Failed --- t/api/access2.t 63 50.00% 2 5-6 t/modperl/setupenv.t 636 9.52% 8 22 29 36 50 57 t/preconnection/note.t11 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] query_string
On 18 Feb 2005, at 13:11, Geoffrey Young wrote: William Ross wrote: hello list. very dumb question for you: with mod_perl2 and apreq2, what is the proper way to get the raw query string? using just the mp2 api its $r->args, just like mp1 http://perl.apache.org/docs/2.0/api/Apache/RequestRec.html#C_args_ using apreq2 it looks like you would need $apr->env->args, since $apr->args returns a table not the unparsed string. Lovely. Thank you. I knew there would be a clean way to do it. best will
Re: [mp2] make test errors
On Fri, Feb 18, 2005 at 01:40:44PM +, 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
[mp2] query_string
hello list. very dumb question for you: with mod_perl2 and apreq2, what is the proper way to get the raw query string? (I want to pass it through the login process.) or is this Bad Thinking? thanks will
Re: [mp2] make test errors
On Thu, Feb 17, 2005 at 04:53:45PM +, 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: Apache::Request equivalent of CGI::Capture?
On Wed, Feb 16, 2005 at 10:40:52PM -0500, Stas Bekman wrote: > I wonder if it'd be a good idea to make CGI.pm libapreq aware. Most people > use CGI.pm since it parses input and generates the output, so empowering > CGI.pm with libapreq speed would be really cool. Actually, I thought[1] the goal of Apache::Request was to mimic most of the functions in CGI.pm. I know that Michael Peters (who is hopefully reading this message and can speak for himself) had to do some extra coding for his CGI::Application plugin[2] which uses the Apache::* modules when running inside a mod_perl environment. From a programmers point-of-view, there are some extra keystrokes involved if you want to support both mod_cgi and mod_perl simply due to the difference in the APIs. I suppose though that adding libapreq to CGI.pm would garner more results for more developers faster than amending the A::R API to mimic CGI.pm (which may not even be the goal of this module). William [1] Presently, I'm primarily an Apache::Registry user. [2] http://search.cpan.org/~wonko/CGI-Application-Plugin-Apache-0.10/ -- Knowmad Services Inc. http://www.knowmad.com
Re: [mp2] Documentation patch for install.pod
On Wed, Feb 16, 2005 at 10:52:06PM -0500, Stas Bekman wrote: > Thanks, William. I've committed an extended version of your patch but at > the beginning of that section. Please let me know if it needs more work. Looks good. That explains it the way I now understand it to work. > I believe the error message should have explained that in first place. If > it's not clear enough (which is most likely the case, if you did read it), > you know what to do :) Yes, I see it now. It had scrolled past so fast that by the time I was prompted to run the tests, I had forgotten about the messages. Mea culpa. William -- Knowmad Services Inc. http://www.knowmad.com
Re: [mp2] make test errors
On Thu, Feb 17, 2005 at 10:39:46AM +, 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
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
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
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
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
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] Documentation patch for install.pod
> 2) if you build a static mod_perl, it'll configure and make Apache for you. Ahh, so I don't even need to configure Apache if I'm building a static mod_perl. I've amended the install.pod to indicate as much. > You should not run it *from under /root directory or similar*, but as long > as you run from somewhere where non-root user can access files (e.g. > /tmp), running as 'root' should work just fine. I see the difference now. I was installing from /usr/local/src so that test should have worked. William -- Knowmad Services Inc. http://www.knowmad.com --- install.pod.orig2005-02-16 15:19:27.0 -0500 +++ install.pod 2005-02-16 17:09:50.0 -0500 @@ -219,6 +219,9 @@ Do B use that CFLAGS in production unless you know what you are doing. +This step is not necessary if you are building a static mod_perl. Just be sure +the Apache source is available. +
Re: [mp2] make test errors
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
#!/usr/bin/perl -w
use IO::Socket;
my $host = 'localhost';
my $port = '8529';
my $socket = IO::Socket::INET->new(PeerAddr => $host, PeerPort => $port) or die "Unable to create listener socket: $!";
my @test_strings = qw(MODPERL 2.0 RULES);
for my $str (@test_strings) {
print $socket "$str\n";
chomp(my $reply = <$socket>||'');
$str = lc $str;
$str =~ s/modperl/mod_perl/;
print ("Reply = $reply\nExpected = $str\n");
}
Re: [mp2] make test errors
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] Documentation patch for install.pod
> committed the first part of it (those who know what options to use don't > need extra explanation, those who don't know won't find the extra > explanation sufficient). That's fine. The second part was more for my own edification. > It's never the case. In the case of DSO it never happens. In the case of > static build Apache server is built during 'make'. > as you say above, it's not the case with DSO. Yeah, that makes sense now. In the case of static mod_perl builds, is there any reason to run make && make install while getting apache source files ready? It seems like I could just do the configure part then let mod_perl build the server from there. > Why do you say so? It should work fine under root. If it doesn't, it > should be fixed rather than documented. please follow the usual routine > as explained here: http://perl.apache.org/bugs/ This was my experience and I faintly remembered you suggesting that Apache::Test should not be run as root so surmised that that was my problem. Right now, I do not have time to track down this error. If I can repeat it at a later time, I will file a proper bug report. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: [mp2] make test errors
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: build problems with apache 1.3.33 and mod_perl 1.29
On Sat, Feb 12, 2005 at 11:12:07AM -0500, John Klassa wrote: > Am I missing something obvious? I'm not familiar with this error. Try filing a complete bug report[1] and you'll have better luck getting some assistance. William [1] http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems -- Knowmad Services Inc. http://www.knowmad.com
[mp2] Documentation patch for install.pod
I finally took the plunge and installed mp2 onto my FreeBSD virtual server. Here are a few updates to the install.pod which would have made the installation process a bit easier for me. I'm not sure about the modification I made at line ~617. I installed a static mod_perl so presume that the server had to be rebuilt. When I first read the recipe, it didn't make much sense that I would install Apache then build mod_perl. The line I added helps clear it up. Does the server also get rebuilt if compiling a dynamic mod_perl? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com --- install.pod.orig2005-02-13 09:18:58.0 -0500 +++ install.pod 2005-02-14 00:17:24.0 -0500 @@ -289,7 +289,11 @@ % cd modperl-1.99_xx % perl Makefile.PL -where I is an optional list of (key,value) pairs. +where I is an optional list of (key,value) pairs. These options can +include all the usual options supported by ExtUtils::MakeMaker (e.g., PREFIX, +LIB, etc.). This is particuarly useful when installing the Apache::* libraries +to non-standard locations such as when doing non-root or virtual server +installations. The following sections give the details about all the available options, but let's mention first an important one. @@ -616,7 +620,8 @@ =head2 Installing mod_perl -Once the test suite has passed, it's a time to install mod_perl. +Once the test suite has passed, it's a time to install mod_perl. This step +will rebuild the Apache server. % make install @@ -634,6 +639,18 @@ installation process from scratch, while verifying all the steps with this document. +=over + +=item * +make test exists with "Error code 1" before any tests begin + +Be sure that you are not trying to run the tests as root. Log in as a regular +user and be sure that user has rwx privileges to the files in the source +directory. + + +=back + If the problem persists L.
[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.t43 75.00% 2-4 t/preconnection/note.t 11 100.00% 1 t/protocol/echo_block.t32 66.67% 2-3 t/protocol/echo_filter.t 32 66.67% 2-3 t/protocol/pseudo_http.t 139 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 ho
Re: Problem Installing libapreq2-2.04-dev on Freebsd
On Tue, Feb 08, 2005 at 08:33:18AM +, gotta go wrote: > trying to install libapreq2-2.04-dev on freebsd 4.8 results in the > following error. > make: don't know how to make all-local. Stop > *** Error code 1 This looks like a make error. I've not tried to build mp2 under FreeBSD, but I know that some programs prefer gnumake (the make program that comes with FreeBSD is not the same; hopefully these issues will be resolved when more projects are ported to using Module::Build). You can get gnumake from your ports/packages collection and retry the build using gmake instead of make. Good luck, William -- Knowmad Services Inc. http://www.knowmad.com
Re: CGI::Session or CGI::Application
Hi Perrin, Thanks for the feedback. I've been meaning to find a better alternative. I think many programmers writing standard cgi scripts are scared off from using the Apache::Session modules because of the chosen namespace, although I understand that it's possible to use them outside of Apache. Maybe someone with extra tuits could rewrite CGI::Session to use Apache::Session for the backend. My point of the previous message was more that CGI::Session needs some TLC, esp. since the original author is obviously not responding. Like others, I've submitted CPAN bug reports and even sent direct emails to him without response over the past 12 months. William -- Knowmad Services Inc. http://www.knowmad.com
Re: CGI::Session or CGI::Application
On Sat, Jan 15, 2005 at 08:15:31AM -0500, Michael Peters wrote: > CGI::Session does not appear to be well maintained. It's very popular > and I know many people who have tried to send in patches and fixes but > the author has been unresponsive. Which is really ashame since it's listed in the Phalanx 100[1]. Nonetheless, it's been working fine for me (via the CGI::Application::Plugin::Session module). William [1] http://qa.perl.org/phalanx/distros.html -- Knowmad Services Inc. http://www.knowmad.com
Re: [mp1] Linking confusion
On Fri, Dec 31, 2004 at 02:02:59PM -0500, Stas Bekman wrote: > Thanks William, I've committed that with a few tweaks. Especially the last > para. Please check that it still makes sense. Looks fine except for a couple of typos (dangling quote mark and mispelled 'should'). Also, now that I'm a bit more knowledgeable about the subject matter, I was able to find this reference[1] in your docs which I've added to the attached patch. William [1] http://perl.apache.org/docs/1.0/guide/install.html#libperl_so_and_libperl_a -- Knowmad Services Inc. http://www.knowmad.com --- /tmp/install.pod.orig 2004-12-31 15:07:11.0 -0500 +++ /tmp/install.pod.wlm2004-12-31 15:04:56.0 -0500 @@ -688,7 +688,7 @@ that comes with Perl source. =for html Also see http://modperlbook.org/html/ch15_04.html";>"Chapter 15.4 - Perl +href="http://modperlbook.org/html/ch15_04.html";>Chapter 15.4 - Perl Build Options" from http://modperlbook.org/";>Practical mod_perl. @@ -721,16 +721,13 @@ Some distributions (notably Debian) have chosen to put F and F into the global library loader path (e.g., F) which will cause linking problems when compiling mod_perl -(if compiling against static perl), in which case you should move aside +(if compiling against static perl), in which case you hould move aside the F while building mod_perl or else will likely encounter further errors. If building against the dynamic perl's F, you may have similar problems but at startup time. It's the best to get rid of perl that installs its libs into F (or similar) and reinstall a new perl, which puts its library under the perl tree. -=for html Also see http://perl.apache.org/docs/1.0/guide/install.html#libperl_so_and_libperl_a";>libperl.so -and libperl.a. -- 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: [mp1] Linking confusion
Thanks for the clear explanation of *.a and *.so files, Stas. I'm starting to grok how it works together. I've attached the diff to the install docs to this message which incorporates some of your notes about .so and .a files. I found this information hard to find while browsing Google, Perlmonks and the modperl docs. I hope that you will include them in some form. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com --- /tmp/install.pod.orig 2004-12-31 10:04:39.0 -0500 +++ /tmp/install.pod.wlm2004-12-31 11:58:30.0 -0500 @@ -681,9 +681,38 @@ mod_perl.o(.text+0x13b): undefined reference to `Perl_av_undef' [more errors snipped] -This happens when you have Perl built statically linked, with no -shared I. Build a dynamically linked Perl (with -I) and the problem will disappear. +This happens when you have perl built statically linked, with no +shared I library. Build a dynamically linked perl (with +I) and the problem will disappear. See the "Building a shared Perl +library" section from the I file that comes with Perl sources. Also +see L<"Chapter 15.4 - Perl Build +Options"|http://modperlbook.org/html/ch15_04.html> from I. + +=head4 Further notes on libperl.(a|so) + +Library files such as I are archives that are used at linking time - +these files are completely included in the final application that linked it. + +I is a shared library. At the linking time the application only +knows which library it wants. Only at the loading time (runtime) that +library will be loaded. + +One of the benefits of using a shared library, is that it's loaded only once, +any application using the same library will not need load it, it'll be shared +(a service provided by the kernel). In the case of static I, it'll be +loaded as many times as there are applications that included it, thus consuming +more memory. Of course this is not the only benefit of using shared libs. + +In mod_perl1, the library file is unfortunately named libperl.(so|a). So you +have libperl.(so|a) which is perl, and you have libperl.(so|a) which is +modperl. You are certainly looking at the modperl version of libperl.a if you +find it in the apache directory. perl's libperl.(so|a) lives under something +like 5.8.6/i686-linux/CORE/. + +Some distributions (notably Debian) have chosen to put libperl.so into the +library path (e.g., /usr/lib) which will cause linking problems when compiling +mod_perl. You should delete or move aside the libperl.so while building +mod_perl or else will likely encounter further errors. =head2 mod_perl Building (make) -- 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: [mp1] Linking confusion
On Thu, Dec 30, 2004 at 05:57:07PM -0500, Stas Bekman wrote: > >During compilation of mod_perl, I was seeing undefined reference errors > >which are nicely described on the install page[1]. The prescription > >suggests rebuilding Perl with dynamic linking; apparently the version > >that's shipped with Debian is not dynamically linked(?). Sounds fine, > >but I'm not a C programmer so am not sure exactly what this means. > > Now that you know what does it take, please send a patch that extends [1] > to explain how to do that. I've started working on a patch for the install doc[1] but have come across a couple of questions that I'm sure someone on the list could answer for me. 1) The docs refer to building a "dynamically linked Perl." Shouldn't the Perl be lowercase since we're talking about the interpreter, not the language? 2) In the same sentence, it says that a dynamically linked perl will have a libperl.a. Isn't that a libperl.so? Could someone describe the differences between libperl.a and libperl.so? I see that it exists in the apache source directory which makes me think it is used when building modperl. If I'm building mp statically linked, I shouldn't need libperl.a after I've installed, right? Is this the library that has been more appropriately named modperl.a in MP2? Cheers! William [1] http://perl.apache.org/docs/1.0/guide/install.html#Undefined_reference_to__PL_perl_destruct_level_ -- Knowmad Services Inc. http://www.knowmad.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: [mp1] Linking confusion
On Thu, Dec 30, 2004 at 07:32:19PM -0500, Stas Bekman wrote: > >Hmm, that's what I thought too and was creating a symlink from > >/usr/lib/libperl.so to the newly created one. I was still getting > >strange behavior though so moved them all out of /usr/lib. Seems a bit > >better now. > > If the application links against a specific libperl.so.x.y that would > explain that behavior. And ldd is the best tool to use to check the links (at least on Unix)? William -- Knowmad Services Inc. http://www.knowmad.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: [mp1] Linking confusion
On Thu, Dec 30, 2004 at 07:00:36PM -0500, Stas Bekman wrote: > >I'm guessing that this goes for any libperl.so, e.g. libperl.so.5.6 or > >libperl.so.5.8. If so then it would explain the weird behavior that I've > >been getting when compiling mod_perl. > > Normally in addition to libperl.so.5.8 there will be a symlink to > libperl.so. Applications normally link against .so and not .so.x.y, so an > upgrade of that library will be possible w/o requiring the compilation of > the former. Hmm, that's what I thought too and was creating a symlink from /usr/lib/libperl.so to the newly created one. I was still getting strange behavior though so moved them all out of /usr/lib. Seems a bit better now. Thanks, William -- Knowmad Services Inc. http://www.knowmad.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: [mp1] Linking confusion
On Thu, Dec 30, 2004 at 05:57:07PM -0500, Stas Bekman wrote: > As [2] explains you have more than one libperl.so and the wrong one gets > loaded. libperl.so should *not* be in /usr/lib or any other globally seen > loader path if you want to have more than one perl on the same system. > Unfortunately some distros don't get it and install libperl.(so|a) into > /usr/lib :( I'm guessing that this goes for any libperl.so, e.g. libperl.so.5.6 or libperl.so.5.8. If so then it would explain the weird behavior that I've been getting when compiling mod_perl. Thanks, William -- Knowmad Services Inc. http://www.knowmad.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
[mp1] Linking confusion
Hi folks, I'm trying to recompile Perl and Apache/mod_perl on a Debian Sarge system using the following versions: Perl 5.8.6 Apache 1.3.33 mod_perl 1.29 I am compiling mod_perl statically (using Apachetoolbox) with the following options: APACHE_PREFIX=/usr/local/apache APACHE_SRC=/usr/local/src/Apachetoolbox-1.5.72/apache_1.3.33/src SSL_BASE= APACI_ARGS='--enable-module=rewrite' DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 During compilation of mod_perl, I was seeing undefined reference errors which are nicely described on the install page[1]. The prescription suggests rebuilding Perl with dynamic linking; apparently the version that's shipped with Debian is not dynamically linked(?). Sounds fine, but I'm not a C programmer so am not sure exactly what this means. >From what I could find reading the INSTALL document that comes with the Perl source, I need to recompile with the -Duseshrplib compile-time option. My understanding is that this option will build a libperl.so file. Is this correct? Am I taking the right action to build a dynamic Perl? With that option, I am able to compile Apache with mod_perl. Now though, when starting the newly compiled server, I'm receiving relocation errors which appear to be due to multiple versions of libperl.so/libperl.a (not sure which). While browsing the net for possible solutions, I came across the troubleshooting document[2]. It seems to say that if 'perl -V:useshrplib' returns true, then Perl is statically linked. Is this correct? It seems opposite of what I'd expect from reading the INSTALL document. I'm pretty much at wits end as to why I'm receiving relocation errors. The best I can figure is some kind of binary incompatibility between the version of Perl that I've compiled and previously compiled libraries. I've tried reinstalling some of the XS modules such as DBI which seems to clear up these errors. Any other suggestions or pointers, esp. in light of the differences between dynamic and static linking and libperl.so/libperl.a, would be much appreciated. Thanks, William [1] http://perl.apache.org/docs/1.0/guide/install.html#Undefined_reference_to__PL_perl_destruct_level_ [2] http://perl.apache.org/docs/1.0/guide/troubleshooting.html#_relocation_errors__or__undefined_symbol_ -- Knowmad Services Inc. http://www.knowmad.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::Test question
On Thu, Dec 16, 2004 at 11:28:42AM -0500, Stas Bekman wrote:
> Right, because as you've figured out t/conf/apache_test_config.pm is a
> cached version of the the test setup data. So you need to do a cleanup
> before reconfiguring things so that file gets updated. Note that you
> perform things A-T has no top-level support for at the moment. Since your
> hack uses internal APIs it can break any moment if things change. So it's
> important to provide a public API for this kind of purposes.
Hi Torsten,
This is an interesting approach you are using. I have opted for creating
a virtual server in my extra.conf.in config file called 'ssl' which
turns on mod_ssl in order to do my tests which require an ssl
connection. When I want to use the SSL connection in a request test, I
do the following:
my $config = Apache::Test::config();
Apache::TestRequest::module('ssl');
my $hostport = Apache::TestRequest::hostport();
I suppose this would not work for the automatically built response tests
which use the default port.
William
--
Knowmad Services Inc.
http://www.knowmad.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: why AuthenNTLM prompt for password/user when user in domain
Hi, Thanks for your reply. then user/password will promt user/password for the first time accessing the page even though user logined, am i right? Do i need a samba server in apache which use the AuthenNTLM. And how do i know the the user/usernthash is right between the apache and PDC? Since my problem is whatever i enter in the user/password prompt, it always says wrong password(rc=3). thanks, william Shannon Eric Peevey wrote: william lai wrote: *Hi speeves, i'm trying Apache::AuthenNTLM 2.07 modules with a NT PDC, mod_perl-1.19_12, Apache/2.0.51., After Hi! Just a note, the newest version of mod_perl is 1.99_17, and Apache 2.0.51 had a security hole that is fixed in 2.0.52. (Though I have been seeing a mention of a new vulnerability in 2.0.52 on bugtraq, though haven't seen it confirmed yet). configuration, i browsers the page that protect by AuthenNTLM and it prompt me for password/user, however it always said the user/passwordis wrong. is it true that NTLM don't need to enter password/user when user login in the domain? **and i also set keepalive= on in httpd.conf. I have searched for a week why it prompt me for password/user, but stil can't solve. * If I am understanding this correctly, AuthenNTLM doesn't check for existing credentials from IE. It simply checks a local cache to see if the user already has a session, then throws a 401 Unauthorized if a cached session is not found. thanks, -- 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
why AuthenNTLM prompt for password/user when user in domain
*Hi speeves,
i'm trying Apache::AuthenNTLM 2.07 modules with a
NT PDC, mod_perl-1.19_12, Apache/2.0.51., After
configuration, i browsers the page that protect by AuthenNTLM and it prompt me
for password/user, however it always said the user/passwordis wrong.
is it true that NTLM don't need to enter password/user when user login in the
domain?
**and i also set keepalive= on in httpd.conf. I have
searched for a week why it prompt me for password/user, but
stil can't solve.
*
*Do you know what's wrong with my setup?
Here is my .htaccess config:
**
PerlAuthenHandler Apache::AuthenNTLM
AuthName "NTLM Test"
AuthType ntlm
PerlAddVar ntdomain "mypdc.com my-pdc"
PerlSetVar defaultdomain mrppdc.com
PerlSetVar ntlmdebug 2
PerlSetVar splitdomainprefix 1
PerlSetVar ntlmsemtimeout 2
require valid-user
Here is the log detail.
[[26627] AuthenNTLM: Config Domain = mrppdc.com pdc =
mrp-pdc bdc =
[26627] AuthenNTLM: Config Default Domain = mrppdc.com
[26627] AuthenNTLM: Config Fallback Domain =
[26627] AuthenNTLM: Config AuthType = ntlm AuthName =
NTLM Test
[26627] AuthenNTLM: Config Auth NTLM = 1 Auth Basic =
0
[26627] AuthenNTLM: Config NTLMAuthoritative = on
BasicAuthoritative = on
[26627] AuthenNTLM: Config Semaphore key = 23754
timeout = 2
[26627] AuthenNTLM: Config SplitDomainPrefix = 1
[26627] AuthenNTLM: Authorization Header
[Wed Nov 24 00:48:18 2004] [error] Bad/Missing
NTLM/Basic Authorization Header for /test/test.html
[26627] AuthenNTLM: Start NTLM Authen handler pid =
26627, connection = 159651528 conn_http_hdr =
Keep-Alive main = cuser = remote_ip = 192.168.59.59
remote_port = remote_host = < > version = 2.07
[26627] AuthenNTLM: Object exists user = \
[26627] AuthenNTLM: Authorization Header NTLM
TlRMTVNTUAABB4IIoAB=
[26627] AuthenNTLM: Got: 78 84 76 77 83 83 80 0 1 0 0
0 7 130 8 160 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
[26627] AuthenNTLM: protocol=NTLMSSP, type=1,
flags1=7(NEGOTIATE_UNICODE,NEGOTIATE_OEM,REQUEST_TARGET),
flags2=130(NEGOTIATE_ALWAYS_SIGN,NEGOTIATE_NTLM),
domain length=0, domain offset=0, host length=0, host
offset=0, host=, domain=
[26627] AuthenNTLM: Connect to pdc = mrp-pdc bdc =
domain = mrppdc.com
[26627] AuthenNTLM: enter lock
[26627] AuthenNTLM: verify handle
[26627] AuthenNTLM: Send: 78 84 76 77 83 83 80 0 2 0 0
0 0 0 0 0 40 0 0 0 1 130 0 0 240 218 235 184 85 9 246
208 0 0 0 0 0 0 0 0
[26627] AuthenNTLM: charencoding = 1
[26627] AuthenNTLM: flags2 = 130
[26627] AuthenNTLM:
nonce=U
[26627] AuthenNTLM: Send header: NTLM
TlRMTVNTUAACACgBggAA8NrruFUJ9t==
[26627] AuthenNTLM: Start NTLM Authen handler pid =
26627, connection = 159651528 conn_http_hdr =
Keep-Alive main = cuser = remote_ip = 192.168.59.59
remote_port = remote_host = < > version = 2.07
[26627] AuthenNTLM: Object exists user = \
[26627] AuthenNTLM: Authorization Header NTLM
TlRMTVNTUAADGAAYAHIYABgAigAAABQAFABADgAOAFQQABAAYgCiBYIAAG0AcgBwAHAAZABjAC4AYwBvAG0AdwBpAGwAbABpAGEAbQBVAE4ASQBGAE8AUgBDAEUAPhTzJwLTwxsz7ARKvDGplLe7aojbl5LXnRmAu7tZvXtgZvUWM9eVEz6f/oUg/E9P
[26627] AuthenNTLM: Got: 78 84 76 77 83 83 80 0 3 0 0
0 24 0 24 0 114 0 0 0 24 0 24 0 138 0 0 0 20 0 20 0 64
0 0 0 14 0 14 0 84 0 0 0 16 0 16 0 98 0 0 0 0 0 0 0
162 0 0 0 5 130 0 0 109 0 114 0 112 0 112 0 100 0 99 0
46 0 99 0 111 0 109 0 119 0 105 0 108 0 108 0 105 0 97
0 109 0 85 0 78 0 73 0 70 0 79 0 82 0 67 0 69 0 62 20
243 39 2 211 195 27 51 236 4 74 188 49 169 148 183 187
106 136 219 151 146 215 157 25 128 187 187 89 189 123
96 102 245 22 51 215 149 19 62 159 254 133 32 252 79
79
[26627] AuthenNTLM: protocol=NTLMSSP, type=3,
user=william, host=UNIFORCE, domain=mrppdc.com,
msg_len=0
[26627] handler type == 3
[26627] AuthenNTLM: Verify user william via smb server
[26627] AuthenNTLM: NTLM for william,
ïïïïYï{`fï3×>ïïï
ïOO , via smb server
[26627] AuthenNTLM: leave lock
here is the
error>>>>>>>>>>>>>>>>>>>>
[Wed Nov 24 00:48:21 2004] [error] Wrong password/user
(rc=3/1/327681): mrppdc.com\\william for
/test/test.html
[26627] AuthenNTLM: rc = 3 ntlmhash =
ïïïïYï{`fï3×>ïïï
*
thanks,
william lai*
--
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: SV: Moving STDOUT to a new handle?
On Mon, Nov 08, 2004 at 07:17:21PM +0100, Arne Skjaerholt wrote: > And, as I think of it, I don't think it'd be terribly useful as > CGI::Application is intended for use with CGI scripts, not mod_perl > handlers. This is not true. Several folks on the C::A list, including myself, are using it in conjunction with mod_perl. In fact, Michael Peters has just released a plugin to make it even more mod_perl friendly (including the use of Apache::* modules rather than CGI.pm). However, I agree that it does not provide a technical solution to your problem. William -- Knowmad Services Inc. http://www.knowmad.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: Mod perl performance and DSO?
On Wed, Oct 13, 2004 at 12:46:19PM +0100, Martin Moss wrote: > Hmmm, I'm a little concerned that using DSO does have > a performance hit for no real benefit for what we wish > to do. Hmm, now just need to find instructions on > building apache with mod_ssl, mod_perl and mod_php? > without using DSO, any ideas? (whilst I'm off to > google...) Yes, that's been my decision as well. I still don't know what version of Apache you are using, but if it's 1.x, then you may want to try Apachetoolbox[1]. I use it to compile mod_perl and mod_ssl. However, I have not tried to compile mod_php along with mod_perl. There is a pretty good online forum which you could turn to if you hit any snags. Let me know how it turns out; I may need to do this myself one day. Good luck, William [1] http://www.apachetoolbox.com/ -- Knowmad Services Inc. http://www.knowmad.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: Mod perl performance and DSO?
On Tue, Oct 12, 2004 at 05:06:18PM +0100, Martin Moss wrote: > Most information I find on the web to do this uses > DSO. Performance is absolutely critical for this > machine, it's going to be handling millions of web > 'hits' per day. > > My question is, should we use DSO or not? > My second question is, is this a daft question? You didn't mention what version of Apache you were using but try this url for a starter: http://perl.apache.org/docs/1.0/guide/install.html#Pros_and_Cons_of_Building_mod_perl_as_DSO You can answer the 2nd question for yourself after you read the above :). William -- Knowmad Services Inc. http://www.knowmad.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] & Apache2: undefined symbol: PL_localizing
Hi Pierre, You're in the right place. I run Apache with Debian and have had troubles in the past with compiling mod_perl due to having two copies of libperl.so[1]; I think this would more likely be the case if you have compiled Perl yourself. William [1] http://mathforum.org/epigone/modperl/percroogrum/[EMAIL PROTECTED] -- Knowmad Services Inc. http://www.knowmad.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: perl modules not running after 'minor' change
On Mon, Sep 06, 2004 at 03:31:51PM -0700, Ben Hopkins wrote: > Here's the error log entries: > [Mon Sep 6 15:21:44 2004] [error] [client 4.42.113.186] File does not > exist: /usr/local/apache/htdocs/server-status > [Mon Sep 6 15:22:03 2004] [error] [client 4.42.113.186] File does not > exist: /usr/local/apache/htdocs/server-info What about /perl-status? You didn't show us the def'n for /server-info. Those log entries make me wonder if Apache is reading the configuration file the way that you think it is. You may want to change the Locations to contain the same directives as one of your working Locations. I don't know how the server-status handler is implemented but are you sure that you have Apache::Status installed on your server? Have you perhaps upgraded Perl and not reinstalled this module? William -- Knowmad Services Inc. http://www.knowmad.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: perl modules not running after 'minor' change
On Sat, Sep 04, 2004 at 12:56:26PM -0700, Ben Hopkins wrote: > I got FORBIDDEN errors until I put my IP addr (I'm working on a remote > server). Then I got 404s. The directives look similar to mine. Is there no message in the Apache error logs that gives you a hint of what's wrong with your system? William -- Knowmad Services Inc. http://www.knowmad.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: perl modules not running after 'minor' change
On Fri, Sep 03, 2004 at 10:47:37PM -0700, Ben Hopkins wrote: > THAT DID IT! I commented perl's LoadModule, restarted, and VIOLA, > every thing's back to normal. Hey Ben, I'm glad that Rici was able to help you. > The very odd thing is that there are no errors in the build, or in > apache's logs or when it tries to run a module. What kind of error are you expecting? Perhaps mod_perl does not mind two versions being loaded although it would seem that issuing the LoadModule statement would trigger a warning message if mod_perl was compiled in. > And I still get 404s for /perl-status and /server-status. That sounds like a problem. What's in your error logs? What are your configurations for these sections. William -- Knowmad Services Inc. http://www.knowmad.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: perl modules not running after 'minor' change
On Thu, Sep 02, 2004 at 08:51:15PM -0700, Ben Hopkins wrote: > Nope. There are two copies of libperl.so: one in the apache source > tree, and one in libexec. > > BUT that link said to use ldd to see what libperl.so is referenced in > the httpd executable. I did that and found NO reference to libperl.so! Hmm, that sounds bad. I wonder if having two copies is somehow throwing off the compilation. Unfortunately, this is outside of my experience, and it appears Stas is unavailable. I'd suggest digging through the archives searching for posts regarding libperl.so. It comes up every now and then and usu. takes a few postings to get it figured out. Good luck, William -- Knowmad Services Inc. http://www.knowmad.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: Help with PERL5LIB
Hi Brett, This question appears to have nothing to do with modperl. I'd suggest you try the beginners mailing list. You can sign up at http://learn.perl.org. William -- Knowmad Services Inc. http://www.knowmad.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: [bug] Apache::FakeRequest::content_languages
On Thu, Sep 02, 2004 at 08:03:01AM -0400, Geoffrey Young wrote: > you could do both - test-driven development. personally, I don't know how I > ever got along without Apache-Test, for both development and debugging. how > I wrote applications before seemed insane when compared to using the tools > we now have available. +1. A::T has helped me to write my code, to catch errors that I've introduced while adding new features, and to do code refactoring (which I've done quite a bit of as I learn to use Class::DBI). It took me awhile to get the gist of it (as you can read if you look back in the docs-dev mailling list) but it was worth the effort. Start with Geoff's article and skeleton; you'll avoid many of the potholes I hit along the way. William -- Knowmad Services Inc. http://www.knowmad.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: perl modules not running after 'minor' change
Hi Ben, Sorry to hear about the hair loss and damage to your walls. I'm starting to think that you may be running into a problem that I've hit before--having an extra libperl.so laying around. Check out this thread between Stas and myself for more info[1]. I've given you the link to the last message. You should be able to follow it back til you find some useful testing tips. Good luck, William [1] http://mathforum.org/epigone/modperl/percroogrum/[EMAIL PROTECTED] -- Knowmad Services Inc. http://www.knowmad.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: perl modules not running after 'minor' change
On Tue, Aug 31, 2004 at 08:41:10PM -0700, Ben Hopkins wrote: > 2: I added /perl-status and got a 404 error, just like I get for > /server-status, /server-info, and /howdy locations. _It's exactly as if > mod_perl were not installed!_ > > Wait a minute! It is exactly as if the "SetHandler" directive is always > ignored. (Which is why /server-status and /server-info do not work.) I > don't remember if they worked before this. Is it possible that I forgot > something that implements SetHandler??? According to your OP, PERL_HANDLER is enabled. I think that you are right; mod_perl is not properly installed. Have you tried building without mod_proxy to see if it works? Unfortunately, I can't be of much further help. I use ApacheToolbox to build my Apache httpd and do not know enough about APACI et al. to offer further advice. Good luck, William -- Knowmad Services Inc. http://www.knowmad.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: perl modules not running after 'minor' change
On Mon, Aug 30, 2004 at 09:51:14PM -0700, Ben Hopkins wrote: > I'm running RH 8, apache 1.3.23, mod_perl 1.29. Hi Ben, Have you tried compiling with a newer version of Apache? It's up to release 1.3.31 now. I'm pretty sure that mod_perl 1.29 was released several months after the release of Apache that you are building. Is it possible there is a mismatch? Have you tried adding /perl-status[1]? Good luck, William [1] http://perl.apache.org/docs/1.0/guide/install.html#Testing_by_viewing__perl_status -- Knowmad Services Inc. http://www.knowmad.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: make test hangs
I understand. I've already appealed to a perl.HPUX list to no avail. I've only been dealing with HP-UX myself for about a year now (mostly Linux and Solaris before this). I agree though. This is most likely not a problem with mod_perl itself, but rather some interaction with perl 5.6 and HP-UX. I may return with other questions if I decide to pursue the non LFS install (which at least completes the make test with failed tests rather than hanging). I will post the particulars if I ever track down this particular bugaboo. Thanks for your time. --- Will Fulmer Database Administrator Northampton Community College Bethlehem, PA >>> Stas Bekman <[EMAIL PROTECTED]> 8/12/2004 3:32:49 PM >>> William Fulmer wrote: > I did find some discussion of old HP-UX patches that fixed problems with > stat calls that some of HP's apps had. There are no particulars and > none pertain to system libraries, so they were no help. The issue here > may be that I'm a relative novice when it comes to C/C++ programming. > For instance, where does the magic happen that masks all of perls stat > calls to stat64 when you compile with LFS support? Some of the info out > there may contain the answer, but I can't see it for lack of this > knowledge. It happens during Perl compilation, where depending on compilation flags, either stat or stat64 is chosen. > I'm also wondering if the problem is not the actually call to stat64, > which looks like it returns the requested info, but whatever comes next. > That last line of the trace bothers me: > > [5889] In > user-mode.[running] > > Very uninformative. Any guesses as to the meaning? Not really. > One of the other things that has been bothering me is that when I built > MP2 with perl 5.8.2, I couldn't get it to work without useshrlib > defined. For perl 5.6.2, perl won't even compile successfully if you > define this option. It tries to run miniperl during the compile and > that hangs with a trace ending in the same mysterious line. The > frustration thing about that is that LFS does not seem to affect this > particular problem. I'm left wondering if perhaps the real problem here > is that these two scenarios are trying to dynamically load libraries > that don't lend themselves to dynamic loading (e.g. libpthread.sl) I > eliminated the usual culprits such as pthread and libcl.sl and of course > there are no helpful messages to point at something else. > > I do see warnings about a symbol _attribute_ being defined again and > internal linking will occur, but as I said before, I don't know enough > about C to know if that has any significance at all. > > Any thought on these? All I can say that these aren't really mod_perl problems per se, even though they prevent you from using mod_perl. They are all OS level issues. You need to find someone who groks your platform's specifics and can advise us on using the right compile/linking flags to get things working. HP-UX is not the only platform mod_perl has a problem with. We have issues with AIX and other platforms. We have Randy Kobes and Steve Hay who do a great work handling the win32 build (which won't be possible w/o having an inhouse expert). The rest of us develop and familiar with Linux. We get random help for other platforms. Ideally what we need is to have an expert on those platforms Apache and Perl are running on to get mod_perl to run. I apologize for not being much of help with the problems you are having, William. -- __ 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: make test hangs
I did find some discussion of old HP-UX patches that fixed problems with
stat calls that some of HP's apps had. There are no particulars and
none pertain to system libraries, so they were no help. The issue here
may be that I'm a relative novice when it comes to C/C++ programming.
For instance, where does the magic happen that masks all of perls stat
calls to stat64 when you compile with LFS support? Some of the info out
there may contain the answer, but I can't see it for lack of this
knowledge.
I'm also wondering if the problem is not the actually call to stat64,
which looks like it returns the requested info, but whatever comes next.
That last line of the trace bothers me:
[5889] In
user-mode.[running]
Very uninformative. Any guesses as to the meaning?
One of the other things that has been bothering me is that when I built
MP2 with perl 5.8.2, I couldn't get it to work without useshrlib
defined. For perl 5.6.2, perl won't even compile successfully if you
define this option. It tries to run miniperl during the compile and
that hangs with a trace ending in the same mysterious line. The
frustration thing about that is that LFS does not seem to affect this
particular problem. I'm left wondering if perhaps the real problem here
is that these two scenarios are trying to dynamically load libraries
that don't lend themselves to dynamic loading (e.g. libpthread.sl) I
eliminated the usual culprits such as pthread and libcl.sl and of course
there are no helpful messages to point at something else.
I do see warnings about a symbol _attribute_ being defined again and
internal linking will occur, but as I said before, I don't know enough
about C to know if that has any significance at all.
Any thought on these?
---
Will Fulmer
Database Administrator
Northampton Community College
Bethlehem, PA
>>> Stas Bekman <[EMAIL PROTECTED]> 8/11/2004 10:29:05 PM >>>
William Fulmer wrote:
> We need to back up a bit. I tried something different just for
giggles
> because I thought we might be on the wrong track with setuid. I
wrote a
> little script that this
>
> #!/bin/bash
> /usr/opt/httpd-2.0.49/bin/httpd -d t -f conf/httpd.conf -DAPACHE2
> -DONE_PROCESS -DNO_DETATCH > stdout 2>&1 &
> tusc -p -f -v -o strace $!
>
> after running the script I went to a browser and hit
> http://cars-l:8529/TestAPI__request_rec
>
> The strace looks quite different this way (and the process does not
> exit). Turns out the setuid thing was the falt of my tusc command
being
> setuid. (Sorry. insert sheepish look here)
>
> Trace from this latest test is more what I expected to see:
[...]
>
stat64("/opt/local/wrfopt/build/mod_perl-1.99_14/t/response/TestAPI/request_rec.pm",
> 0x6ff66648) = 0
> st_dev: 64 0x05
> st_ino: 171526
>st_mode: S_IFREG|0644
> st_nlink: 1
>st_rdev: 0
>st_size: 2503
> st_blksize: 8192
> st_blocks: 1
> st_uid: 1073741829
> st_gid: 27549760
> st_atime: Tue Aug 10 16:50:28 2004
> st_mtime: Fri Apr 18 02:18:58 2003
> st_ctime: Mon Aug 9 20:40:52 2004
> Hangs at this point.
>
> The compile with no LFS:
[...]
> Blows right by the call to stat no problem. Get output in the
browser
> say Ok to all 42 tests.
>
> The only notable difference being the call to stat as opposed to
> stat64.
Excellent. So you've almost nailed it, William! Now try to see if there
are any discussions on the web re: stat vs. stat64, e.g.:
http://www.google.ca/search?hl=fr&ie=UTF-8&q=stat+stat64+hangs&btnG=Rechercher&meta=
may be some more keywords should be added, like your platform name...
--
__
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: make test hangs
We need to back up a bit. I tried something different just for giggles
because I thought we might be on the wrong track with setuid. I wrote a
little script that this
#!/bin/bash
/usr/opt/httpd-2.0.49/bin/httpd -d t -f conf/httpd.conf -DAPACHE2
-DONE_PROCESS -DNO_DETATCH > stdout 2>&1 &
tusc -p -f -v -o strace $!
after running the script I went to a browser and hit
http://cars-l:8529/TestAPI__request_rec
The strace looks quite different this way (and the process does not
exit). Turns out the setuid thing was the falt of my tusc command being
setuid. (Sorry. insert sheepish look here)
Trace from this latest test is more what I expected to see:
[5889] writev(72, 0x6fff1940, 3)
=
40
iov_base[0]: 0x6fff1838
iov_len[0]: 4
iov_base[1]: 0x40cfeebc
iov_len[1]: 34
iov_base[2]: 0x7fb78
iov_len[2]: 2
[5889] writev(72, 0x6fff1940, 3)
=
40
iov_base[0]: 0x6fff1838
iov_len[0]: 4
iov_base[1]: 0x40cfeebc
iov_len[1]: 34
iov_base[2]: 0x7fb78
iov_len[2]: 2
[5889] writev(72, 0x6fff1940, 3)
=
11
iov_base[0]: 0x6fff1838
iov_len[0]: 3
iov_base[1]: 0x40cfeebc
iov_len[1]: 6
iov_base[2]: 0x7fb78
iov_len[2]: 2
[5889]
stat64("/opt/local/wrfopt/build/mod_perl-1.99_14/t/response/TestAPI/request_rec.pm",
0x6ff66648) = 0
st_dev: 64 0x05
st_ino: 171526
st_mode: S_IFREG|0644
st_nlink: 1
st_rdev: 0
st_size: 2503
st_blksize: 8192
st_blocks: 1
st_uid: 1073741829
st_gid: 27549760
st_atime: Tue Aug 10 16:50:28 2004
st_mtime: Fri Apr 18 02:18:58 2003
st_ctime: Mon Aug 9 20:40:52 2004
[5889] In user-mode
.
[running]
Hangs at this point.
The compile with no LFS:
[14273] writev(72, 0x6fff1940, 3)
..
. = 11
iov_base[0]: 0x6fff1838
iov_len[0]: 3
iov_base[1]: 0x4105eb74
iov_len[1]: 6
iov_base[2]: 0x7fb78
iov_len[2]: 2
[14273]
stat("/opt/local/wrfopt/build/mod_perl-1.99_14/t/response/TestAPI/reques
t_rec.pm", 0x6ff665f0) = 0
st_dev: 64 0x05
st_ino: 172780
st_mode: S_IFREG|0644
st_nlink: 1
st_rdev: 0
st_size: 2503
st_blksize: 8192
st_blocks: 8
st_uid: 1062
st_gid: 1062
st_atime: Tue Aug 10 17:11:49 2004
st_mtime: Fri Apr 18 02:18:58 2003
st_ctime: Mon Aug 9 20:40:25 2004
[14273] writev(72, 0x6fff1940, 3)
..
. = 11
iov_base[0]: 0x6fff1838
iov_len[0]: 3
iov_base[1]: 0x4105eb74
iov_len[1]: 6
iov_base[2]: 0x7fb78
iov_len[2]: 2
Blows right by the call to stat no problem. Get output in the browser
say Ok to all 42 tests.
The only notable difference being the call to stat as opposed to
stat64.
---
Will Fulmer
Database Administrator
Northampton Community College
Bethlehem, PA
>>> "William Fulmer" <[EMAIL PROTECTED]> 8/10/2004 9:33:50 AM
>>>
I have a non root user that I use for all of my software builds
(called
build strangely enough). All elements (apache, perl, mod_perl) were
built as this user. I just tried building as root as the email
suggested. It would not run apache as root, but tried to use
nobody(which did not work no matter how wide I ripped the permissions).
I forced it to run as the user that my webserver nomrally runs as by
setting APACHE_TEST_USER and APACHE_TEST_GROUP. Then the test hangs
as
before.
I never got this message:
waiting for server to start: .No -M all
Re: make test hangs
I have a non root user that I use for all of my software builds (called
build strangely enough). All elements (apache, perl, mod_perl) were
built as this user. I just tried building as root as the email
suggested. It would not run apache as root, but tried to use
nobody(which did not work no matter how wide I ripped the permissions).
I forced it to run as the user that my webserver nomrally runs as by
setting APACHE_TEST_USER and APACHE_TEST_GROUP. Then the test hangs as
before.
I never got this message:
waiting for server to start: .No -M allowed while running setuid.
perl_parse: Address family not supported by protocol
!!!
The server always started successfully.
My perl is not configure to emulate setuid/setgid either.
Does perl 5.6 handle the setuid differently then 5.8?
Also, I'm confuse, does -M bypass the setuid code while stat get's
caught?
Shouldn't they both hang during make test?
My perl.c code looks like this:
STATIC void
S_forbid_setid(pTHX_ char *s)
{
if (PL_euid != PL_uid)
Perl_croak(aTHX_ "No %s allowed while running setuid", s);
if (PL_egid != PL_gid)
Perl_croak(aTHX_ "No %s allowed while running setgid", s);
}
So I changed it to never croak just for some smiles:
STATIC void
S_forbid_setid(pTHX_ char *s)
{
if (1 != 1)
Perl_croak(aTHX_ "No %s allowed while running setuid", s);
if (1 != 1)
Perl_croak(aTHX_ "No %s allowed while running setgid", s);
}
and make test still hangs.
---
Will Fulmer
Database Administrator
Northampton Community College
Bethlehem, PA
>>> Stas Bekman <[EMAIL PROTECTED]> 8/9/2004 2:05:48 PM >>>
William Fulmer wrote:
> Apologies. You are correct. I never responded directly to this
email.
>
> my $file = "/tmp";
> my $mtime = (stat $file)[9];
>
> and:
>
> my $file = __FILE__;
> my $mtime = (stat $file)[9];
>
> both fail (meaning the test hangs)
>
> -M __FILE__;
>
> and
>
> -M "/tmp";
>
> both work (which is to say that the test does not hang, but the test
> fails because stat returns number of seconds since the epoch and -M
> returns the number of days since last modification).
Right, but I think both perform stat(). I went back to your strace
message, which had:
write(2, "N o - M a l l o w e d w h ".., 36)
. = 36
with some googling I've found:
http://marc.theaimsgroup.com/?l=apache-modperl&m=104941790431878&w=2
which is talking about:
"waiting for server to start: .No -M allowed while running setuid.
perl_parse: Address family not supported by protocol
!!!
server has died with status 1 (please examine t/logs/error_log)
make: *** [run_tests] Error 143 "
Could that be your issue? Do you have setuid involved in your setup?
If you build mod_perl as root as Richard mentioned in the above URL, do
you get any difference?
the error is coming from perl.c:
STATIC void
S_forbid_setid(pTHX_ char *s)
{
#ifdef SETUID_SCRIPTS_ARE_SECURE_NOW
if (PL_euid != PL_uid)
Perl_croak(aTHX_ "No %s allowed while running setuid", s);
if (PL_egid != PL_gid)
Perl_croak(aTHX_ "No %s allowed while running setgid", s);
#endif /* SETUID_SCRIPTS_ARE_SECURE_NOW */
/* PSz 29 Feb 04
* Checks for UID/GID above "wrong": why disallow
* perl -e 'print "Hello\n"'
* from within setuid things?? Simply drop them: replaced by
* fdscript/suidscript and #ifdef IAMSUID checks below.
*
* This may be too late for command-line switches. Will catch
those on
* the #! line, after finding the script name and setting up
* fdscript/suidscript. Note that suidperl does not get around to
* parsing (and checking) the switches on the #! line, but checks
that
* the two sets are identical.
*
* With SETUID_SCRIPTS_ARE_SECURE_NOW, could we use fdscript, also
or
* instead, or would that be "too late"? (We never have
suidscript, can
* we be sure to have fdscript?)
*
* Catch things with suidscript (in descendant of suidperl), even
with
* right UID/GID. Was already checked in suidperl, with #ifdef
IAMSUID,
* below; but I am paranoid.
*
* Also see comments about root running a setuid script,
elsewhere.
*/
> Apache, perl and mod_perl where all compiled with HP's ANSI C
compiler.
> The compiler is now with the latest version and patch level. Also,
> will point out that this is now under HP-UX 11i (11.11) was formerly
> HP-UX 11.00. Not sure this matters since the symptom's of the
problem
> remain unchanged. When I first reported the problem I was on the eve
of
> upgrading the OS on the server I've been trying to get this working
on.
That's good.
--
___
