perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Caldwell <tom.caldw...@vanderbilt.edu>
Subject Re: [mp2] modperl2 compile error
Date Mon, 02 May 2005 22:24:33 GMT
Comments below.

On Sat, 2005-04-30 at 01:25, Stas Bekman wrote:
> Tom Caldwell wrote:
> > Stas,
> > 
> > I forgot to mention that apache usually runs under a different account
> > than nobody (I use - apache), in case that matters.
> 
> Of course. In which case you need to check 'apache' instead of 'nobody'.
> 
> > Also, I apologize for not cc'ing the list on the last message but I
> > normally use the mail client from my desktop machine instead of this
> > Ximian client on red hat and I am not used to the client not doing the
> > cc for me.
> 
> No worries.
> 
>  > Yes, I noticed that nobody was having trouble finding libperl.so, but it
>  > seemed very strange that none of the other tests failed.
>  >
>  > Anyway, I tried to
>  > su - nobody
>  > which failed because the shell was set to /sbin/nologin.
> 
> su - apache
> 
>  > So I fixed that (set shell to bash) and set the .bashrc file to set the
>  > LD_LIBRARY_PATH to
>  > /opt/perl/lib/5.8.6/x86_64-linux/CORE:/opt/apache2/server/lib/:/usr/lib64
>  > so it can find libperl.so
>  > /opt/perl/bin/perl -V then ran correctly from the nobody account.
>  >
>  > Then I reran the tests and got the same failures here is the test report
>  > (see below).
>  >
>  > Also, I was able to run the 4 scripts in t/htdocs/util - argv.pl
>  > env.pl  in_err.pl  in_out.pl
>  >
>  > They seemed to work fine except env.pl did not print anything.
>  >
>  > Thanks for looking into this,
>  >
>  > Tom
>  >
>  > P.S. Here is the other info you asked for.
>  >
>  > First line of t/TEST is
>  > #!/opt/perl/bin/perl
>  >
>  > ldd /opt/perl/bin/perl
>  >         libperl.so => /opt/perl/lib/5.8.6/x86_64-linux/CORE/libperl.so
>  > (0x0000002a9566d000)

> is it possible that this path it not readable by user 'apache'? I doubt 
> so, since all other tests run just fine.
Well, the LD_LIBRARY_PATH gets set during the bash startup (.bashrc) so
if the test does > su - nobody    - then the variable should be set.

> 
> what if you change one of these scripts (.e.g. t/htdocs/argv.pl) to be:
( I take it you mean t/htdocs/util/argv.pl ?)
But these scripts aren't run during the test sequence. The tests that
are failing are coming out of t/response/TestApache/subprocess.pm (as
per t/logs/error_log) unless I'm missing something?

I use >t/TEST -verbose t/apache/subprocess.t     - as per
http://perl.apache.org/docs/2.0/user/help/help.html#_C_make_test___Failures
'make test' Failures  - to run the tests that are failing.

Is there another way to perform the tests so that the scripts in 
t/htdocs/util  are run instead?

Thanks,

Tom
> 

> #!/bin/sh
> 
> printenv > /tmp/dump
> ldd /opt/perl/bin/perl >> /tmp/dump
> 
> and run the subprocess test? This will show what the environment this 
> subprocess script is running under.


Mime
View raw message