Re: 302 Redirect not working as expected with PerlCleanupHandler and Firefox under ModPerl::Registry

[Tosh Cooey]

The good news is that Mr. Mackenna got it!  If I set "KeepAlive Off" in 
apache2.conf then it all works fine.  Below is a functioning long 
process thingy which works with "KeepAlive On" and Firefox.  I just hope 
it works with MSIE ...



#!/usr/bin/perl

use strict;
use Apache2::Const -compile => qw(:conn_keepalive);
use Apache2::Log();# defines warn
use Apache2::RequestUtil();# defines push_handlers
use Apache2::Connection();
use Apache2::RequestRec();

my $r = shift;
my $c = $r->connection();
$c->keepalive(Apache2::Const::CONN_CLOSE);
$r->push_handlers(PerlCleanupHandler => \&cleanup );

$r->err_headers_out->set(Location => 'http://...index.pl');
$r->status(Apache2::Const::REDIRECT);
return Apache2::Const::REDIRECT;

sub cleanup {
  my ($r) = @_;
  $r->warn("Starting cleanup");
  foreach my $num (1..5) {
  $r->warn("Number is $num");
  sleep 2;
  }
  return Apache2::Const::OK;
}


So, thanks again, and as for the warning from William T., well my 
spin-off processes are maybe 10s-10m long and not a driving feature, but 
I will have to keep my eye on them.


Tosh


macke...@animalhead.com wrote:

The warning from William T. made me think to ask:

Does your site have "KeepAlive On" in httpd.conf?
(If not I can't think of anything to suggest...)

If so, try adding this as part of the redirect:

use Apache2::Connection();
use Apache2::RequestRec();
...
my $c = $r->connection();
$c->keepalive(Apache2::Const::CONN_CLOSE);

This will keep your process (which is about to do a "long"
cleanup) from automatically getting the redirected request
from the browser.

Hopefully the root httpd will know that this "redirecting"
child has not finished the complete cycle, and will launch
other children if needed to process the redirected request
plus any other requests.

Of course William is right that if lots of requests are
arriving that need such cleanup, and the cleanup really does
take a long time on average, you are likely to pile up
more children than your household income (I'm sorry I meant
to say your server :-) can support.

Good Luck,
cmac


On Jan 26, 2010, at 2:27 PM, Tosh Cooey wrote:


So this works almost perfectly... Almost because:

#!/usr/bin/perl

use strict;
use Apache2::Const();# defines OK
use Apache2::Log();# defines warn
use Apache2::RequestUtil();# defines push_handlers

my $r = shift;
$r->push_handlers(PerlCleanupHandler => \&cleanup );

$r->headers_out->set(Location => 'http://...index.pl');
$r->status(Apache2::Const::REDIRECT);
return Apache2::Const::REDIRECT;

sub cleanup {
  my ($r) = @_;
  $r->warn("Starting cleanup");
  foreach my $num (1..5) {
  $r->warn("Number is $num");
  sleep 2;
  }
  return Apache2::Const::OK;
}
 test.pl


It seems if you take the above program and hit it with Firefox (3.5.7 
and 3.6) it may take 10 seconds (5 x sleep 2) before Firefox does the 
redirect.  Safari 4.0.4 seems fine.  curl works as well :)


I said "may" above because it's not consistent.  If you launch Firefox 
fresh and hit the above program it may redirect instantly, but then 
subsequent hits will illustrate the delay.  I'm also seeing varying 
behaviour on a different server that has no Basic Auth, but always the 
problem is there.


Can anyone else reproduce this?

Thank-you!

Tosh


macke...@animalhead.com wrote:

at(1) is a Unix command to start a process.
Assuming you're on a Unix/Linux box, type "man at" to get the story.
A cleanup handler is more pleasant than a prostate exam.
You can spend your life waiting for others.  Just write a
routine called "cleanup" and have it do something like
make a log entry.
use Apache2::Const();# defines OK
use Apache2::Log();# defines warn
use Apache2::RequestUtil();# defines push_handlers
...
sub cleanup {
  my ($r) = @_;
  $r->warn("cleanup was here");
  return Apache2::Const::OK;
}
Then put a call like the one below in your ModPerl::Registry routine.
If the log entry shows up in error_log, you're on your way...
Good Luck,
cmac
P.S. Google doesn't index some sites well.
Look at http://perl.apache.org/docs/2.0/
particularly its API link.
On Jan 25, 2010, at 5:49 PM, Tosh Cooey wrote:
Sorry, I couldn't figure out what at(1) meant (or maybe ap(1) which 
you say below) is that an abbreviation for something?


And Perrin saying "cleanup handler" is right up there with "prostate 
exam" in my list of things to get into, both scare me!


Of course at some point a man needs to do both...

So... If this magic: $r->push_handlers(PerlCleanupHandler => 
\&cleanup); is available in ModPerl::Registry context then I will 
attempt to force all my forks into early retirement and work the 
problem out that way.


Unfortunately Google doesn't return an easy answer, anybody know 
this before I spend all day tomorrow in my struggle?


Thank-you all again,

Tosh


macke...@animalhead.com wrote:

You made no comment on the links I sent you earlier today.
They had lots of good advice.  Part

Re: 302 Redirect not working as expected with PerlCleanupHandler and Firefox under ModPerl::Registry

[Tosh Cooey]

Would this problem be any different in a normal CGI context with the 
program doing forks?  I don't imagine it would be, which is why I see 
the ultimate wisdom in spawning an external program to handle 
long-running tasks, or just cron something.


Oh well, live and learn.

Tosh


William T wrote:

Caveat Lector:

Long Cleanups done inline on the Apache children can cause problems.

If you get a situation where the CleanUp takes to long OR you get
enough traffic to the page(s) which engage the CleanUp then you will
encounter a tipping point, and soon after your website will be almost
completely unavailable.  This will occur because the Apache Children
aren't processing requests fast enough to handle the rate at which the
come in; because they are busy in CleanUp.

The reason I bring this up is encountering the failure is usually a
catastrophic event.  The website is almost always entirely down, and
workarounds can be hard to come by.

This may or may not apply to you depending on your traffic
characteristics and how long your cleanup takes, BUT it is something
you should be aware of.

-wjt



--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/

Re: mod_perl2 + fork + DBI = Chaos

[Tosh Cooey]

Just to tie this thread up...

In case anyone else is ever in the same situation I would like to tell 
them that mod_perl(1|2) + fork = bad idea, and don't even THINK about 
throwing DBI into the mix.


For me in the future, if I have a VERY long task I will externalize it, 
and if I have brief but long tasks then the following worked great for me:


#!/usr/bin/perl

use strict;
use Apache2::Const -compile => qw(:conn_keepalive);
use Apache2::Log();# defines warn
use Apache2::RequestUtil();# defines push_handlers
use Apache2::Connection();
use Apache2::RequestRec();

my $r = shift;
my $c = $r->connection();
$c->keepalive(Apache2::Const::CONN_CLOSE);
$r->push_handlers(PerlCleanupHandler => \&cleanup );

$r->err_headers_out->set(Location => 'http://...index.pl);
$r->status(Apache2::Const::REDIRECT);
return Apache2::Const::REDIRECT;

sub cleanup { # long process
  my ($r) = @_;
  $r->warn("Starting cleanup");
  foreach my $num (1..5) {
  $r->warn("Number is $num");
  sleep 2;
  }
  return Apache2::Const::OK;
}



YMMV.

Tosh



macke...@animalhead.com wrote:

at(1) is a Unix command to start a process.
Assuming you're on a Unix/Linux box, type "man at" to get the story.

A cleanup handler is more pleasant than a prostate exam.

You can spend your life waiting for others.  Just write a
routine called "cleanup" and have it do something like
make a log entry.

use Apache2::Const();# defines OK
use Apache2::Log();# defines warn
use Apache2::RequestUtil();# defines push_handlers
...
sub cleanup {
  my ($r) = @_;
  $r->warn("cleanup was here");
  return Apache2::Const::OK;
}
Then put a call like the one below in your ModPerl::Registry routine.
If the log entry shows up in error_log, you're on your way...

Good Luck,
cmac

P.S. Google doesn't index some sites well.
Look at http://perl.apache.org/docs/2.0/
particularly its API link.


On Jan 25, 2010, at 5:49 PM, Tosh Cooey wrote:

Sorry, I couldn't figure out what at(1) meant (or maybe ap(1) which 
you say below) is that an abbreviation for something?


And Perrin saying "cleanup handler" is right up there with "prostate 
exam" in my list of things to get into, both scare me!


Of course at some point a man needs to do both...

So... If this magic: $r->push_handlers(PerlCleanupHandler => 
\&cleanup); is available in ModPerl::Registry context then I will 
attempt to force all my forks into early retirement and work the 
problem out that way.


Unfortunately Google doesn't return an easy answer, anybody know this 
before I spend all day tomorrow in my struggle?


Thank-you all again,

Tosh


macke...@animalhead.com wrote:

You made no comment on the links I sent you earlier today.
They had lots of good advice.  Particularly the first one
suggested not forking the Apache process, but using an
ap(1) call to start a process to do the additional processing.
OK, the ap(1) alternative was a bit light on details.
How about the alternative offered by Perrin Hawkins in the
same thread, of using a cleanup handler to do the follow-up
processing rather than a forked process.
 From p. 107 of "mod_per2 User's Guide":
$r->push_handlers(PerlCleanupHandler => \&cleanup);

print $in->redirect... # to redirect the browser

Now cleanup (which receives $r as its operand) can do
whatever slow stuff you need to, can probably use DBI
without all the pain you have below, and can access the
request to find out what to do.
In some past context you may have learned how to get hold of
a $r to use in these calls, and hopefully you're no longer
scared of $r.  But there does remain the question of whether
a ModPerl::Registry module can do such calls.
Hopefully someone who knows can chime in on this.
If not, for me it would be worth the editing of getting the
module out from under ModPerl::Registry and into the "native
mode" of SetHandler modperl.
Best of luck,
cmac
On Jan 25, 2010, at 1:54 PM, Tosh Cooey wrote:
Ok, then maybe I need to supply some code here to try and get 
clarification:


mailfile.pl
###
use strict;
...
use POSIX;

#gather needed modules and objects
my $fileOBJ = new MyOBJS::FILE($in->param('id'));
my $clientOBJ = new ...
my $userOBJ = new ...
# All OBJjects have a {DBH} property which is their DB handle
# I hear I have to disconnect these first, do I have to disconnect ALL?
$fileOBJ->{DBH}->disconnect;
$SIG{CHLD} = 'IGNORE';
my $pid;
if ($pid = fork) {
warn "Pid = $pid";
} elsif (defined $pid) {
close(STDOUT);
close(STDIN);
close(STDERR);

# chdir to /, stops the process from preventing an unmount
chdir '/' or die "Can't chdir to /: $!";
# dump our STDIN and STDOUT handles
open STDIN, '/dev/null' or die "Can't read /dev/null: $!";
open STDOUT, '>/dev/null' or die "Can't write to /dev/null: $!";
# redirect for logging
open STDERR, '>/tmp/stderr' or die "Can't write to /tmp/stderr: 
$!";

# Prevent locking to apache process
setsid or die "Can't start a new session: $!";

Re: Redirect WTF

[Adam Prime]

David E. Wheeler wrote:

Fellow mod_perlers,



Note that the hosthame is "benedict.local". Now I often just use localhost when 
using Bricolage, and most of the time that works fine. But there is one 
JavaScript-triggered redirect button that looks like this:

window.location.href = '/admin/profile/dest?id=1024'

And when I click it, The request goes to mod_perl and I see it come through the 
access handler and the fixup handler as a request to localhost. But then the 
PerlReponseHandler never fires! Instead, I see another request come in for the 
same URL path, but this time for the host name benedict.local. It's almost as 
if something in Apache or mod_perl is seeing that the request is for a 
different domain name and helpfully trying to redirect. But it's not helpful (I 
get a new login screen), and I don't understand why the same thing doesn't 
happen for other requests.

Is there something like that in mod_perl2 and I'm just missing it? Or is it 
more likely that there's some other mysterious bit of code in Bricolage that's 
doing it and I just haven't found it yet? If the latter, what comes between the 
PerlFixupHandler and PerlResponseHandler? Because in that first request, the 
fixup handler fires but the response handler never does.



This smells like a UseCanonicalName On + mod_dir redirect to me.  If the 
directory /admin/profile/dest exists in the document root, there's a 
good chance it is.


HTH,

Adam

Re: mod_perl2 + fork + DBI = Chaos

[Perrin Harkins]

On Wed, Jan 27, 2010 at 8:22 AM, Tosh Cooey  wrote:
> In case anyone else is ever in the same situation I would like to tell them
> that mod_perl(1|2) + fork = bad idea, and don't even THINK about throwing
> DBI into the mix.

I don't want people to think this doesn't work.  It does work, and has
been used successfully before.  Any time you mix DBI with forking, you
do have to be careful about closing handles, as described in the links
earlier in this thread.  It's hard enough to get right that I would
advise people to use a job queue instead if possible.

> For me in the future, if I have a VERY long task I will externalize it, and
> if I have brief but long tasks then the following worked great for me:

That's good advice: use a separate job queue or a cleanup handler for
short tasks.

- Perrin

Re: mod_perl-2.0.4 with Apache 2.2.9 and perl 5.10.0 intermittent crashing

[Tosh Cooey]

I'm seeing the same thing on my DEV server which is:

Server: Apache/2.2.11 (Ubuntu) mod_perl/2.0.4 Perl/v5.10.0

I see it in the mornings when it has been sitting around all night doing 
nothing, and the first couple hits result in core dumps/seg faults, then 
after pounding REFRESH like a mad monkey a couple times it then works.


This is on an Amazon EC2 Ubuntu 9.04 jaunty AMI built by Eric Hammond
http://alestic.com  http://ec2ubuntu-group.notlong.com

perl -V:

Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
  Platform:
osname=linux, osvers=2.6.24-23-server, 
archname=i486-linux-gnu-thread-multi
uname='linux rothera 2.6.24-23-server #1 smp wed apr 1 22:22:14 utc 
2009 i686 gnulinux '
config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN 
-Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr 
-Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 
-Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 
-Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local 
-Dsitelib=/usr/local/share/perl/5.10.0 
-Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1 
-Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 
-Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl 
-Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio 
-Uusenm -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib 
-Dlibperl=libperl.so.5.10.0 -Dd_dosuid -des'

hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN 
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64',

optimize='-O2 -g',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing 
-pipe -I/usr/local/include'

ccversion='', gccversion='4.3.3', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8

alignbytes=4, prototype=define
  Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /usr/lib64
libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
perllibs=-ldl -lm -lpthread -lc -lcrypt
libc=/lib/libc-2.9.so, so=so, useshrplib=true, 
libperl=libperl.so.5.10.0

gnulibc_version='2.9'
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib'


Characteristics of this binary (from libperl):
  Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_ITHREADS
USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API
  Built under linux
  Compiled at Jun 26 2009 18:23:00
  @INC:
/etc/perl
/usr/local/lib/perl/5.10.0
/usr/local/share/perl/5.10.0
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.10
/usr/share/perl/5.10
/usr/local/lib/site_perl
.


Of course this could also just be all the illegitimate bastard apache 
children I have been spawning being totally unprepared to answer a real 
web request, but I'm keeping an eye on this server...


Tosh


Pas Argenio wrote:
Sorry if this is naive, but has anyone gotten this combo to work?  
Upgraded to Apache 2.2.14, now crash on almost every request, then next 
httpd picks up the request and actually displays the page...


I've got massive core dumps all ending in malloc/free, truss shows last 
operation was close()


--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/

Re: Redirect WTF

[David E. Wheeler]

On Jan 27, 2010, at 7:23 AM, Adam Prime wrote:

> This smells like a UseCanonicalName On + mod_dir redirect to me.  If the 
> directory /admin/profile/dest exists in the document root, there's a good 
> chance it is.

Ooh, thanks! I can see that I have mod_dir as a DSO, but I'm not loading it. 
The only modules loaded are:

LoadModule   perl_module /usr/local/apache2/modules/mod_perl.so
LoadModule   expires_module modules/mod_expires.so
LoadModule   apreq_module modules/mod_apreq2.so

Might the core be loading it somehow?

Thanks,

Daivd

Re: 302 Redirect not working as expected with PerlCleanupHandler and Firefox under ModPerl::Registry

[mackenna]

Just wanted to note that since you've put the CONN_CLOSE in the  
redirect code, it's not necessary (nor desirable) to put

"KeepAlive Off" in apache2.conf


With the CONN_CLOSE call you turn KA off just when you need it to be  
off.


So what's the bad news?

cmac


On Jan 27, 2010, at 5:08 AM, Tosh Cooey wrote:

The good news is that Mr. Mackenna got it!  If I set "KeepAlive  
Off" in apache2.conf then it all works fine.  Below is a  
functioning long process thingy which works with "KeepAlive On" and  
Firefox.  I just hope it works with MSIE ...



#!/usr/bin/perl

use strict;
use Apache2::Const -compile => qw(:conn_keepalive);
use Apache2::Log();# defines warn
use Apache2::RequestUtil();# defines push_handlers
use Apache2::Connection();
use Apache2::RequestRec();

my $r = shift;
my $c = $r->connection();
$c->keepalive(Apache2::Const::CONN_CLOSE);
$r->push_handlers(PerlCleanupHandler => \&cleanup );

$r->err_headers_out->set(Location => 'http://...index.pl');
$r->status(Apache2::Const::REDIRECT);
return Apache2::Const::REDIRECT;

sub cleanup {
  my ($r) = @_;
  $r->warn("Starting cleanup");
  foreach my $num (1..5) {
  $r->warn("Number is $num");
  sleep 2;
  }
  return Apache2::Const::OK;
}


So, thanks again, and as for the warning from William T., well my  
spin-off processes are maybe 10s-10m long and not a driving  
feature, but I will have to keep my eye on them.


Tosh


macke...@animalhead.com wrote:

The warning from William T. made me think to ask:
Does your site have "KeepAlive On" in httpd.conf?
(If not I can't think of anything to suggest...)
If so, try adding this as part of the redirect:
use Apache2::Connection();
use Apache2::RequestRec();
...
my $c = $r->connection();
$c->keepalive(Apache2::Const::CONN_CLOSE);
This will keep your process (which is about to do a "long"
cleanup) from automatically getting the redirected request
from the browser.
Hopefully the root httpd will know that this "redirecting"
child has not finished the complete cycle, and will launch
other children if needed to process the redirected request
plus any other requests.
Of course William is right that if lots of requests are
arriving that need such cleanup, and the cleanup really does
take a long time on average, you are likely to pile up
more children than your household income (I'm sorry I meant
to say your server :-) can support.
Good Luck,
cmac
On Jan 26, 2010, at 2:27 PM, Tosh Cooey wrote:

So this works almost perfectly... Almost because:

#!/usr/bin/perl

use strict;
use Apache2::Const();# defines OK
use Apache2::Log();# defines warn
use Apache2::RequestUtil();# defines push_handlers

my $r = shift;
$r->push_handlers(PerlCleanupHandler => \&cleanup );

$r->headers_out->set(Location => 'http://...index.pl');
$r->status(Apache2::Const::REDIRECT);
return Apache2::Const::REDIRECT;

sub cleanup {
  my ($r) = @_;
  $r->warn("Starting cleanup");
  foreach my $num (1..5) {
  $r->warn("Number is $num");
  sleep 2;
  }
  return Apache2::Const::OK;
}
 test.pl


It seems if you take the above program and hit it with Firefox  
(3.5.7 and 3.6) it may take 10 seconds (5 x sleep 2) before  
Firefox does the redirect.  Safari 4.0.4 seems fine.  curl works  
as well :)


I said "may" above because it's not consistent.  If you launch  
Firefox fresh and hit the above program it may redirect  
instantly, but then subsequent hits will illustrate the delay.   
I'm also seeing varying behaviour on a different server that has  
no Basic Auth, but always the problem is there.


Can anyone else reproduce this?

Thank-you!

Tosh


macke...@animalhead.com wrote:

at(1) is a Unix command to start a process.
Assuming you're on a Unix/Linux box, type "man at" to get the  
story.

A cleanup handler is more pleasant than a prostate exam.
You can spend your life waiting for others.  Just write a
routine called "cleanup" and have it do something like
make a log entry.
use Apache2::Const();# defines OK
use Apache2::Log();# defines warn
use Apache2::RequestUtil();# defines push_handlers
...
sub cleanup {
  my ($r) = @_;
  $r->warn("cleanup was here");
  return Apache2::Const::OK;
}
Then put a call like the one below in your ModPerl::Registry  
routine.

If the log entry shows up in error_log, you're on your way...
Good Luck,
cmac
P.S. Google doesn't index some sites well.
Look at http://perl.apache.org/docs/2.0/
particularly its API link.
On Jan 25, 2010, at 5:49 PM, Tosh Cooey wrote:
Sorry, I couldn't figure out what at(1) meant (or maybe ap(1)  
which you say below) is that an abbreviation for something?


And Perrin saying "cleanup handler" is right up there with  
"prostate exam" in my list of things to get into, both scare me!


Of course at some point a man needs to do both...

So... If this magic: $r->push_handlers(PerlCleanupHandler =>  
\&cleanup); is available in ModPerl::Registry context then I  
will attempt to force all my forks into ea

Re: Redirect WTF

[Adam Prime]

David E. Wheeler wrote:

On Jan 27, 2010, at 7:23 AM, Adam Prime wrote:


This smells like a UseCanonicalName On + mod_dir redirect to me.  If the 
directory /admin/profile/dest exists in the document root, there's a good 
chance it is.


Ooh, thanks! I can see that I have mod_dir as a DSO, but I'm not loading it. 
The only modules loaded are:

LoadModule   perl_module /usr/local/apache2/modules/mod_perl.so
LoadModule   expires_module modules/mod_expires.so
LoadModule   apreq_module modules/mod_apreq2.so

Might the core be loading it somehow?


It appears that mod_dir is compiled and loaded by default unless you 
take steps to exclude it:


http://httpd.apache.org/docs/2.2/mod/mod_dir.html

http://httpd.apache.org/docs/2.2/mod/module-dict.html#Status

Adam

Re: mod_perl-2.0.4 with Apache 2.2.9 and perl 5.10.0 intermittent crashing

[Pas Argenio]

I just fell back to Apache-2.2.8 but same problem.  By the way, Tosh, how
did you dump the libperl info?
I'm getting more core dumps than you, but pages are displayed by the next
child to pick it up.  Here is the most common stack trace (via Solaris'
pstack command):

Wed Jan 27 09:06:35 EST 2010
core '/tmp/core' of 13862:/usr/local/apache/bin/httpd -k start
 fee56ec8 t_delete (528c90, 228, 0, fecb2e24, fef303a8, c20360) + 74
 fee56ac4 realfree (528a60, 229, d995c, fee56eb0, 0, 528a58) + 8c
 fee56610 _malloc_unlocked (528598, 6f8, 528590, ff, 0, 0) + 260
 fee56394 malloc   (4c8, 1, da058, fee563a0, fef303a8, fef3a518) + 4c
 fec8ae8c Perl_safesysmalloc (4c8, 0, 200, fff8, c04, c329d9) +
10
 fecc2294 Perl_sv_grow (d17680, 4c8, 0, 200, 4cb, 0) + f8
 fecbd094 Perl_sv_setsv_flags (84408, 4c7, 12c04540, d17680, d177e0,
ff80) + ea0
 fecbd5ac Perl_sv_mortalcopy (d177e0, 5e65d0, fed76000, 78, fed74400,
d17680) + 60
 fecb2e24 Perl_pp_aassign (fed76294, 5b8c20, 5b8c0c, 5b8c1c, 0, fed74400) +
154
 fecaa830 Perl_runops_standard (0, fecb2cd0, fed75c88, 91c2c0, fed75c00,
91cec0) + 1c
 feca4ce0 Perl_call_sv (fed75c00, fed76000, fed76000, fed75c00, fed75c00,
91c2c0) + 4a4
 fec1ca94 modperl_callback (0, 44b410, 44b450, ab4b8, 160080, fed76000) +
338
 fec1d05c modperl_callback_run_handlers (fed75dec, 4, 44b450, 121dc8, ab4b8,
0) + 31c
 fec1d32c modperl_callback_per_dir (6, 44b450, 1, 1, ffbff03c, 214678) + 24
 fec19ab4 modperl_response_handler_run (44b450, 0, 1460, 0, fed761d8,
fed76000) + 18
 fec19cc4 modperl_response_handler_cgi (44b450, 4484b8, 121520, 0, 99070, 9)
+ 134
 0003bfe4 ap_run_handler (44b450, 0, c, 449018, 448728, 0) + 3c
 0003c460 ap_invoke_handler (44b450, 77400, 44b450, 0, fe780020, 0) + b8
 000547f8 ap_process_request (44b450, 0, 4, 44b450, 0, 443728) + 160
 00051964 ap_process_http_connection (4436c8, 443430, 443430, 0, 998d0, 2) +
10c
 00042790 ap_run_process_connection (4436c8, 443430, 443430, 0, 441438,
4453f8) + 3c
 00067a10 child_main (0, 0, 99c00, 99800, 11177, 99800) + 42c
 00067c74 make_child (67400, 0, 0, fe781020, 440fc8, 0) + ec
 00067d44 startup_children (5, feebd280, 0, 10, 1cf4, a) + 68
 000686b0 ap_mpm_run (a4878, 99800, ab4b8, 99c00, 99800, 99800) + 950
 000291f4 main (a4878, 96c00, 99000, 99000, a2870, 0) + 780
 00028594 _start   (0, 0, 0, 0, 0, 0) + 5c

My MPM is straight pre-fork, default 5 children to start with.
Unfortunately, this stuff needs to go into production soon.



On Wed, Jan 27, 2010 at 11:42 AM, Tosh Cooey  wrote:

> I'm seeing the same thing on my DEV server which is:
>
> Server: Apache/2.2.11 (Ubuntu) mod_perl/2.0.4 Perl/v5.10.0
>
> I see it in the mornings when it has been sitting around all night doing
> nothing, and the first couple hits result in core dumps/seg faults, then
> after pounding REFRESH like a mad monkey a couple times it then works.
>
> This is on an Amazon EC2 Ubuntu 9.04 jaunty AMI built by Eric Hammond
> http://alestic.com  http://ec2ubuntu-group.notlong.com
>
> perl -V:
>
>
> Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
>  Platform:
>osname=linux, osvers=2.6.24-23-server,
> archname=i486-linux-gnu-thread-multi
>uname='linux rothera 2.6.24-23-server #1 smp wed apr 1 22:22:14 utc 2009
> i686 gnulinux '
>config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN
> -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr
> -Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10
> -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5
> -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.10.0
> -Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1
> -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1
> -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl
> -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm
> -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.10.0
> -Dd_dosuid -des'
>
>hint=recommended, useposix=true, d_sigaction=define
>useithreads=define, usemultiplicity=define
>
>useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
>use64bitint=undef, use64bitall=undef, uselongdouble=undef
>usemymalloc=n, bincompat5005=undef
>  Compiler:
>cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN
> -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64',
>optimize='-O2 -g',
>cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe
> -I/usr/local/include'
>ccversion='', gccversion='4.3.3', gccosandvers=''
>intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
>d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
>
>ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
> lseeksize=8
>alignbytes=4, prototype=define
>  Linker and Libraries:
>ld='cc', ldflags =' -L/usr/local/lib'
>libpth=/usr/local/lib /lib /usr/lib /usr/lib

Re: mod_perl-2.0.4 with Apache 2.2.9 and perl 5.10.0 intermittent crashing

[Tosh Cooey]

perl -V

I don't think it's an Apache issue, my purely superstitious feelings 
based on the ravens I saw flying around this morning is that blame lies 
with perl 5.10, I just don't trust even number releases, even less round 
numbers cleanly divisible by 10.


But then $r scares me so...

Are you in Europe?  It's really cold here, so maybe Apache needs to warm 
up first like a car, it takes a couple moments before it turns over?


But in all seriousness I am also having the same problem.  How did you 
create your setup?  From packages or building everything from source?


I'm using packages and suspect fault there as well...

Tosh


Pas Argenio wrote:
I just fell back to Apache-2.2.8 but same problem.  By the way, Tosh, 
how did you dump the libperl info?
I'm getting more core dumps than you, but pages are displayed by the 
next child to pick it up.  Here is the most common stack trace (via 
Solaris' pstack command):


Wed Jan 27 09:06:35 EST 2010
core '/tmp/core' of 13862:/usr/local/apache/bin/httpd -k start
 fee56ec8 t_delete (528c90, 228, 0, fecb2e24, fef303a8, c20360) + 74
 fee56ac4 realfree (528a60, 229, d995c, fee56eb0, 0, 528a58) + 8c
 fee56610 _malloc_unlocked (528598, 6f8, 528590, ff, 0, 0) + 260
 fee56394 malloc   (4c8, 1, da058, fee563a0, fef303a8, fef3a518) + 4c
 fec8ae8c Perl_safesysmalloc (4c8, 0, 200, fff8, c04, 
c329d9) + 10

 fecc2294 Perl_sv_grow (d17680, 4c8, 0, 200, 4cb, 0) + f8
 fecbd094 Perl_sv_setsv_flags (84408, 4c7, 12c04540, d17680, d177e0, 
ff80) + ea0
 fecbd5ac Perl_sv_mortalcopy (d177e0, 5e65d0, fed76000, 78, fed74400, 
d17680) + 60
 fecb2e24 Perl_pp_aassign (fed76294, 5b8c20, 5b8c0c, 5b8c1c, 0, 
fed74400) + 154
 fecaa830 Perl_runops_standard (0, fecb2cd0, fed75c88, 91c2c0, fed75c00, 
91cec0) + 1c
 feca4ce0 Perl_call_sv (fed75c00, fed76000, fed76000, fed75c00, 
fed75c00, 91c2c0) + 4a4
 fec1ca94 modperl_callback (0, 44b410, 44b450, ab4b8, 160080, fed76000) 
+ 338
 fec1d05c modperl_callback_run_handlers (fed75dec, 4, 44b450, 121dc8, 
ab4b8, 0) + 31c

 fec1d32c modperl_callback_per_dir (6, 44b450, 1, 1, ffbff03c, 214678) + 24
 fec19ab4 modperl_response_handler_run (44b450, 0, 1460, 0, fed761d8, 
fed76000) + 18
 fec19cc4 modperl_response_handler_cgi (44b450, 4484b8, 121520, 0, 
99070, 9) + 134

 0003bfe4 ap_run_handler (44b450, 0, c, 449018, 448728, 0) + 3c
 0003c460 ap_invoke_handler (44b450, 77400, 44b450, 0, fe780020, 0) + b8
 000547f8 ap_process_request (44b450, 0, 4, 44b450, 0, 443728) + 160
 00051964 ap_process_http_connection (4436c8, 443430, 443430, 0, 998d0, 
2) + 10c
 00042790 ap_run_process_connection (4436c8, 443430, 443430, 0, 441438, 
4453f8) + 3c

 00067a10 child_main (0, 0, 99c00, 99800, 11177, 99800) + 42c
 00067c74 make_child (67400, 0, 0, fe781020, 440fc8, 0) + ec
 00067d44 startup_children (5, feebd280, 0, 10, 1cf4, a) + 68
 000686b0 ap_mpm_run (a4878, 99800, ab4b8, 99c00, 99800, 99800) + 950
 000291f4 main (a4878, 96c00, 99000, 99000, a2870, 0) + 780
 00028594 _start   (0, 0, 0, 0, 0, 0) + 5c

My MPM is straight pre-fork, default 5 children to start with.  
Unfortunately, this stuff needs to go into production soon.




On Wed, Jan 27, 2010 at 11:42 AM, Tosh Cooey > wrote:


I'm seeing the same thing on my DEV server which is:

Server: Apache/2.2.11 (Ubuntu) mod_perl/2.0.4 Perl/v5.10.0

I see it in the mornings when it has been sitting around all night
doing nothing, and the first couple hits result in core dumps/seg
faults, then after pounding REFRESH like a mad monkey a couple times
it then works.

This is on an Amazon EC2 Ubuntu 9.04 jaunty AMI built by Eric Hammond
http://alestic.com  http://ec2ubuntu-group.notlong.com

perl -V:


Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
 Platform:
   osname=linux, osvers=2.6.24-23-server,
archname=i486-linux-gnu-thread-multi
   uname='linux rothera 2.6.24-23-server #1 smp wed apr 1 22:22:14
utc 2009 i686 gnulinux '
   config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN
-Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr
-Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10
-Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5
-Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local
-Dsitelib=/usr/local/share/perl/5.10.0
-Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1
-Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1
-Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl
-Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio
-Uusenm -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib
-Dlibperl=libperl.so.5.10.0 -Dd_dosuid -des'

   hint=recommended, useposix=true, d_sigaction=define
   useithreads=define, usemultiplicity=define

   useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
   use64bitint=undef, use64bitall=undef, uselongdouble=undef
  

Re: mod_perl-2.0.4 with Apache 2.2.9 and perl 5.10.0 intermittent crashing

[Pas Argenio]

No, wish I were. East coast US, unseasonably warm (we have more hot air in
general).

I'm building everything from source.  I've rebuilt perl a half-dozen times
both static & dynamic.  I'm working on building 5.10.1 but it seems so
different in the build defaults.
Still to try: mod_perl.2.0.3 and using perl malloc

On Wed, Jan 27, 2010 at 1:50 PM, Tosh Cooey  wrote:

> perl -V
>
> I don't think it's an Apache issue, my purely superstitious feelings based
> on the ravens I saw flying around this morning is that blame lies with perl
> 5.10, I just don't trust even number releases, even less round numbers
> cleanly divisible by 10.
>
> But then $r scares me so...
>
> Are you in Europe?  It's really cold here, so maybe Apache needs to warm up
> first like a car, it takes a couple moments before it turns over?
>
> But in all seriousness I am also having the same problem.  How did you
> create your setup?  From packages or building everything from source?
>
> I'm using packages and suspect fault there as well...
>
> Tosh
>
>
> Pas Argenio wrote:
>
>> I just fell back to Apache-2.2.8 but same problem.  By the way, Tosh, how
>> did you dump the libperl info?
>> I'm getting more core dumps than you, but pages are displayed by the next
>> child to pick it up.  Here is the most common stack trace (via Solaris'
>> pstack command):
>>
>> Wed Jan 27 09:06:35 EST 2010
>> core '/tmp/core' of 13862:/usr/local/apache/bin/httpd -k start
>>  fee56ec8 t_delete (528c90, 228, 0, fecb2e24, fef303a8, c20360) + 74
>>  fee56ac4 realfree (528a60, 229, d995c, fee56eb0, 0, 528a58) + 8c
>>  fee56610 _malloc_unlocked (528598, 6f8, 528590, ff, 0, 0) + 260
>>  fee56394 malloc   (4c8, 1, da058, fee563a0, fef303a8, fef3a518) + 4c
>>  fec8ae8c Perl_safesysmalloc (4c8, 0, 200, fff8, c04, c329d9)
>> + 10
>>  fecc2294 Perl_sv_grow (d17680, 4c8, 0, 200, 4cb, 0) + f8
>>  fecbd094 Perl_sv_setsv_flags (84408, 4c7, 12c04540, d17680, d177e0,
>> ff80) + ea0
>>  fecbd5ac Perl_sv_mortalcopy (d177e0, 5e65d0, fed76000, 78, fed74400,
>> d17680) + 60
>>  fecb2e24 Perl_pp_aassign (fed76294, 5b8c20, 5b8c0c, 5b8c1c, 0, fed74400)
>> + 154
>>  fecaa830 Perl_runops_standard (0, fecb2cd0, fed75c88, 91c2c0, fed75c00,
>> 91cec0) + 1c
>>  feca4ce0 Perl_call_sv (fed75c00, fed76000, fed76000, fed75c00, fed75c00,
>> 91c2c0) + 4a4
>>  fec1ca94 modperl_callback (0, 44b410, 44b450, ab4b8, 160080, fed76000) +
>> 338
>>  fec1d05c modperl_callback_run_handlers (fed75dec, 4, 44b450, 121dc8,
>> ab4b8, 0) + 31c
>>  fec1d32c modperl_callback_per_dir (6, 44b450, 1, 1, ffbff03c, 214678) +
>> 24
>>  fec19ab4 modperl_response_handler_run (44b450, 0, 1460, 0, fed761d8,
>> fed76000) + 18
>>  fec19cc4 modperl_response_handler_cgi (44b450, 4484b8, 121520, 0, 99070,
>> 9) + 134
>>  0003bfe4 ap_run_handler (44b450, 0, c, 449018, 448728, 0) + 3c
>>  0003c460 ap_invoke_handler (44b450, 77400, 44b450, 0, fe780020, 0) + b8
>>  000547f8 ap_process_request (44b450, 0, 4, 44b450, 0, 443728) + 160
>>  00051964 ap_process_http_connection (4436c8, 443430, 443430, 0, 998d0, 2)
>> + 10c
>>  00042790 ap_run_process_connection (4436c8, 443430, 443430, 0, 441438,
>> 4453f8) + 3c
>>  00067a10 child_main (0, 0, 99c00, 99800, 11177, 99800) + 42c
>>  00067c74 make_child (67400, 0, 0, fe781020, 440fc8, 0) + ec
>>  00067d44 startup_children (5, feebd280, 0, 10, 1cf4, a) + 68
>>  000686b0 ap_mpm_run (a4878, 99800, ab4b8, 99c00, 99800, 99800) + 950
>>  000291f4 main (a4878, 96c00, 99000, 99000, a2870, 0) + 780
>>  00028594 _start   (0, 0, 0, 0, 0, 0) + 5c
>>
>> My MPM is straight pre-fork, default 5 children to start with.
>>  Unfortunately, this stuff needs to go into production soon.
>>
>>
>>
>> On Wed, Jan 27, 2010 at 11:42 AM, Tosh Cooey > t...@1200group.com>> wrote:
>>
>>I'm seeing the same thing on my DEV server which is:
>>
>>Server: Apache/2.2.11 (Ubuntu) mod_perl/2.0.4 Perl/v5.10.0
>>
>>I see it in the mornings when it has been sitting around all night
>>doing nothing, and the first couple hits result in core dumps/seg
>>faults, then after pounding REFRESH like a mad monkey a couple times
>>it then works.
>>
>>This is on an Amazon EC2 Ubuntu 9.04 jaunty AMI built by Eric Hammond
>>http://alestic.com  http://ec2ubuntu-group.notlong.com
>>
>>perl -V:
>>
>>
>>Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
>> Platform:
>>   osname=linux, osvers=2.6.24-23-server,
>>archname=i486-linux-gnu-thread-multi
>>   uname='linux rothera 2.6.24-23-server #1 smp wed apr 1 22:22:14
>>utc 2009 i686 gnulinux '
>>   config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN
>>-Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr
>>-Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10
>>-Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5
>>-Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local
>>-Dsitelib=/usr/local/share/perl/5.10.0
>>-Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1d

Re: mod_perl-2.0.4 with Apache 2.2.9 and perl 5.10.0 intermittent crashing

[Fred Moyer]

Perl 5.10.1 is still relatively new, so you might want to give 5.8.9 a
shot.  That is more heavily vetted on lesser used platforms such as
Solaris.

On Wed, Jan 27, 2010 at 9:28 AM, Pas Argenio  wrote:
> I just fell back to Apache-2.2.8 but same problem.  By the way, Tosh, how
> did you dump the libperl info?
> I'm getting more core dumps than you, but pages are displayed by the next
> child to pick it up.  Here is the most common stack trace (via Solaris'
> pstack command):
>
> Wed Jan 27 09:06:35 EST 2010
> core '/tmp/core' of 13862:    /usr/local/apache/bin/httpd -k start
>  fee56ec8 t_delete (528c90, 228, 0, fecb2e24, fef303a8, c20360) + 74
>  fee56ac4 realfree (528a60, 229, d995c, fee56eb0, 0, 528a58) + 8c
>  fee56610 _malloc_unlocked (528598, 6f8, 528590, ff, 0, 0) + 260
>  fee56394 malloc   (4c8, 1, da058, fee563a0, fef303a8, fef3a518) + 4c
>  fec8ae8c Perl_safesysmalloc (4c8, 0, 200, fff8, c04, c329d9) +
> 10
>  fecc2294 Perl_sv_grow (d17680, 4c8, 0, 200, 4cb, 0) + f8
>  fecbd094 Perl_sv_setsv_flags (84408, 4c7, 12c04540, d17680, d177e0,
> ff80) + ea0
>  fecbd5ac Perl_sv_mortalcopy (d177e0, 5e65d0, fed76000, 78, fed74400,
> d17680) + 60
>  fecb2e24 Perl_pp_aassign (fed76294, 5b8c20, 5b8c0c, 5b8c1c, 0, fed74400) +
> 154
>  fecaa830 Perl_runops_standard (0, fecb2cd0, fed75c88, 91c2c0, fed75c00,
> 91cec0) + 1c
>  feca4ce0 Perl_call_sv (fed75c00, fed76000, fed76000, fed75c00, fed75c00,
> 91c2c0) + 4a4
>  fec1ca94 modperl_callback (0, 44b410, 44b450, ab4b8, 160080, fed76000) +
> 338
>  fec1d05c modperl_callback_run_handlers (fed75dec, 4, 44b450, 121dc8, ab4b8,
> 0) + 31c
>  fec1d32c modperl_callback_per_dir (6, 44b450, 1, 1, ffbff03c, 214678) + 24
>  fec19ab4 modperl_response_handler_run (44b450, 0, 1460, 0, fed761d8,
> fed76000) + 18
>  fec19cc4 modperl_response_handler_cgi (44b450, 4484b8, 121520, 0, 99070, 9)
> + 134
>  0003bfe4 ap_run_handler (44b450, 0, c, 449018, 448728, 0) + 3c
>  0003c460 ap_invoke_handler (44b450, 77400, 44b450, 0, fe780020, 0) + b8
>  000547f8 ap_process_request (44b450, 0, 4, 44b450, 0, 443728) + 160
>  00051964 ap_process_http_connection (4436c8, 443430, 443430, 0, 998d0, 2) +
> 10c
>  00042790 ap_run_process_connection (4436c8, 443430, 443430, 0, 441438,
> 4453f8) + 3c
>  00067a10 child_main (0, 0, 99c00, 99800, 11177, 99800) + 42c
>  00067c74 make_child (67400, 0, 0, fe781020, 440fc8, 0) + ec
>  00067d44 startup_children (5, feebd280, 0, 10, 1cf4, a) + 68
>  000686b0 ap_mpm_run (a4878, 99800, ab4b8, 99c00, 99800, 99800) + 950
>  000291f4 main (a4878, 96c00, 99000, 99000, a2870, 0) + 780
>  00028594 _start   (0, 0, 0, 0, 0, 0) + 5c
>
> My MPM is straight pre-fork, default 5 children to start with.
> Unfortunately, this stuff needs to go into production soon.
>
>
>
> On Wed, Jan 27, 2010 at 11:42 AM, Tosh Cooey  wrote:
>>
>> I'm seeing the same thing on my DEV server which is:
>>
>> Server: Apache/2.2.11 (Ubuntu) mod_perl/2.0.4 Perl/v5.10.0
>>
>> I see it in the mornings when it has been sitting around all night doing
>> nothing, and the first couple hits result in core dumps/seg faults, then
>> after pounding REFRESH like a mad monkey a couple times it then works.
>>
>> This is on an Amazon EC2 Ubuntu 9.04 jaunty AMI built by Eric Hammond
>> http://alestic.com  http://ec2ubuntu-group.notlong.com
>>
>> perl -V:
>>
>> Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
>>  Platform:
>>    osname=linux, osvers=2.6.24-23-server,
>> archname=i486-linux-gnu-thread-multi
>>    uname='linux rothera 2.6.24-23-server #1 smp wed apr 1 22:22:14 utc
>> 2009 i686 gnulinux '
>>    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN
>> -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr
>> -Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10
>> -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5
>> -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.10.0
>> -Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1
>> -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1
>> -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl
>> -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm
>> -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.10.0
>> -Dd_dosuid -des'
>>    hint=recommended, useposix=true, d_sigaction=define
>>    useithreads=define, usemultiplicity=define
>>    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
>>    use64bitint=undef, use64bitall=undef, uselongdouble=undef
>>    usemymalloc=n, bincompat5005=undef
>>  Compiler:
>>    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN
>> -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
>> -D_FILE_OFFSET_BITS=64',
>>    optimize='-O2 -g',
>>    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing
>> -pipe -I/usr/local/include'
>>    ccversion='', gccversion='4.3.3', gccosandvers=''
>>    intsize=4, longsize=4, ptrsize=4

Re: writing CGI::Session sessions only when necessary

[Perrin Harkins]

On Tue, Jan 26, 2010 at 7:42 PM, Jonathan Swartz  wrote:
> On our site we create a new CGI::Session object at the beginning of the
> request, so that it can be used anywhere in the web code.
>
> However, sessions are rarely written to, so at the end of the request I'd
> like to avoid actually writing out a new session to backing store unless a
> param actually got set.

It might be simpler to just write immediately when you set a param.
It's simple and foolproof, and it's only a negative for performance if
you normally set multiple params in a single request.

If your ultimate goal is to fix performance on your servers, I'd
recommend looking at using encrypted data in a cookie and ditching
server-side session storage.

- Perrin

Re: writing CGI::Session sessions only when necessary

[Jonathan Swartz]

On Jan 27, 2010, at 2:45 PM, Perrin Harkins wrote:

On Tue, Jan 26, 2010 at 7:42 PM, Jonathan Swartz   
wrote:
On our site we create a new CGI::Session object at the beginning of  
the

request, so that it can be used anywhere in the web code.

However, sessions are rarely written to, so at the end of the  
request I'd
like to avoid actually writing out a new session to backing store  
unless a

param actually got set.


It might be simpler to just write immediately when you set a param.
It's simple and foolproof, and it's only a negative for performance if
you normally set multiple params in a single request.

If your ultimate goal is to fix performance on your servers, I'd
recommend looking at using encrypted data in a cookie and ditching
server-side session storage.



True. My solution only involves a couple of lines of code, so it isn't  
going to get much simpler. It would just be ideal if I could use the  
public API. And this seems like an optimization that others might want.

Re: mod_perl-2.0.4 with Apache 2.2.9 and perl 5.10.0 intermittent crashing

[John D Groenveld]

In message <30a2344a1001271105t6c690071qb72eb53df2a68...@mail.gmail.com>, Pas A
rgenio writes:
>I'm building everything from source.  I've rebuilt perl a half-dozen times
>both static & dynamic.  I'm working on building 5.10.1 but it seems so

Does modperl's make test succeed?

Under Solaris, you need to be very careful to match your Perl build
to your Apache.

These are my notes for 64-bit Apache stack for Solaris 10:
http://www.cse.psu.edu/~groenvel/apache2.html>
Some modperl and libapreq2 tests are failing, but not core dumping.

John
groenv...@acm.org

Filter out error log by IP address?

[Michael A. Capone]

Hello,

I'm not sure this is a mod_perl question per se, but I'm hoping there's 
a mod_perl solution to our problem.


We currently use a 3rd party security company to do a nessus-type 
security audit on our site for PCI compliance.  Their scans naturally 
generate a lot of noise in the error log, to the point that legitimate 
site errors are lost in the forest.  What I'm hoping to find / create is 
some kind of mechanism that can pre-empt writing to the error log and 
either 1) ideally, don't log if the client IP is xxx.xxx.xxx.xxx, or 2) 
always log the client IP address with each error, which will enable us 
to filter those out manually after the fact.  Either solution is acceptable.


Apache provides a trivial solution for the access_log, in the form of:

   SetEnvIf Remote_Addr xxx.xxx.xxx.* nolog

... however, that solution does not extend to the error log.  I'm hoping 
there's a mod_perl "hook" that can allow me to change apache's error 
logging behaviour to what I need it to be.


Can someone point me in the right direction?