make test fails / mod_perl doesn't work

[ralf . lehmann]

Hello list,
 
this is my first post on a mailing-list, so please pardon if I accidently
break some rules. Also Enlish isn't my native language but I try to give my
best...
 
My problem is, that I have a web-application based on perl-scripts. So far
everything is running (IBM-webserver based on Apache 2.0.47.1, Perl 5.8.2 ,
mySQL and that all on AIX5.3).
Because of performance reasons (response time) I have to add mod_perl to
this configuration.
 
I've tried with mod_perl 2.0.3 but so far without success. Step-by-Step what
I did:
 
[EMAIL PROTECTED]  :: ~/mod_perl-2.0.3 # perl 
Makefile.PL
MP_APXS=/usr/IBMIHS/bin/apxs MP_USE_DSO=1
I've also tried with additional "MP_APR_CONFIG=/usr/IBMIHS/bin/apr-config" 
This command returned a lot of output - the only negative things I've found
in it are the following two parts

   Unrecognized argument in LIBS ignored: '-Wld,-brtl'

[warning] mod_perl dso library will be built as mod_perl.so
[warning] You'll need to add the following to httpd.conf:
[warning] 
[warning]   LoadModule perl_module modules/mod_perl.so
[warning] 
[warning] depending on your build, mod_perl might not live in
[warning] the modules/ directory.
 
[warning] Check the results of
[warning] 
[warning]   $ /usr/IBMIHS/bin/apxs -q LIBEXECDIR
[warning] 
[warning] and adjust the LoadModule directive accordingly.

The named command returns "/usr/IBMIHS/modules" so that should be correct
 
 
 
next step: make
this returns about 4300 rows of output - most of them are

ld: 0711-415 WARNING: Symbol PerlIOBase_binmode is already exported.

just for lots of different "Symbols" (Modules?). The rest of the output
seems to be ok and because of "already exported" I ignored this
 
 
next step: 

[EMAIL PROTECTED]  : ~/mod_perl-2.0.3 # make test
cd "src/modules/perl" && make
Target "all" is up to date.
/usr/bin/perl -Iblib/arch -Iblib/lib  t/TEST -clean
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl /root/mod_perl-2.0.3/t/TEST -clean
APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT=
APACHE_TEST_USER= APACHE_TEST_APXS=  /usr/bin/perl -Iblib/arch -Iblib/lib
t/TEST -bugreport -verbose=0 
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl /root/mod_perl-2.0.3/t/TEST -bugreport
-verbose=0
exec(): 0509-036 Cannot load program /usr/IBMIHS/bin/httpd because of the
following errors:
0509-150   Dependent module libaprutil-0.so could not be loaded.
0509-022 Cannot load module libaprutil-0.so.
0509-026 System error: A file or directory in the path name does not
exist.
exec(): 0509-036 Cannot load program /usr/IBMIHS/bin/httpd because of the
following errors:
0509-150   Dependent module libaprutil-0.so could not be loaded.
0509-022 Cannot load module libaprutil-0.so.
0509-026 System error: A file or directory in the path name does not
exist.
exec(): 0509-036 Cannot load program /usr/IBMIHS/bin/httpd because of the
following errors:
0509-150   Dependent module libaprutil-0.so could not be loaded.
0509-022 Cannot load module libaprutil-0.so.
0509-026 System error: A file or directory in the path name does not
exist.
[  error] You are using mod_perl response handlers 
[  error] but do not have a mod_perl capable Apache.
++
| Please file a bug report: http://perl.apache.org/bugs/
  |
++
make: 1254-004 The error code from the last command is 1.

Stop.

 
 
A "make install" runs without warnings or errors. When I insert the line
"LoadModule perl_module modules/mod_perl.so" to the httpd.conf and I then
restart the webserver, then the following entries appear in the error_log:
[Thu Jan 18 13:06:19 2007] [notice] IBM_HTTP_Server/2.0.47.1 Apache/2.0.47
(Unix) mod_perl/2.0.3 Perl/v5.8.2 configured -- resuming normal operations
[Thu Jan 18 13:06:29 2007] [notice] child pid 790546 exit signal
Segmentation fault (11)
[Thu Jan 18 13:06:31 2007] [notice] child pid 786554 exit signal
Segmentation fault (11)

Then trying to open the web-application in my browser (which did fine before
restart) I just get an error-page that the server doesn't response. Same
when I additionally change the httpd.conf further the way I have to for my
web-app: set/change some "alias" and inserting:

  SetHandler  perl-script
  PerlHandler Apache::R

Re: Two failures in make test building mod_perl 2.0.3

[Geoffrey Young]

> -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)

> # testing : connection notes
> # expected: 127.0.0.1
> # received: 127.0.0.7
> not ok 1

this looks like it may be an IPv6 issue that's perhaps outside our
control...

the 'expected' part of this test is deduced by Apache-Test using
straight-up perl.

  $ perl -MSocket -e 'print
Socket::inet_ntoa((gethostbyname("localhost"))[-1])'

the 'received' part uses the value of $c->remote_ip, which is set in the
connection record by httpd (not mod_perl) using the APR abstraction layer.

I don't have a clue about IPv6 or how it works, but I suspect the issue
is the difference between perl's and apr's interpretation of localhost
on your machine.

maybe someone else has a clue.

--Geoff

Catching errors

[Jonathan Mangin]

I'm hitting a location on my server with:

http://zeppo/time?fname=Jonathan&lname=Mangin&foo=George


#use APR::Const -compile => qw(:common :error);
use APR::Const qw(:common :error);

sub handler {
   my $r = shift;
   my $req = Apache2::Request->new($r);
   my $foo;
#   eval {$foo = $req->param('foo')};
   $foo = $req->param('foo');
   my $args_error = $req->args_status();
   my $body_error = $req->body_status();
   my $param_error = $req->param_status();

Whether $foo is defined or not (using eval or not)
$args_error is always defined as 'Error 0' and 
the other two are 'Missing input data'.  How does
it know that input data is missing?  What am I doing
so wrong that I never get APR_SUCCESS?

Thanks,
Jon

Re: Session Handling/Set Session attributes

[Frank Wiles]

On Wed, 17 Jan 2007 16:11:17 -0800 (PST)
Tracy12 <[EMAIL PROTECTED]> wrote:

> 
> Well does this all mean there is limited features to do session
> handling on mod_perl. Well I am new to mod_perl but in JAVA/Servlet
> you can do a simple thing like this
>  
> request.getSession().setAttribute("my_remote_user", authenticated
> user>);
> for subsequent requests we can retrieve this attribute and do what we
> want. I expected similar session handleing feature availabe in
> mod_perl as this is a common requirement.

   This is essentially what Apache::Session does for you.  

 -
   Frank Wiles <[EMAIL PROTECTED]>
   http://www.wiles.org
 -

Re: Catching errors

[Robert Landrum]

Jonathan Mangin wrote:


sub handler {
   my $r = shift;
   my $req = Apache2::Request->new($r);
   my $foo;
#   eval {$foo = $req->param('foo')};
   $foo = $req->param('foo');


You might want to make sure $r is really $r.  If you configure apache 
such that you use PerlHandler Foo->handler, I believe the first argument 
is 'Foo', followed by $r.


Rob

Apache2::Request fouls up content length?

[craig]

I'm still hoping for a good answer on my previous build problem.
But for now I'm proceeding with testing using the mod_perl that
my hosting provider set up.

The first script that I've tested that uses Apache2::Request gives
a problem.  The browser sits and waits for its timeout period,
then the complete expected response is available.  My limited
experience suggests this is probably because the response's
content-length value is fouled up (or the header isn't sent?).

My "server signature" is
Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1  
mod_apreq2-20051231/2.5.7 mod_perl/2.0.2 Perl/v5.8.7 Server at  
mackenna1.securesites.net


OS is FreeBSD 6.  The problem happens under both http: and https:.

mod_deflate and mod_include are also active for the transaction.

Anyone can see the problem at
http://mackenna1.securesites.net/contact.html

which is the site's contact form.  If you just hit "send" without  
entering

anything, you'll get a response that says you didn't enter anything,
but it will take a long time.

Apache2::Request had bigger problems until I included the following
line in httpd.conf:
LoadModule apreq_module modules/mod_apreq2.so

That .so was also provided by my hosting provider (Verio).

Does this sound familiar?  Could it be avoided by newer versions of
any of the software?

Craig MacKenna
Los Gatos, CA

Re: Apache2::Request fouls up content length?

[Jonathan Vanasco]

it sounds to me like a keepalive problem

try
KeepAlive Off

if you really want it on, try
MaxKeepAliveRequests 10
KeepAliveTimeout 3

but you may not be able to specify either, as its an apache config  
option.




// Jonathan Vanasco

| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - -

| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - -

| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - -

mod_perl best practices cleanup

[Tracy12]

Hi,

I could get my Perl (mod_perl) Authentication handler with the CGI:Session
package, It is working fine.

We decided to keep the session data on LAN (file). 

As there will be new file created for each Session, We just wanted to know
how to cleanup this folder, basically to clean all the expired sessions.
Which part of the perl auth handler should do this cleanup

How can we do the above , Sample code segment in our PerlAuth handler looks
as follows

my $session = new CGI::Session() or die CGI::Session->errstr;

$session = new CGI::Session(undef, undef, {Directory=>'../tmp/sessions'});


if ( $session->is_expired ) {
 $session = $session->new();
}
if ( $session->is_empty ) {
$session = $session->new();
 }

-- 
View this message in context: 
http://www.nabble.com/mod_perl-best-practices-cleanup-tf3037692.html#a8442512
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: mod_perl best practices cleanup

[Jonathan Vanasco]

On Jan 18, 2007, at 7:53 PM, Tracy12 wrote:


We decided to keep the session data on LAN (file).

As there will be new file created for each Session, We just wanted  
to know
how to cleanup this folder, basically to clean all the expired  
sessions.

Which part of the perl auth handler should do this cleanup


none.

use a cron job to clear out files that haven't been modified within X  
time.  run it ever 15-30 minutes.


you can also store sessions in a db, and just run a cron job that  
deletes old sessions every so often.


while its possible to run a cleanup in your code, its way easier to  
just run a cron job.



// Jonathan Vanasco

| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - -

| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - -

| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - -

Re: mod_perl best practices cleanup

[Jonathan Vanasco]

Which part of the perl auth handler should do this cleanup


Just to add though -- if you really want to do a cleanup within MP,  
use the cleanup handler which works after the client connection is  
terminated.  also try setting a global timestamp so you only do the  
cleanup code once every 15 minutes or so, instead of on every request.

Re: Apache2::Request fouls up content length?

[Jonathan Vanasco]

On Jan 18, 2007, at 8:14 PM, [EMAIL PROTECTED] wrote:


You are correct.  Turning off keepalive fixes the problem.
(We're on a VPS so we have control of httpd.conf.)

My residual problem is that neither KeepAlive nor
MaxKeepAliveRequests is allowed in a  block, so
I can't just do one of them for the scripts that use Apache2::Request.

Anyone have a way to keep KeepAlive and Apache2::Request?
Might newer versions of any of the software involved fix the problem?

Thanks much,
Craig MacKenna
www.animalhead.com


personally, I would suggest this:

forget about keepalive in modperl

	don't run mod_perl on port 80.  run a proxy on it -- either apache  
or something lightweight like nginx
	run your app on port  80xx using its own apache.  have keepalive  
turned off.

keepalive can be turn on in your port 80 dae,pm
serve static off the proxy, only hit up mp for dynamic content.

its not as fast as if you had keepalive on the proxied connection,  
but its still considerably faster than not-proxying , and you don't  
deal with any of the issues of a slow-client tying up your modperl  
process


there's a section in the modperl book explaining the multi-server /  
multi-apache setup in depth.  its online, via google



// Jonathan Vanasco

| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - -

| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - -

| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - -

Re: mod_perl best practices cleanup

[Tracy12]

Looks like cron job will do, but is there any docs to write such a script.

Meantime I found a sample as follows, as I am not having any DSN  but only a
folder /tmp to store session data will this work or how this can be modified



#!/usr/bin/perl

use constant DSN=> 'driver:file';
use constant DSN_ARGS   => {};

use CGI::Session;

CGI::Session->find( DSN, sub {}, DSN_ARGS ) or die CGI::Session->errstr;



Jonathan Vanasco-3 wrote:
> 
>>> Which part of the perl auth handler should do this cleanup
> 
> Just to add though -- if you really want to do a cleanup within MP,  
> use the cleanup handler which works after the client connection is  
> terminated.  also try setting a global timestamp so you only do the  
> cleanup code once every 15 minutes or so, instead of on every request.
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/mod_perl-best-practices-cleanup-tf3037692.html#a8442858
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: mod_perl best practices cleanup

[Rhesa]

Tracy12 wrote:

Looks like cron job will do, but is there any docs to write such a script.



See CGI::Session::ExpireSessions 
(http://search.cpan.org/perldoc?CGI%3A%3ASession%3A%3AExpireSessions) for a 
complete solution).


HTH,
Rhesa

Ugly build scenario...

[William A. Rowe, Jr.]

On a very fast dual cpu xeon box, configuring and then running make under
linux gives me;

make[1]: Warning: File `Makefile.PL' has modification time 3.7e+03 s in the 
future
Makefile out-of-date with respect to Makefile.PL
Cleaning current config before rebuilding Makefile...
make -f Makefile.old clean > /dev/null 2>&1

This isn't very funny.

Is there any magic in the modperl2 or Apache-Test configurations that would
be dinking the datestamps?  Has anyone seen similar?

Re: Ugly build scenario...

[William A. Rowe, Jr.]

Nevermind

 - no, it's not fun - and the project really should rethink failing
   with an error or offering an override to bypass this error.

In this case it was svn's bogus use checkout/export time and crossing timezones
that have screwed up my datestamps.  For a project with extreme dedication to
metadata, this screwball default always trips up.

Bill


William A. Rowe, Jr. wrote:
> On a very fast dual cpu xeon box, configuring and then running make under
> linux gives me;
> 
> make[1]: Warning: File `Makefile.PL' has modification time 3.7e+03 s in the 
> future
> Makefile out-of-date with respect to Makefile.PL
> Cleaning current config before rebuilding Makefile...
> make -f Makefile.old clean > /dev/null 2>&1
> 
> This isn't very funny.
> 
> Is there any magic in the modperl2 or Apache-Test configurations that would
> be dinking the datestamps?  Has anyone seen similar?
> .
> 

Re: Ugly build scenario...

[Geoffrey Young]

William A. Rowe, Jr. wrote:
> Nevermind
> 
>  - no, it's not fun - and the project really should rethink failing
>with an error or offering an override to bypass this error.
> 
> In this case it was svn's bogus use checkout/export time and crossing 
> timezones
> that have screwed up my datestamps.  For a project with extreme dedication to
> metadata, this screwball default always trips up.
> 
> Bill
> 
> 
> William A. Rowe, Jr. wrote:
> 
>>On a very fast dual cpu xeon box, configuring and then running make under
>>linux gives me;
>>
>>make[1]: Warning: File `Makefile.PL' has modification time 3.7e+03 s in the 
>>future
>>Makefile out-of-date with respect to Makefile.PL
>>Cleaning current config before rebuilding Makefile...
>>make -f Makefile.old clean > /dev/null 2>&1

fwiw, this error is from ExtUtils::MakeMaker, part of the standard perl
toolkit, and has nothing to do with mod_perl proper - you'll see that
message from any CPAN install with similar timestamp issues.

--Geoff

Re: mod_perl best practices cleanup

[Tracy12]

I have a general understanding about cleanup handler

 But what is meant by the global timestamp and cleaning up in every 15
minutes,

 Programatically How can we achieve it
 Are u refereing to a global variable



Jonathan Vanasco-3 wrote:
> 
>>> Which part of the perl auth handler should do this cleanup
> 
> Just to add though -- if you really want to do a cleanup within MP,  
> use the cleanup handler which works after the client connection is  
> terminated.  also try setting a global timestamp so you only do the  
> cleanup code once every 15 minutes or so, instead of on every request.
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/mod_perl-best-practices-cleanup-tf3037692.html#a8444035
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: mod_perl best practices cleanup

[Tracy12]

I introduced a


 use vars qw( $SESSION_CLEANUP_COUNTER);

also having if not defined value =0,

and 

$SESSION_CLEANUP_COUNTER

When it reaches the threshold do the cleanup, but it always go to the
undefined clause and return zero,
had use vars qw been deprecated?




Tracy12 wrote:
> 
> I have a general understanding about cleanup handler
> 
>  But what is meant by the global timestamp and cleaning up in every 15
> minutes,
> 
>  Programatically How can we achieve it
>  Are u refereing to a global variable
> 
> 
> 
> Jonathan Vanasco-3 wrote:
>> 
 Which part of the perl auth handler should do this cleanup
>> 
>> Just to add though -- if you really want to do a cleanup within MP,  
>> use the cleanup handler which works after the client connection is  
>> terminated.  also try setting a global timestamp so you only do the  
>> cleanup code once every 15 minutes or so, instead of on every request.
>> 
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/mod_perl-best-practices-cleanup-tf3037692.html#a8444348
Sent from the mod_perl - General mailing list archive at Nabble.com.

Re: Two failures in make test building mod_perl 2.0.3

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Jan 18, 2007 at 02:58:45PM -0500, Geoffrey Young wrote:
> 
> > -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
> 
> > # testing : connection notes
> > # expected: 127.0.0.1
> > # received: 127.0.0.7
> > not ok 1
> 
> this looks like it may be an IPv6 issue that's perhaps outside our
> control...

...or just some funny entry in /etc/hosts (yeah, I know, but it'd be
worth checking...)

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFFsFOTBcgs9XrR2kYRApdAAJwOwQ6BRfL9T93DdJPibyjp4C1gWgCfadzZ
V2WEofsjekNIhbWtdQhvvXg=
=6Iv4
-END PGP SIGNATURE-

Re: Apache2::Request fouls up content length?

[craig]

Jonathan, thank you for your replies!

The client I'm testing with is, in most contexts, not "slow".  It's a
dual-processor 1.25 MHz PowerMac on a DSL line, with the Safari
browser which does most things faster than any other PC or Mac
browser I've used.

Thought I had a solution: since my two pages containing forms
are both under SSL, I put "KeepAlive On" in the virtual host for 80,
and "KeepAlive Off" in the virtual host for 443.

Unfortunately this did not fix the problem, from an SSL page.

Apache::Request worked with KeepAlive under Apache 1 and
mod_perl 1.  So I feel like things have gone backward...

My front page downloads a series of 80+ small jpg's, and the impact
of a general KeepAlive Off on that operation is unacceptable.

The complexity of a "multi-server / multi-apache setup" is more than
I want to deal with.

I much prefer KeepAlive on a single Apache to using Apache2::Request
on a multi-server solution.  It's easy enough to get the form data and
parse it myself.

1. Do you think the problem is in mod_perl or apreq2?
2. Does that module have a bug reporting system (other than this
mailing list) ?
3. Is there a known bug for Apache2::Request vs. KeepAlive?
4. If not, where can I post one, so this can be fixed for other people?

Thanks for your help,
Craig MacKenna
www.animalhead.com


On Jan 18, 2007, at 5:26 PM, Jonathan Vanasco wrote:



On Jan 18, 2007, at 8:14 PM, [EMAIL PROTECTED] wrote:


You are correct.  Turning off keepalive fixes the problem.
(We're on a VPS so we have control of httpd.conf.)

My residual problem is that neither KeepAlive nor
MaxKeepAliveRequests is allowed in a  block, so
I can't just do one of them for the scripts that use  
Apache2::Request.


Anyone have a way to keep KeepAlive and Apache2::Request?
Might newer versions of any of the software involved fix the problem?

Thanks much,
Craig MacKenna
www.animalhead.com


personally, I would suggest this:

forget about keepalive in modperl

	don't run mod_perl on port 80.  run a proxy on it -- either apache  
or something lightweight like nginx
	run your app on port  80xx using its own apache.  have keepalive  
turned off.

keepalive can be turn on in your port 80 dae,pm
serve static off the proxy, only hit up mp for dynamic content.

its not as fast as if you had keepalive on the proxied connection,  
but its still considerably faster than not-proxying , and you don't  
deal with any of the issues of a slow-client tying up your modperl  
process


there's a section in the modperl book explaining the multi-server /  
multi-apache setup in depth.  its online, via google



// Jonathan Vanasco

| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - - -

| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - - -

| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - - -

Re: file descriptor for client socket?

[Daniel Risacher]

>From within a mod_perl request handler, fileno(STDOUT) returns -1, which is 
>the same thing I got from $r->FILENO.

Any other ideas?


On Wed, 17 Jan 2007 17:26:56 -0500, Robert Landrum <[EMAIL PROTECTED]> wrote:
> Daniel Risacher wrote:
>> Is it possible to get the file descriptor for the client socket from the
> RequestRec?
>>
>> I.e. something like $r->FILENO (which doesn't seem to work) or perhaps
> $r->connection->client_socket->os_sock
>>
>> (os_sock exists in the APR structure in C, but there doesn't seem to be
> a perl accessor method.)
>>
>> Reason I want to do this... I'm trying write a perl module to pass the
> connection to another process using File::FDpasser.
>>
> 
> $fd = fileno(STDOUT); won't work?
> 
> Is this really what you want to do?  I think apache will still terminate
> the connection (I'm not sure there's away to avoid that).
> 
> Rob