mod_perl2 timely catching SIGPIPE

[Jim Albert]

I'm trying to determine how to have my mod_perl apache server properly 
catch a SIGPIPE signal in a timely manner.

My environment is Apache/2.0.49 (Fedora) and mod_perl 2.
In my conf.d/perl.conf file I have the following:
PerlFixupHandler Apache::SIG2
I have created Apache::SIG2.pm as follows:
--
package Apache::SIG2;
use strict;
use Apache::RequestRec;
use Apache::Const;
sub handler {
my $r = shift;
if (!$r->main) {
print STDERR ("In handler\n");
$SIG{PIPE} = \&PIPE;
}
return OK;
}
sub PIPE {
 my($signal) = @_;
 print STDERR ("signal caught = $signal\n");
}
1;
--
For ease of tracing, I have set up my apache environment so as to have 
only one mod_perled httpd child running.

When an httpd request is made, I see "In handler" so I know that a 
SIGPIPE signal should be caught.

However, when I cause a condition that generates a SIGPIPE, such as 
pressing the browser stop button, my SIGPIPE handler, PIPE, is not 
immediately called.  Strangely, PIPE is called the next time a new httpd 
request is handled by this same httpd child.  I ran my httpd server with 
strace and I do see the following at the time the connection is broken:
--- SIGPIPE (Broken pipe) @ 0 (0) ---
so the SIGPIPE is being generated at the appropriate time, but the 
mod_perled httpd child is not detecting it (or at least not executing my 
signal handler routine) until the next httpd request.

The http request I make to test this is a non_modperl CGI generating 
lots of output with autoflush turned on ($|=1) so that there is plenty 
of output being sent over the pipe that will be broken by me clicking 
the browser stop button.

Under Apache/1.3.27 and mod_perl/1.27 I had a very similar 
PerlFixupHandler in place (a slightly modified Apache::SIG.pm) to catch 
a SIGPIPE and the SIGPIPE was caught and my signal handler executed at 
the correct time... when the connection was broken by the browser.  I 
would like to be able to continue to catch a SIGPIPE like this under 
Apache2/modperl2.  Can anyone offer any suggestions as to how to get my 
signal handler, PIPE, executed as soon as the SIGPIPE is generated?

Thanks
Jim Albert

--
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_perl2 timely catching SIGPIPE

[Jim Albert]

Stas Bekman wrote:
Jim Albert wrote:
I'm trying to determine how to have my mod_perl apache server properly 
catch a SIGPIPE signal in a timely manner.

My environment is Apache/2.0.49 (Fedora) and mod_perl 2.

Jim, please *always* report bugs and problems following these guidelines!
http://perl.apache.org/bugs/
and save yourself and us time. Thank you!
In my conf.d/perl.conf file I have the following:
PerlFixupHandler Apache::SIG2
[...]
Under Apache/1.3.27 and mod_perl/1.27 I had a very similar 
PerlFixupHandler in place (a slightly modified Apache::SIG.pm) to 
catch a SIGPIPE and the SIGPIPE was caught and my signal handler 
executed at the correct time... when the connection was broken by the 
browser.  I would like to be able to continue to catch a SIGPIPE like 
this under Apache2/modperl2.  Can anyone offer any suggestions as to 
how to get my signal handler, PIPE, executed as soon as the SIGPIPE is 
generated?

What perl version are you using now (and which one have you used with 
1.3.x?) (which you were supposed to sent as a part of the bug report).
In my mod_perl environment (Apache 1.3 / mod_perl 1.27) where my perl 
handler catches and immediately handles the SIGPIPE I am using perl 5.6.1.

In my mod_perl environment (Apache2.0.49 / mod_perl 2) where my perl 
handler properly catches the SIGPIPE, but does not handle it immediately 
I am using perl 5.8.3.


I 
don't think this has anything to do with what mod_perl version you are 
using.
>
> Starting from 5.8.0 perl delays signal delivery, making signals safe.
[...]
Stas, you are absolutely correct... thanks a lot!  I added the following 
line to my server_startup.pl (Apache2.0.49 / mod_perl 2) which gets 
included from my conf.d/perl.conf file:
$ENV{PERL_SIGNALS} = "unsafe";

With that line in place, my PerlFixupHandler now catches a SIGPIPE and 
immediately executes the SIGPIPE signal handler.

I hadn't had any significant problem that I noticed using "unsafe" 
signals in the past and  I need the functionality that "unsafe" signals 
provide me, so I'm going to go with "unsafe" signals in my 
apache2/mod_perl2/perl5.8 environment.

Please let us know which technique has worked for you and it'd be great 
to have a section documenting this area, including full examples as in 
your original bug report.
I've been researching this problem for several days so I'm anxious to 
get an Apache2/mod_perl2 system into production now that I have a 
solution.  When I get some time I'll post a detailed explanation of this 
problem with examples to this mailing list.

Jim Albert

--
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

perl 5.8 safe signals and broken pipes in apache

[Jim Albert]

Last week I had a problem where I could not get my 
Apache2/mod_perl2/perl5.8.3 web server to catch a SIGPIPE signal in a 
timely manner.  I was asked to post a description of this problem and 
solution to this list so that it might be included in future mod_perl 
documentation.

Feel free to adjust this description as necessary when integrating it 
into the appropriate documentation.

The Problem:
Use a PerlFixupHandler to catch when the pipe from browser to httpd 
server has been broken such as when the user presses the browser stop 
button.

In conf.d/perl.conf
PerlFixupHandler Apache::SIG2
where Apache::SIG2.pm is defined in this example as:
--
package Apache::SIG2;
# This package adapted by Jim Albert from the original mod_perl1
# Apache::SIG.pm by Doug MacEachern and Doug Bagley
# This PerlHandler can be used to prevent httpd children from killing
# off non-mod-perled CGIs when the user presses the Stop button.
use strict;
use Apache::RequestRec;
use ModPerl::Util;
use Apache::Const;
sub handler {
my $r = shift;
if (!$r->main) {
$SIG{PIPE} = \&PIPE;
}
   return OK;
}
sub PIPE {
   my($signal) = @_;
   print STDERR ("User pressed stop button.\n");
   # Kill off the httpd child before it can kill any running CGIs.
   # Or do whatever other cleanup is appropriate.
   CORE::exit();
}
1;
--
With the introduction of perl 5.8.0, this handler no longer works as 
expected because of the introduction of perl safe signals.
See:
http://www.perldoc.com/perl5.8.4/pod/perlipc.html#Deferred-Signals-(Safe-Signals)

What happens with perl 5.8 and safe signals is that the apache httpd 
child does receive the SIGPIPE, but it is delayed and the perl CGI 
program has already been killed.  The httpd child does not act on the 
SIGPIPE until it receives the next httpd request.

The Solution:
An Apache server_startup.pl script can be used to turn off perl safe 
signals with the following line:
$ENV{PERL_SIGNALS} = "unsafe";
The server_startup.pl script can be included via the following line in 
perl.conf:
PerlRequire conf/server_startup.pl
The ability to revert back to "unsafe" signals is available as of perl 
5.8.1.

--
Jim Albert

--
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 5.8 safe signals and broken pipes in apache

[Jim Albert]

Great! It's always nice to have multiple solutions to a problem.  I 
believe Stas Bekman also pointed to the POSIX sigaction solution when he 
first pointed me in the right direction in solving this problem, but 
setting $ENV{PERL_SIGNALS} = "unsafe"; got me going with perl 5.8 very 
quickly.

I might give the POSIX sigaction solution a try myself since I too 
wasn't incredibly comfortable with resorting to old signal handling for 
my entire httpd servers.  My guess is that your POSIX sigaction solution 
would work with perl5.8.0 unlike the $ENV{PERL_SIGNALS} solution which 
is not supported until perl5.8.1.

Assuming your solution also solves this problem, it should also be 
included in any documentation regarding "safe signals" and apache/mod_perl.

Eric wrote:
Jim,
Thank you! This was a big help to me in that I ran into this problem from two directions recently, with a perl daemon and with Apache::SIG.. I did find some info about fixing this for real rather than using unsafe signals. They mostly seemed to point to using the POSIX sigaction methods rather Perl's. 

I did end up getting my daemon to work without either dying after the first command or spawning endless children that would not die, those were my two choices before :) Only a part of this was related to the signal problem, but it was the hard part for a while. 

The child signal was what was causing me big problems. I know this is far from a complete answer, but I hope it might send someone off on the right path if they don't want to set the ENV var. I was worried about doing it that way, because what happens a year from now when I upgrade my server and we somehow forget about that little detail?  I know me and I will manage to mess it up if I can :) 

Below are some examples from the POSIX module, it should work :). I found most of this 
somewhere when doing research on perl daemons but the child one I added on and I am 
currently using all of the below, I just did some cutting of other things.
use POSIX ();
use POSIX 'WNOHANG';
use FindBin ();
use File::Basename ();
use File::Spec::Functions;
my $script = File::Basename::basename($0);
my $SELF = catfile $FindBin::Bin, $script; 

my $sigset = POSIX::SigSet->new();
  my $action = POSIX::SigAction->new('sigHUP_handler',
 $sigset,
 &POSIX::SA_NODEFER);
  my $action_alrm = POSIX::SigAction->new('sigALRM_handler',
 $sigset,
 &POSIX::SA_NODEFER);  
  my $action_child = POSIX::SigAction->new('sigCHLD_handler',
 $sigset,
 &POSIX::SA_NODEFER);  
 
  POSIX::sigaction(&POSIX::SIGHUP, $action);
  POSIX::sigaction(&POSIX::SIGALRM, $action_alrm);
  POSIX::sigaction(&POSIX::SIGCHLD, $action_child);
  
  sub sigHUP_handler {
  print "got SIGHUP\n";
  exec($SELF, @ARGV) or die "Couldn't restart: $!\n";
  }
  sub sigALRM_handler {
  print "got ALARM timeout\n";

  }
  sub sigCHLD_handler {
  while (my $reaperpid = waitpid(-1,WNOHANG)>0) {
  }
  }

## do your while (1) and  fork etc... 


I wish I could paste in my whole daemon thing, but it is too far along with to many things specific to my bosses application.. 

Thanks,
Eric 

At 02:55 PM 6/15/2004, Jim Albert wrote:
Last week I had a problem where I could not get my Apache2/mod_perl2/perl5.8.3 web 
server to catch a SIGPIPE signal in a timely manner.  I was asked to post a 
description of this problem and solution to this list so that it might be included in 
future mod_perl documentation.
Feel free to adjust this description as necessary when integrating it into the 
appropriate documentation.
The Problem:
Use a PerlFixupHandler to catch when the pipe from browser to httpd server has been 
broken such as when the user presses the browser stop button.
In conf.d/perl.conf
PerlFixupHandler Apache::SIG2
where Apache::SIG2.pm is defined in this example as:
--
package Apache::SIG2;
# This package adapted by Jim Albert from the original mod_perl1
# Apache::SIG.pm by Doug MacEachern and Doug Bagley
# This PerlHandler can be used to prevent httpd children from killing
# off non-mod-perled CGIs when the user presses the Stop button.
use strict;
use Apache::RequestRec;
use ModPerl::Util;
use Apache::Const;
sub handler {
  my $r = shift;
  if (!$r->main) {
  $SIG{PIPE} = \&PIPE;
  }
 return OK;
}
sub PIPE {
 my($signal) = @_;
 print STDERR ("User pressed stop button.\n");
 # Kill off the httpd child before it can kill any running CGIs.
 # Or do whatever other cleanup is appropriate.
 CORE::exit();
}
1;
--
With the introduction

Re: perl 5.8 safe signals and broken pipes in apache

[Jim Albert]

Stas Bekman wrote:
Eric Frazier wrote:
Jim, Eric, so can you please put this thread together into one doc piece 
that can be added to the docs?


I had just noticed that I received none of the mod_perl mailings in the 
past 10 days or so.  Looks like the mod_perl list mail server is on a 
spam blacklist.

relay=hermes.apache.org [209.237.227.199]
Rejected from 209.237.227.199 - see http://spews.org/bounce.html
I understand spews is one of the more aggressive blacklists, but perhaps 
one the list admins should look into getting this IP out of spews?

--
Jim Albert

--
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 5.8 safe signals and broken pipes in apache

[Jim Albert]

Stas Bekman wrote:
Jim Albert wrote:
Stas Bekman wrote:
Eric Frazier wrote:
Jim, Eric, so can you please put this thread together into one doc 
piece that can be added to the docs?


I had just noticed that I received none of the mod_perl mailings in 
the past 10 days or so.  Looks like the mod_perl list mail server is 
on a spam blacklist.

relay=hermes.apache.org [209.237.227.199]
Rejected from 209.237.227.199 - see http://spews.org/bounce.html
I understand spews is one of the more aggressive blacklists, but 
perhaps one the list admins should look into getting this IP out of 
spews?

This issue was raised on the apache infrastructure list and someone told 
that one shouldn't even bother to do that, because of the draconian 
rules spews.org uses (I'm just repeating their words) and I guess the 
admins aren't going to do that. Therefore there is nothing we can do 
about it. I suppose you could contact infrastructure #at# apache.org.

Not a big deal; one can always allow access to a particular server on 
their own mail server if they decide to trust the server. If the admins 
don't want to make an attempt to get the IP pulled out of spews, I 
wouldn't push it.

--
Jim Albert

--
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: automatically restart httpd

[Jim Albert]

On 4/23/2013 11:49 AM, Ryan Perry wrote:

I've been plagued by some bug that makes a call to LWP stop working:
"Can't connect to 192.168.0.222 (Bad hostname)"

I haven't been able to figure out why, but a simple httpd restart fixes
it for a day or 2.

Since I can't figure out a real fix, I'm wondering if there is a way for
me to automatically restart httpd whenever the bug hits.  Maybe whenever
it appears in the httpd-error.log?  What are my options?


Without more to go on to the actual cause of the problem...

Restarting apache daily isn't a bad idea in general if even just a 
graceful restart.

kill -USR1 `cat /var/run/httpd.pid`
which I believe should be safe any time of day.

If a complete restart, maybe early morning off hours assuming your 
server requires a high degree of availability?


Jim

Re: automatically restart httpd

[Jim Albert]

On 4/23/2013 1:08 PM, Ryan Perry wrote:

I've considered doing it daily via cron, but if there's a way to do when
I hit this error I'd prefer that.


On Tue, Apr 23, 2013 at 12:02 PM, Jim Albert mailto:j...@netrition.com>> wrote:

On 4/23/2013 11:49 AM, Ryan Perry wrote:

I've been plagued by some bug that makes a call to LWP stop working:
"Can't connect to 192.168.0.222 (Bad hostname)"

I haven't been able to figure out why, but a simple httpd
restart fixes
it for a day or 2.

Since I can't figure out a real fix, I'm wondering if there is a
way for
me to automatically restart httpd whenever the bug hits.  Maybe
whenever
it appears in the httpd-error.log?  What are my options?


Without more to go on to the actual cause of the problem...

Restarting apache daily isn't a bad idea in general if even just a
graceful restart.
kill -USR1 `cat /var/run/httpd.pid`
which I believe should be safe any time of day.

If a complete restart, maybe early morning off hours assuming your
server requires a high degree of availability?

Jim


Try to remember not to top-post, please. It makes it hard for others to 
read the thread.


I don't know, but it kind of has a DNS feel to it, possibly. Nothing 
concrete to go on, just past experience when I see network and I know 
the network is fine... I think DNS. Maybe reverse resolution of your 
private IP address space assuming your requests are being made to/from 
private addresses? That's really just a shot in the dark because we 
don't have much to go on. I'd start thinking network and DNS, put in 
some debug, see what if anything is timing out.


Jim

Re: automatically restart httpd

[Jim Albert]

On 4/23/2013 1:36 PM, Ryan Perry wrote:




On Tue, Apr 23, 2013 at 12:23 PM, Jim Albert mailto:j...@netrition.com>> wrote:

On 4/23/2013 1:08 PM, Ryan Perry wrote:

I've considered doing it daily via cron, but if there's a way to
do when
I hit this error I'd prefer that.


On Tue, Apr 23, 2013 at 12:02 PM, Jim Albert mailto:j...@netrition.com>
<mailto:j...@netrition.com <mailto:j...@netrition.com>>> wrote:

 On 4/23/2013 11:49 AM, Ryan Perry wrote:

 I've been plagued by some bug that makes a call to LWP
stop working:
 "Can't connect to 192.168.0.222 (Bad hostname)"

 I haven't been able to figure out why, but a simple httpd
 restart fixes
 it for a day or 2.

 Since I can't figure out a real fix, I'm wondering if
there is a
 way for
 me to automatically restart httpd whenever the bug
hits.  Maybe
 whenever
 it appears in the httpd-error.log?  What are my options?


 Without more to go on to the actual cause of the problem...

 Restarting apache daily isn't a bad idea in general if even
just a
 graceful restart.
 kill -USR1 `cat /var/run/httpd.pid`
 which I believe should be safe any time of day.

 If a complete restart, maybe early morning off hours
assuming your
 server requires a high degree of availability?

 Jim


Try to remember not to top-post, please. It makes it hard for others
to read the thread.

I don't know, but it kind of has a DNS feel to it, possibly. Nothing
concrete to go on, just past experience when I see network and I
know the network is fine... I think DNS. Maybe reverse resolution of
your private IP address space assuming your requests are being made
to/from private addresses? That's really just a shot in the dark
because we don't have much to go on. I'd start thinking network and
DNS, put in some debug, see what if anything is timing out.

Jim


Sorry about the top post.

I've done the debugging on DNS.  If it try changing the IP/hostname I
still get the error.  I think it's per-process though.  Once it starts
to happen it's intermittent and gets worse, making me think depending
which process I hit it will work or not until all processes are affected.

This is on FreeBSD using a jailed (virtualized) host.  I read about
apache/jails on OpenBSD having a config issue with DNS but it seemed
different than this.

It only seems to affect httpd, I can log in and ping from the server
just fine.


Also, please reply to the list, not personal email addresses so everyone 
else gets the benefit of the thread, and maybe you get a better answer 
from someone other than me. :)


I'm not so sure you've eliminated DNS, yet.

What if from 192.168.0.222 you:
dig -x 192.168.0.x

where 192.168.0.x is the IP addressing making the connection to 
192.168.0.222


Do you have reverse resolvers for your private address space or are the 
requests handled by the top level root servers?


Who is answering for that reverse resolution request?
dig -x 192.168.0.x
Is it your resolver or a root level like prisoner.iana.org

Jim

Re: automatically restart httpd

[Jim Albert]

On 4/23/2013 2:33 PM, Ryan Perry wrote:




On Tue, Apr 23, 2013 at 12:47 PM, Jim Albert mailto:j...@netrition.com>> wrote:

On 4/23/2013 1:36 PM, Ryan Perry wrote:




On Tue, Apr 23, 2013 at 12:23 PM, Jim Albert mailto:j...@netrition.com>
<mailto:j...@netrition.com <mailto:j...@netrition.com>>> wrote:

 On 4/23/2013 1:08 PM, Ryan Perry wrote:

 I've considered doing it daily via cron, but if there's
a way to
 do when
 I hit this error I'd prefer that.


     On Tue, Apr 23, 2013 at 12:02 PM, Jim Albert
mailto:j...@netrition.com>
 <mailto:j...@netrition.com <mailto:j...@netrition.com>>
 <mailto:j...@netrition.com <mailto:j...@netrition.com>
<mailto:j...@netrition.com <mailto:j...@netrition.com>>>> wrote:

  On 4/23/2013 11:49 AM, Ryan Perry wrote:

  I've been plagued by some bug that makes a
call to LWP
 stop working:
  "Can't connect to 192.168.0.222 (Bad hostname)"

  I haven't been able to figure out why, but a
simple httpd
  restart fixes
  it for a day or 2.

  Since I can't figure out a real fix, I'm
wondering if
 there is a
  way for
  me to automatically restart httpd whenever the bug
 hits.  Maybe
  whenever
  it appears in the httpd-error.log?  What are
my options?


  Without more to go on to the actual cause of the
problem...

  Restarting apache daily isn't a bad idea in
general if even
 just a
  graceful restart.
  kill -USR1 `cat /var/run/httpd.pid`
  which I believe should be safe any time of day.

  If a complete restart, maybe early morning off hours
 assuming your
  server requires a high degree of availability?

  Jim


 Try to remember not to top-post, please. It makes it hard
for others
 to read the thread.

 I don't know, but it kind of has a DNS feel to it,
possibly. Nothing
 concrete to go on, just past experience when I see network
and I
 know the network is fine... I think DNS. Maybe reverse
resolution of
 your private IP address space assuming your requests are
being made
 to/from private addresses? That's really just a shot in the
dark
 because we don't have much to go on. I'd start thinking
network and
 DNS, put in some debug, see what if anything is timing out.

 Jim


Sorry about the top post.

I've done the debugging on DNS.  If it try changing the
IP/hostname I
still get the error.  I think it's per-process though.  Once it
starts
to happen it's intermittent and gets worse, making me think
depending
which process I hit it will work or not until all processes are
affected.

This is on FreeBSD using a jailed (virtualized) host.  I read about
apache/jails on OpenBSD having a config issue with DNS but it seemed
different than this.

It only seems to affect httpd, I can log in and ping from the server
just fine.


Also, please reply to the list, not personal email addresses so
everyone else gets the benefit of the thread, and maybe you get a
better answer from someone other than me. :)

I'm not so sure you've eliminated DNS, yet.

What if from 192.168.0.222 you:
dig -x 192.168.0.x

where 192.168.0.x is the IP addressing making the connection to
192.168.0.222

Do you have reverse resolvers for your private address space or are
the requests handled by the top level root servers?

Who is answering for that reverse resolution request?
dig -x 192.168.0.x
Is it your resolver or a root level like prisoner.iana.org
<http://prisoner.iana.org>

Jim


Interesting, but it seems hard to believe that would be it.  I don't
have any other suspects though...


; <<>> DiG 9.8.3-P3 <<>> -x 192.168.0.200
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20209
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;200.0.168.192.in-addr.arpa.INPTR

;; AUTHORITY SECTION:
168.192.in-a

Re: automatically restart httpd

[Jim Albert]

On 4/23/2013 3:09 PM, Jim Albert wrote:

On 4/23/2013 2:33 PM, Ryan Perry wrote:




On Tue, Apr 23, 2013 at 12:47 PM, Jim Albert mailto:j...@netrition.com>> wrote:

On 4/23/2013 1:36 PM, Ryan Perry wrote:




On Tue, Apr 23, 2013 at 12:23 PM, Jim Albert mailto:j...@netrition.com>
<mailto:j...@netrition.com <mailto:j...@netrition.com>>> wrote:

 On 4/23/2013 1:08 PM, Ryan Perry wrote:

 I've considered doing it daily via cron, but if there's
a way to
 do when
 I hit this error I'd prefer that.


     On Tue, Apr 23, 2013 at 12:02 PM, Jim Albert
mailto:j...@netrition.com>
 <mailto:j...@netrition.com <mailto:j...@netrition.com>>
 <mailto:j...@netrition.com <mailto:j...@netrition.com>
<mailto:j...@netrition.com <mailto:j...@netrition.com>>>> wrote:

  On 4/23/2013 11:49 AM, Ryan Perry wrote:

  I've been plagued by some bug that makes a
call to LWP
 stop working:
  "Can't connect to 192.168.0.222 (Bad hostname)"

  I haven't been able to figure out why, but a
simple httpd
  restart fixes
  it for a day or 2.

  Since I can't figure out a real fix, I'm
wondering if
 there is a
  way for
  me to automatically restart httpd whenever
the bug
 hits.  Maybe
  whenever
  it appears in the httpd-error.log?  What are
my options?


  Without more to go on to the actual cause of the
problem...

  Restarting apache daily isn't a bad idea in
general if even
 just a
  graceful restart.
  kill -USR1 `cat /var/run/httpd.pid`
  which I believe should be safe any time of day.

  If a complete restart, maybe early morning off
hours
 assuming your
  server requires a high degree of availability?

  Jim


 Try to remember not to top-post, please. It makes it hard
for others
 to read the thread.

 I don't know, but it kind of has a DNS feel to it,
possibly. Nothing
 concrete to go on, just past experience when I see network
and I
 know the network is fine... I think DNS. Maybe reverse
resolution of
 your private IP address space assuming your requests are
being made
 to/from private addresses? That's really just a shot in the
dark
 because we don't have much to go on. I'd start thinking
network and
 DNS, put in some debug, see what if anything is timing out.

 Jim


Sorry about the top post.

I've done the debugging on DNS.  If it try changing the
IP/hostname I
still get the error.  I think it's per-process though.  Once it
starts
to happen it's intermittent and gets worse, making me think
depending
which process I hit it will work or not until all processes are
affected.

This is on FreeBSD using a jailed (virtualized) host.  I read
about
apache/jails on OpenBSD having a config issue with DNS but it
seemed
different than this.

It only seems to affect httpd, I can log in and ping from the
server
just fine.


Also, please reply to the list, not personal email addresses so
everyone else gets the benefit of the thread, and maybe you get a
better answer from someone other than me. :)

I'm not so sure you've eliminated DNS, yet.

What if from 192.168.0.222 you:
dig -x 192.168.0.x

where 192.168.0.x is the IP addressing making the connection to
192.168.0.222

Do you have reverse resolvers for your private address space or are
the requests handled by the top level root servers?

Who is answering for that reverse resolution request?
dig -x 192.168.0.x
Is it your resolver or a root level like prisoner.iana.org
<http://prisoner.iana.org>

Jim


Interesting, but it seems hard to believe that would be it.  I don't
have any other suspects though...


; <<>> DiG 9.8.3-P3 <<>> -x 192.168.0.200
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20209
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;200.0.168.192.in-addr.arp

Re: automatically restart httpd

[Jim Albert]

On 4/23/2013 3:27 PM, Ryan Perry wrote:




On Tue, Apr 23, 2013 at 2:09 PM, Jim Albert mailto:j...@netrition.com>> wrote:

On 4/23/2013 2:33 PM, Ryan Perry wrote:




On Tue, Apr 23, 2013 at 12:47 PM, Jim Albert mailto:j...@netrition.com>
<mailto:j...@netrition.com <mailto:j...@netrition.com>>> wrote:

 On 4/23/2013 1:36 PM, Ryan Perry wrote:




 On Tue, Apr 23, 2013 at 12:23 PM, Jim Albert
mailto:j...@netrition.com>
 <mailto:j...@netrition.com <mailto:j...@netrition.com>>
 <mailto:j...@netrition.com <mailto:j...@netrition.com>
<mailto:j...@netrition.com <mailto:j...@netrition.com>>>> wrote:

  On 4/23/2013 1:08 PM, Ryan Perry wrote:

  I've considered doing it daily via cron, but
if there's
 a way to
  do when
  I hit this error I'd prefer that.


  On Tue, Apr 23, 2013 at 12:02 PM, Jim Albert
 mailto:j...@netrition.com>
<mailto:j...@netrition.com <mailto:j...@netrition.com>>
  <mailto:j...@netrition.com
<mailto:j...@netrition.com> <mailto:j...@netrition.com
<mailto:j...@netrition.com>>>
  <mailto:j...@netrition.com
<mailto:j...@netrition.com> <mailto:j...@netrition.com
<mailto:j...@netrition.com>>
 <mailto:j...@netrition.com <mailto:j...@netrition.com>
<mailto:j...@netrition.com <mailto:j...@netrition.com>>>>> wrote:

   On 4/23/2013 11:49 AM, Ryan Perry wrote:

   I've been plagued by some bug that
makes a
 call to LWP
  stop working:
   "Can't connect to 192.168.0.222 (Bad
hostname)"

   I haven't been able to figure out
why, but a
 simple httpd
   restart fixes
   it for a day or 2.

   Since I can't figure out a real fix, I'm
 wondering if
  there is a
   way for
   me to automatically restart httpd
whenever the bug
  hits.  Maybe
   whenever
   it appears in the httpd-error.log?
  What are
 my options?


   Without more to go on to the actual cause
of the
 problem...

   Restarting apache daily isn't a bad idea in
 general if even
  just a
   graceful restart.
   kill -USR1 `cat /var/run/httpd.pid`
   which I believe should be safe any time
of day.

   If a complete restart, maybe early
morning off hours
  assuming your
   server requires a high degree of
availability?

   Jim


  Try to remember not to top-post, please. It makes
it hard
 for others
  to read the thread.

  I don't know, but it kind of has a DNS feel to it,
 possibly. Nothing
  concrete to go on, just past experience when I see
network
 and I
  know the network is fine... I think DNS. Maybe reverse
 resolution of
  your private IP address space assuming your
requests are
 being made
  to/from private addresses? That's really just a
shot in the
 dark
  because we don't have much to go on. I'd start
thinking
 network and
  DNS, put in some debug, see what if anything is
timing out.

  Jim


 Sorry about the top post.

 I've done the debugging on DNS.  If it try changing the
 IP/hostname I
 still get the error.  I think it's per-process though.
  Once it
 starts
 to happen it's intermittent and gets worse, making me think
 depending
 which process I hit it will work or not until all
processes 

Re: [DISCUSS] The future of mod_perl

[Jim Albert]

Not that I want to be the guy that says it sounds like we'll be pulling 
the mod_perl plug at any time the right scenario arises, but is it 
reasonable to have a discussion here on mod_perl alternatives inline 
with the various means of using mod_perl from the low level means of 
interfacing with the Apache server to the quick and dirty stuff 
(ModPerl::PerlRun, I believe to keep Perl and modules in memory).


For those drawing the same conclusions from this thread as me, I've seen 
mod_fcgid proposed as an alternative, but I haven't yet played with it. 
Anyone with similar thoughts would ideally be looking for something that 
doesn't require months of redeveloping to a proposed replacement to 
mod_perl.


I like mod_perl and it does a good job for what I use it for, but if we 
have no one developing, it sounds like we're waiting for the catalyst to 
come along that puts and end to it. EG.. some future Apache 
incompatibility.  I'd really like someone with mod_perl authority to 
tell me I'm wrong, but my take on Adam's reply pretty much leaves me 
with that conclusion. I don't see another way to draw a better conclusion.


Jim

On 3/17/2021 8:52 PM, Adam Prime wrote:
The projects current state is that no new development happening. This 
isn't to say that new development shouldn't happen, but it isn't. 
Apache and Perl both continue to move forward, and we are pretty lucky 
that the design that Stas, Phillipe, Geoff, etc built mod_perl 2 under 
is resilient enough to continue to despite the changes that both of 
these projects have made.


So, if the goal of the PMC is to maintain the status quo, then there 
is essentially no time required, aside from someone needing to file a 
report every few months saying that nothing has happened, and there 
were no releases. Things can only remain that way as long as there are 
no security problems that affect mod_perl, and neither Apache or Perl 
do anything that really breaks mod_perl.


Adam

On 3/17/2021 6:10 PM, Geoff Mottram wrote:

All,

I would certainly hate to see mod_perl no longer being maintained. I 
use it as a front-end for a library cataloging system that is very 
much alive, in-use and updated with recent HTML, CSS and JavaScript 
features. Rewriting this front-end in some other language would be a 
huge undertaking and would not provide much benefit because Apache + 
Perl + mod_perl not only do the job but do it extremely well.


While I don't understand what type of time commitment would be 
required, I would be happy to add my name to the bottom of any list 
should others have a strong desire to hold such a position.


Best,

Geoff Mottram

On 3/17/2021 3:40 PM, Sander Striker wrote:

Dear community members,

As projects mature, they will naturally reach a point where activity 
reduces to a level such that the project is no longer sustainable.  
At Apache, projects reach this stage when there are not at least 3 
active PMC members providing oversight. Projects that reach this 
stage are usually placed in the Attic [1] or absorbed by another 
Apache project willing to manage its releases.


If you are interested in seeing mod_perl remain an active project, 
and are able to help maintain and provide oversight, please respond 
in this thread indicating that you are interested in performing the 
duties of a PMC member[2].


Cheers,

Sander Striker
Director, The Apache Software Foundation

[1] https://attic.apache.org/ 
[2] https://www.apache.org/dev/pmc.html 





-
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org

Re: [DISCUSS] The future of mod_perl

[Jim Albert]

Sure... I'll start a new thread after I reply here.

I don't know about how apache projects are maintained and the logistics, 
but there are two issues here.
Foremost... from your previous response you need a few people to step up 
and file your described report indicating no new releases, but that's 
not necessarily a developer and it doesn't sound involved. I expect 
you'll get some volunteers.


However, aside from that is the bigger issue of you stated there are no 
developers maintaining mod_perl. That's the big red flag in this. Should 
some vulnerability be discovered or a future Apache release present some 
compatibility issue... maybe someone steps up and provides a fix... 
that's a big maybe.


Jim

On 3/17/2021 10:39 PM, Adam Prime wrote:
I think if you want to discuss alternatives, then a new thread would 
be the place to do that.


With regards to plug being pulled, I think that it is up to the 
community if, when, and how that happens. That's what the point of 
this thread is. If there aren't people that are committed enough to 
the project for whatever reason to step up and keep it from going to 
the attic, then that's what will happen.


Adam



On 3/17/2021 9:50 PM, Jim Albert wrote:
Not that I want to be the guy that says it sounds like we'll be 
pulling the mod_perl plug at any time the right scenario arises, but 
is it reasonable to have a discussion here on mod_perl alternatives 
inline with the various means of using mod_perl from the low level 
means of interfacing with the Apache server to the quick and dirty 
stuff (ModPerl::PerlRun, I believe to keep Perl and modules in memory).


For those drawing the same conclusions from this thread as me, I've 
seen mod_fcgid proposed as an alternative, but I haven't yet played 
with it. Anyone with similar thoughts would ideally be looking for 
something that doesn't require months of redeveloping to a proposed 
replacement to mod_perl.


I like mod_perl and it does a good job for what I use it for, but if 
we have no one developing, it sounds like we're waiting for the 
catalyst to come along that puts and end to it. EG.. some future 
Apache incompatibility.  I'd really like someone with mod_perl 
authority to tell me I'm wrong, but my take on Adam's reply pretty 
much leaves me with that conclusion. I don't see another way to draw 
a better conclusion.


Jim

mod_perl alternatives

[Jim Albert]

Given the recent discussion on the need for mod_perl PMC members and the 
disclosure that there is no active development on mod_perl this seems 
like an appropriate time to start a thread on a discussion of mod_perl 
alternatives inline with the various means of using mod_perl from the 
low level use of interfacing with the Apache server to the quick and 
dirty stuff (ModPerl::PerlRun, I believe to keep Perl and modules in 
memory).


I've seen mod_fcgid proposed in posts on other forums. Has anyone played 
with alternatives? I expect the low level Apache interaction might be 
difficult to duplicate at least to continue to do so in Perl. Perhaps 
the ModPerl::PerlRun approach of keeping Perl and modules in memory is a 
potential starting point for discussion for those using mod_perl at the 
most basic level.


Jim

Re: [DISCUSS] The future of mod_perl

[Jim Albert]

Thanks for the thorough response, Fred.
At some point before mod_perl stops having any development support would 
you expect an End Of Life announcement with reasonable advanced notice?


I haven't followed discussion or announcements on other Apache modules 
to know how modules normally reach their end. Is it structured or do 
some just suddenly disappear?


Jim


On 3/18/2021 1:05 AM, Fred Moyer wrote:

Longer response here.

So I'm happy to be another active PMC member still involved. As
someone with a growing family, my time is limited, but not too much to
review and lend a +1 or feedback. I think that may be the case for a
few of the folks on this list. I'd like to see Steve Hay lead the
future of mod_perl project as I know a lot of the old guard have
personal duties now that take precedence.

mod_perl is not a new Apache project. It's approaching two decades,
close to the age of the Apache httpd project itself. It was a core
driver in developing my career in software, as well as many key
professional relationships associated there. I remember a *lot* of
weekends early in my career hacking on mod_perl for *fun* - the coding
was the reward, as well as the community feedback.

There are still many shops out there using mod_perl, but not much new
development, which makes sense. The project is in maintenance mode,
and there are developers willing to support needed releases as Adam
mentioned. If you are developing a new project, you should not use
mod_perl. But if you are maintaining legacy mod_perl infrastructure,
we will not leave you behind.

The open source project model has changed significantly, especially
over the last ten years. IMHO, while the ASF model was instrumental in
the rise of open source projects into commercial environments, more
recent approaches such as those supported by the Linux Foundation
(which is *definitely* more commercially supported, and reflected by
the platitude of industry sponsors and resources) have achieved
greater growth levels in the short term. Will they still be here in 20
years? No idea.

A takeaway from my reflections there is that the ASF can benefit from
a bit less formality in structure to keep up with the new kids on the
block. I'm just a mostly inactive PMC member, but I think it's clear
that the project rules are preventing us keeping up with the needed
leadership changes.

On Wed, Mar 17, 2021 at 8:02 PM Fred Moyer  wrote:

Happy to continue being a maintainer. Longer response coming soon :)

On Wed, Mar 17, 2021, 7:39 PM Adam Prime  wrote:

I think if you want to discuss alternatives, then a new thread would be
the place to do that.

With regards to plug being pulled, I think that it is up to the
community if, when, and how that happens. That's what the point of this
thread is. If there aren't people that are committed enough to the
project for whatever reason to step up and keep it from going to the
attic, then that's what will happen.

Adam



On 3/17/2021 9:50 PM, Jim Albert wrote:

Not that I want to be the guy that says it sounds like we'll be pulling
the mod_perl plug at any time the right scenario arises, but is it
reasonable to have a discussion here on mod_perl alternatives inline
with the various means of using mod_perl from the low level means of
interfacing with the Apache server to the quick and dirty stuff
(ModPerl::PerlRun, I believe to keep Perl and modules in memory).

For those drawing the same conclusions from this thread as me, I've seen
mod_fcgid proposed as an alternative, but I haven't yet played with it.
Anyone with similar thoughts would ideally be looking for something that
doesn't require months of redeveloping to a proposed replacement to
mod_perl.

I like mod_perl and it does a good job for what I use it for, but if we
have no one developing, it sounds like we're waiting for the catalyst to
come along that puts and end to it. EG.. some future Apache
incompatibility.  I'd really like someone with mod_perl authority to
tell me I'm wrong, but my take on Adam's reply pretty much leaves me
with that conclusion. I don't see another way to draw a better conclusion.

Jim

Issues with Environment Variables

[Jim Albert]

Under mod_perl1 I had a mod_perled program that opened a pipe to a 
standard CGI and recorded its output.

I did this in my mod_perl program by setting the following ENV vars:
$ENV{"QUERY_STRING"}
$ENV{"REQUEST_METHOD"}
$ENV{"CONTENT_LENGTH"}
and then opening a pipe to the CGI.
The problem under mod_perl2 that I now see is that my standard CGI is 
not getting the QUERY_STRING information.

I see at
http://perl.apache.org/docs/2.0/user/porting/compat.html#Issues_with_Environment_Variables
the following information:
"Forked processes (including backticks) won't see CGI emulation 
environment variables. (META: This will hopefully be resolved in the 
future, it's documented in modperl_env.c:modperl_env_magic_set_all.)"

Does anyone have any information as to whether this issue will be 
resolved in mod_perl2?

If not or not anytime soon... can someone suggest a way for my mod_perl2 
script to open a pipe to a standard CGI that relies on QUERY_STRING for 
its input?

I was thinking of having my mod_perl2 script open a pipe to a perl 
script that will take some query_string and such as parameters. That 
intermediate script could set the appropriate environment variables and 
open a pipe to my standard CGI. That might work, but it seems messy.

--
Jim Albert

Re: Issues with Environment Variables

[Jim Albert]

Frank Wiles wrote:
On Tue, 11 Jan 2005 14:02:00 -0500
Jim Albert <[EMAIL PROTECTED]> wrote:

Under mod_perl1 I had a mod_perled program that opened a pipe to a 
standard CGI and recorded its output.

I did this in my mod_perl program by setting the following ENV vars:
$ENV{"QUERY_STRING"}
$ENV{"REQUEST_METHOD"}
$ENV{"CONTENT_LENGTH"}
and then opening a pipe to the CGI.
The problem under mod_perl2 that I now see is that my standard CGI is 
not getting the QUERY_STRING information.

I see at
http://perl.apache.org/docs/2.0/user/porting/compat.html#Issues_with_Environment_Variables
the following information:
"Forked processes (including backticks) won't see CGI emulation 
environment variables. (META: This will hopefully be resolved in the 
future, it's documented in modperl_env.c:modperl_env_magic_set_all.)"

Does anyone have any information as to whether this issue will be 
resolved in mod_perl2?

If not or not anytime soon... can someone suggest a way for my
mod_perl2 script to open a pipe to a standard CGI that relies on
QUERY_STRING for its input?
I was thinking of having my mod_perl2 script open a pipe to a perl 
script that will take some query_string and such as parameters. That 
intermediate script could set the appropriate environment variables
and open a pipe to my standard CGI. That might work, but it seems
messy.

  This may not work, but I've seen people pass environment variables
  on the commandline before... like so: 

  # TEST=foobar ./test.pl
  This sets $ENV{TEST} == 'foobar'.  Not an elegant way to work around
  it, but it should then be passed to the CGI. 

More or less, that's what I did. I have my mod_perl script open a pipe 
and pass the query string and other information to a regular perl script 
(call it 'middleman') as command line parameters. middleman then sets 
the ENV and opens a pipe to the CGI.

It works, but I don't really like the solution. Luckily, this is not 
something that runs a whole lot, so the additional time and resources 
are not a big deal.

--
Jim Albert

Apache2 namespace

[Jim Albert]

Can someone point me to a URL that describes the purpose of the Apache2 
namespace? Latest mod_perl was just installed on one of my systems and I 
noticed a few modules moved from Apache:: to Apache2::


Not a big deal. I made a few changes to handle that. But, I'm wondering 
if I should eventually expect all modules to move from Apache:: to 
Apache2:: or what the criteria might be for doing so. For example, it 
looks to me from cpan like Apache::Session still exists in Apache::


Thanks.

--
Jim Albert

Re: Apache2 namespace

[Jim Albert]

Philip M. Gollucci wrote:

Jim Albert wrote:

Can someone point me to a URL that describes the purpose of the 
Apache2 namespace? 



I don't believe one exists (yet) ... possibly a good idea for the
perl.apache.org site?

The general idea as I've got it is:

1.  Apache::*
Module works under mp1
Possibly works under mp2

Example: Apache::DBI v0.98 (both)

Example: Apache::Peek (mp1)

Note: I'm working on porting this one as we speak
to work under both.

2.  Apache2::*
Module works under mp2 only
Example: Apache2::AuthNTLM

The decision is basically left up to the individual maintainers at the 
moment.  The benefit of 1 is that you have 1 code base.  The benefit of 
2 is that you remove the if/else logic and clearly mark the module as 
mp2 only.


HTH


Yes, it does. Thank you very much. Do you have any example code you 
could share with me for places in my code where I have to use an 
Apache:: module on some servers, but Apache2:: module on another. I'd 
like to keep one code base.


For example, one piece of my code has
use Apache::Const
but I had to change that to use Apache2::Const on the server running the 
lastest mod_perl.


Can you give me the logic to handle that properly in a single code file. 
Thanks again.


--
Jim Albert

Re: Apache2 namespace

[Jim Albert]

Philip M. Gollucci wrote:


Philip M. Gollucci wrote:


Jim Albert wrote:


For example, one piece of my code has
use Apache::Const
but I had to change that to use Apache2::Const on the server running 
the lastest mod_perl.


Can you give me the logic to handle that properly in a single code 
file. Thanks again.


Here's the link I was looking for:

Superseeds previous e-mail:
http://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence 


Hmmm seems like the example on that page relies on
use mod_perl;
to get $mod_perl::VERSION
However, mod_perl.pm has changed to mod_perl2.pm in the newer version of 
mod_perl that's now on my system, so it doesn't appear that the example 
at 
http://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence 
solves this particular problem.


--
Jim Albert

Re: Apache2 namespace

[Jim Albert]

Philip M. Gollucci wrote:


Hmmm seems like the example on that page relies on


use mod_perl;
to get $mod_perl::VERSION
However, mod_perl.pm has changed to mod_perl2.pm in the newer version 
of mod_perl that's now on my system, so it doesn't appear that the 
example at 
http://perl.apache.org/docs/2.0/user/porting/compat.html#mod_perl_1_0_and_2_0_Constants_Coexistence 
solves this particular problem.



s/mod_perl/mod_perl2/g


Correct, that will change mod_perl to mod_perl2 in my source, but my 
point was that it won't help in the case of attempting to maintain one 
code base (my code) in terms of whether to include modules from the 
Apache:: or Apache2:: namespace. Perhaps the exsitence of and the 
particular value of $ENV{MOD_PERL_API_VERSION} might be better suited.


--
Jim Albert

ModPerl::PerlRun CGI.pm SSI

[Jim Albert]

I'm trying to debug a strange situation with the following environment:
Apache 2.0.54
mod_perl 2.0.1
perl 5.8.6
CGI.pm 3.10
Linux 2.6.12-1.1447_FC4smp

Say I have a mod_perl script called x.cgi configured for mod_perl as 
follows:


  SetHandler perl-script
  PerlHandler ModPerl::PerlRun
  Options ExecCGI
  PerlSendHeader On


**NOTE that I am using ModPerl::PerlRun

x.cgi uses CGI.pm as follows:

use strict;
use CGI qw (:cgi);

my $inp = param('inp');
print STDERR ("inp = $inp\n");


x.cgi works fine as a ModPerl::PerlRun script except for the case where 
I use it multiple times as a Server Side Include in the same .html file 
as follows:










In such a case the value of inp prints as 50 for both calls.

I've tested this on a single httpd process system and x.cgi works 
properly for multiple calls to it (with different values for inp) during 
the life of that single httpd process. I only get the strange incorrect 
results when used as a server side include multiple times within the 
same html file.


After attempting to track down the problem, the best I can come up with 
is there is a global @QUERY_PARAM array in CGI.pm that does not get 
cleared when x.cgi is uses multiple times as server side include in the 
same html file. If @QUERY_PARAM is not cleared, CGI.pm continues to use 
the same QUERY_STRING.


However, I don't believe this is a CGI.pm bug. I believe 
ModPerl::PerlRun appears to be clearing @QUERY_PARAM properly between 
multiple calls of x.cgi. However, ModPerl::PerlRun does not appear to 
clearing @QUERY_PARAM between multiple calls to x.cgi when x.cgi is used 
mutliple times as a server side include in the same html file.


I'm guessing there is either a problem with ModPerl::PerlRun or Apache 
2.0.54.


Perhaps there is some httpd.conf or perl.conf configuration I should be 
looking at?


Thanks for any help you can provide as currently the only solution I 
have is to hack up CGI.pm but I don't believe that is the best solution 
as the relevant code of CGI.pm does not appear to have changed from 
another version of CGI.pm on a different system where this works fine.


--
Jim Albert

Re: ModPerl::PerlRun CGI.pm SSI

[Jim Albert]

I think I may now have a better understanding of this and that the 
problem lies in CGI.pm. I've emailed the following to Lincoln Stein 
explaining what I believe to be true. Perhaps someone can either confirm 
my understanding or otherwise correct me.


My email to Lincoln Stein is as follows:
I did some more research and I believe I understand the problem and why 
it only happens when the mod_perled x.cgi is used multiple times as a 
server side include within the same html file.


The issue is with this line of code in CGI::new
$r->pool->cleanup_register(\&CGI::_reset_globals);

From my understanding, that sets up a apache callback to clean up your 
globals **after** the apache process is done serving the request.


However, in the case where x.cgi is used multiple times as a server side 
include in the same html file, _reset_globals is not called until the 
apache process is done with the request.


It seems to me it would be best simply to call _reset_globals first 
thing in your new() method when you detect a mod_perl environment. That 
way we know all those globals are clean for each use.


Unless you can offer another suggestion, my solution at present is to 
add the following to all my mod_perled scripts that use CGI.pm:

CGI::initialize_globals();

I hope you can help with this.

Jim Albert wrote:


I'm trying to debug a strange situation with the following environment:
Apache 2.0.54
mod_perl 2.0.1
perl 5.8.6
CGI.pm 3.10
Linux 2.6.12-1.1447_FC4smp

Say I have a mod_perl script called x.cgi configured for mod_perl as 
follows:


  SetHandler perl-script
  PerlHandler ModPerl::PerlRun
  Options ExecCGI
  PerlSendHeader On


**NOTE that I am using ModPerl::PerlRun

x.cgi uses CGI.pm as follows:

use strict;
use CGI qw (:cgi);

my $inp = param('inp');
print STDERR ("inp = $inp\n");


x.cgi works fine as a ModPerl::PerlRun script except for the case where 
I use it multiple times as a Server Side Include in the same .html file 
as follows:










In such a case the value of inp prints as 50 for both calls.

I've tested this on a single httpd process system and x.cgi works 
properly for multiple calls to it (with different values for inp) during 
the life of that single httpd process. I only get the strange incorrect 
results when used as a server side include multiple times within the 
same html file.


After attempting to track down the problem, the best I can come up with 
is there is a global @QUERY_PARAM array in CGI.pm that does not get 
cleared when x.cgi is uses multiple times as server side include in the 
same html file. If @QUERY_PARAM is not cleared, CGI.pm continues to use 
the same QUERY_STRING.


However, I don't believe this is a CGI.pm bug. I believe 
ModPerl::PerlRun appears to be clearing @QUERY_PARAM properly between 
multiple calls of x.cgi. However, ModPerl::PerlRun does not appear to 
clearing @QUERY_PARAM between multiple calls to x.cgi when x.cgi is used 
mutliple times as a server side include in the same html file.


I'm guessing there is either a problem with ModPerl::PerlRun or Apache 
2.0.54.


Perhaps there is some httpd.conf or perl.conf configuration I should be 
looking at?


Thanks for any help you can provide as currently the only solution I 
have is to hack up CGI.pm but I don't believe that is the best solution 
as the relevant code of CGI.pm does not appear to have changed from 
another version of CGI.pm on a different system where this works fine.





--
Jim Albert

Re: ModPerl::PerlRun CGI.pm SSI

[Jim Albert]

Lack of response on this tells me:

1. Nobody is using ModPerl::PerlRun any longer to run their scripts 
under mod_perl. I doubt it.


2. There is an alternative to CGI.pm that is mod_perl safe. If there is 
a mod_perl safe alternative to CGI.pm for use under ModPerl::PerlRun 
scripts for things like retrieving input from QUERY_STRING and working 
with cookies, please point me to what you use for this.


Thanks.

Jim Albert wrote:

I think I may now have a better understanding of this and that the 
problem lies in CGI.pm. I've emailed the following to Lincoln Stein 
explaining what I believe to be true. Perhaps someone can either confirm 
my understanding or otherwise correct me.


My email to Lincoln Stein is as follows:
I did some more research and I believe I understand the problem and why 
it only happens when the mod_perled x.cgi is used multiple times as a 
server side include within the same html file.


The issue is with this line of code in CGI::new
$r->pool->cleanup_register(\&CGI::_reset_globals);

 From my understanding, that sets up a apache callback to clean up your 
globals **after** the apache process is done serving the request.


However, in the case where x.cgi is used multiple times as a server side 
include in the same html file, _reset_globals is not called until the 
apache process is done with the request.


It seems to me it would be best simply to call _reset_globals first 
thing in your new() method when you detect a mod_perl environment. That 
way we know all those globals are clean for each use.


Unless you can offer another suggestion, my solution at present is to 
add the following to all my mod_perled scripts that use CGI.pm:

CGI::initialize_globals();

I hope you can help with this.

Jim Albert wrote:


I'm trying to debug a strange situation with the following environment:
Apache 2.0.54
mod_perl 2.0.1
perl 5.8.6
CGI.pm 3.10
Linux 2.6.12-1.1447_FC4smp

Say I have a mod_perl script called x.cgi configured for mod_perl as 
follows:


  SetHandler perl-script
  PerlHandler ModPerl::PerlRun
  Options ExecCGI
  PerlSendHeader On


**NOTE that I am using ModPerl::PerlRun

x.cgi uses CGI.pm as follows:

use strict;
use CGI qw (:cgi);

my $inp = param('inp');
print STDERR ("inp = $inp\n");


x.cgi works fine as a ModPerl::PerlRun script except for the case 
where I use it multiple times as a Server Side Include in the same 
.html file as follows:










In such a case the value of inp prints as 50 for both calls.

I've tested this on a single httpd process system and x.cgi works 
properly for multiple calls to it (with different values for inp) 
during the life of that single httpd process. I only get the strange 
incorrect results when used as a server side include multiple times 
within the same html file.


After attempting to track down the problem, the best I can come up 
with is there is a global @QUERY_PARAM array in CGI.pm that does not 
get cleared when x.cgi is uses multiple times as server side include 
in the same html file. If @QUERY_PARAM is not cleared, CGI.pm 
continues to use the same QUERY_STRING.


However, I don't believe this is a CGI.pm bug. I believe 
ModPerl::PerlRun appears to be clearing @QUERY_PARAM properly between 
multiple calls of x.cgi. However, ModPerl::PerlRun does not appear to 
clearing @QUERY_PARAM between multiple calls to x.cgi when x.cgi is 
used mutliple times as a server side include in the same html file.


I'm guessing there is either a problem with ModPerl::PerlRun or Apache 
2.0.54.


Perhaps there is some httpd.conf or perl.conf configuration I should 
be looking at?


Thanks for any help you can provide as currently the only solution I 
have is to hack up CGI.pm but I don't believe that is the best 
solution as the relevant code of CGI.pm does not appear to have 
changed from another version of CGI.pm on a different system where 
this works fine.







--
Jim Albert

Re: ModPerl::PerlRun CGI.pm SSI

[Jim Albert]

Michael Peters wrote:



Jim Albert wrote:


Lack of response on this tells me:

1. Nobody is using ModPerl::PerlRun any longer to run their scripts
under mod_perl. I doubt it.




From the docs:

  This module is meant for "Dirty" CGI Perl scripts

and

  The Apache::Registry handler is much faster

So new development shouldn't be targetting PerlRun anymore, but
Registry. If you are trying to work with a legacy app, then that is more
understandable.


Yes, I have a lot of old code and I don't ever see myself having enough 
time to convert it to Registry, if that would in fact be better for my 
situation. I've never really agreed with the "dirty" cgi perl scripts 
terminology. I really consider PerlRun and Registry simply different 
paradigms. With PerlRun my script itself doesn't get loaded persistently 
into memory, but that's not a huge deal... perl and all the modules the 
script uses do get loaded persistently so that probably accounts for 90% 
of the speedup since most of my code is in underlying modules which are 
mod_perl safe. To convert them to Registry to gain maybe another 10% 
doesn't seem to be worth the effort. Besides the fact that if I choose 
the scripts to run mod_cgi perhaps in a non mod_perl environment, then 
they are all set to go. My code does run under various apache 
environments so keeping it flexible is important to me.


Hopefully future mod_perl versions don't discount what I would guess is 
the large amount of PerlRun code still running out there. If people have 
code and it works, most don't have time to write it over to make it work 
in a different way.






2. There is an alternative to CGI.pm that is mod_perl safe. If there is
a mod_perl safe alternative to CGI.pm for use under ModPerl::PerlRun
scripts for things like retrieving input from QUERY_STRING and working
with cookies, please point me to what you use for this.



Have you tried using CGI.pm in an OO fashion to see if it fixes the
problem you're having? If that doesn't work, then I'd suggest sticking
with your original thought and just do the resetting the globals
yourself at the beginning of every request.

  CGI::_reset_globals();


Actually, you're partly correct. I'm sorry... I forgot to point that out 
in my previous messages. I actually did have to switch to using CGI.pm 
in OO via something like:

my $cgi_obj = CGI->new();
I needed to switch to this in order to have the new() method called for 
each run of my cgi in the request since it is new() that calls init() 
which is what reads in the request information.


However, simply switching to OO was not enough. That didn't clear out 
the global variables in CGI.pm such as @QUERY_PARAM between calls to my 
cgi. I wrote a method in one of my modules named NetrCGI.pm to do the 
following:

sub NetrCGI_makeCGIdotPMmodPerlSafe
{
   my $self = shift;

   undef @CGI::QUERY_PARAM;
   undef $CGI::QUERY_CHARSET;
   undef %CGI::QUERY_FIELDNAMES;
}

I thought this was safer than calling CGI::initiliaze_globals since I 
wasn't sure if the values of all those globals were important throughout 
the use of CGI.pm, but I convinced myself that I could safely undef the 
above three variables since they only seem to be used for saving state 
which was the problem for me to begin with. Actually, undefing 
@QUERY_PARAM would have been sufficient for my problem.




I don't think your scenario is common enough to get this put into CGI.pm
itself since it would slow down everyone else (which is why Lincoln put
it into a cleanup handler in the first place, so it's run after the
output has been sent to the browser).


Yes, and in most cases that's fine, except for (at least) the case where 
the httpd process is running multiple mod_perled scripts in a single 
request... for example, mutiple server side includes of the script in 
the same html file.




But you may be able to convince Lincoln to make the method public and
documented so that it won't get ripped out from under you some day.


Yes, I was thinking maybe an option to the new() method to force an 
immediate call to initialize_globals seems like maybe a good way to do 
it. Then anyone not affected by this can simply ignore it. But, I'd 
leave that open for Lincoln to decide how best to put in the hook so as 
to have no impact on those not affected by this. It does look Lincoln 
made an effort to keep CGI.pm mod_perl safe, so hopefully he can add in 
this extra hook to keep it more mod_perl safe. I've forwarded him these 
suggestions.


Alternatively, I was considering just turning on $CGI::PERLEX since this 
forces a call to _reset_globals in new. However, I see this that 
$CGI::PERLEX is meant to indicate ActivateState's PerlEx. I don't know 
what that is or what it might indicate in future versions of CGI.pm so I 
chose against turning that variable on.

# Turn on special checking fo

Re: ModPerl::PerlRun CGI.pm SSI

[Jim Albert]

Perrin Harkins wrote:


On Thu, 2005-10-06 at 11:53 -0400, Jim Albert wrote:

Besides the fact that if I choose 
the scripts to run mod_cgi perhaps in a non mod_perl environment,
then 
they are all set to go.



This is true with Registry scripts as well.



I thought this was safer than calling CGI::initiliaze_globals



I don't think it is.  Guessing at which ones need to be cleared sounds
less safe to me.

I have successfully used the CGI::initialize_globals workaround when
needing to support CGI.pm with subrequests, and I recommend that you use
it if you want to stick with CGI.pm.


Yes, I agree. Especially since I had to move to using CGI.pm via OO 
anyway so any changes that CGI.pm makes to those globals just happen 
again after me clearing the globals when i I call the CGI::new() method. 
I had previously thought best otherwise when I thought I could continue 
to use CGI.pm non-OO.


Thanks for bringing that to mind.



Ultimately, you're better off abandoning CGI.pm for something else.
There are alternatives with an identical API if all you need is
parameter parsing.


OK, thanks... I'll check some of them out when I have some more time. 
Right now, CGI::initiliaze_globals is the quickest way for me to get my 
problem resolved.


Thanks all for confirming my thoughts on this problem.

--
Jim Albert

Re: graphics in perl

[Jim Albert]

Malka Cymbalista wrote:

We are running perl 5.8.5 on a Linux machine that is running apache 2.2.6 with 
mod_perl 2.0.3.  Our data is in a MySQL database (MySQL 5.0.45)

We have been asked to write a web application that requires plotting 
capabilities.  We do most of our web programming in perl so I am looking for a 
perl module that has the following features:
1. ability to create histograms 
2. ability to create x,y plots

3. ability to zoom in on a portion of the graph
4. ability to calculate the distance between 2  points on the graph
5. ability to hover on a point and bring up some text 


Does anyone have any suggestions for which perl modules we should look into?

Thanks for any information.


There are a lot of perl APIs built over various graphics packages.
You can start with this list:
http://search.cpan.org/modlist/Graphics

You might also try searching cpan for some specific keywords, because I 
don't believe all the graphics modules are in that list. For example, 
I've used Image::Magick for doing some basic image resizing and 
conversion, but I don't see Image::Magick in that list.


--
Jim Albert

What would a mod_perl EOL look like?

[Jim Albert]

When mod_perl does come to an end what would an End of Life look like?
I'm told mod_perl is an Apache Software Foundation project. Do Apache 
Software Foundation projects have a structured life cycle or do some 
just suddenly disappear with no warning given various situations that 
result in the need for EOL?


Jim

Re: What would a mod_perl EOL look like?

[Jim Albert]

On 3/18/2021 10:41 AM, Ruben Safir wrote:

On Thu, Mar 18, 2021 at 10:37:02AM -0400, Jim Albert wrote:

When mod_perl does come to an end what would an End of Life look like?


maybe we can focus on keeping it maintained... really.

A secure well written project like modperl doesn't need new features and
people destroying its API.  It works, and that is good.

There is no reason for it to have an end of lifecycle.  It works forever



I'm told mod_perl is an Apache Software Foundation project. Do
Apache Software Foundation projects have a structured life cycle or
do some just suddenly disappear with no warning given various
situations that result in the need for EOL?

Jim


That would be wonderful, of course. The reality of the mod_perl project, 
to my understanding, is that it is made up of volunteers (and a very 
sincere thank you to those that have and do volunteer their skills). 
Also to my understanding is that the mod_perl project has no industry 
backing financial, technical or otherwise, but please correct me if I am 
wrong. If those volunteers go away and aren't replaced, I have to think 
the project goes away perhaps with temporary assistance of the overall 
Apache Software Foundation. I have no idea how ASF project lifecycles 
are maintained.


Most software projects have a lifecycle so I'm asking if Apache Software 
Foundation projects, including mod_perl, have a structured lifecycle .
If you are using a certain software be it operating system or otherwise, 
don't you want to know the EOL up front (in the case of most operating 
systems) or have an understanding that when EOL happens for various 
software packages, you'll receive adequate warning?  Anyone relying on 
mod_perl would or at least should want to understand that. I would hope 
it's not a case of well... it's there to use until it breaks.


Jim

Re: What would a mod_perl EOL look like?

[Jim Albert]

sorry for so much top-posting, but that seems to be the flow in this 
forum. I also notice a lack of reply-to header or some other reason that 
a reply action is to sender rather than modperl@perl.apache.org... kind 
of annoying unless my MX is messing with the forum's headers.


OK... so an Apache Attic announcement is synonymous with EOL. Is that 
correct?


To quote from https://attic.apache.org/
" The Apache Attic was created in November 2008 
<http://www.apache.org/foundation/records/minutes/2008/board_minutes_2008_11_19.txt> 
to provide process and solutions to make it clear when an Apache project 
has reached its end of life."


To paraphrase... "the Apache Attic is not intended for bug fixes or 
releases"


I see processes for moving out of the Attic, but without active 
development, I assume that is unlikely.


Is that a reasonable summary?

Jim

On 3/18/2021 12:48 PM, adam.pr...@utoronto.ca wrote:
If you go back to Sander's original email, he outlines what will 
happen if we can't staff the PMC sufficiently to meet Apache's 
guidelines. The project woudl go to the attic[1].  There are lots of 
projects in the Attic. Some of them have been forked and continue to 
have development done on them. At any rate, there will be some notice, 
though probably not years of notice, and the source code absolutely 
will not 'suddenly disappear'. I'd suggest following the link below 
and reading about what the attic is, and what it would mean to get 
more context if you're interested in more detail.


Adam

[1] http://attic.apache.org/




Quoting Jim Albert :


When mod_perl does come to an end what would an End of Life look like?
I'm told mod_perl is an Apache Software Foundation project. Do Apache
Software Foundation projects have a structured life cycle or do some
just suddenly disappear with no warning given various situations that
result in the need for EOL?

Jim

Re: What would a mod_perl EOL look like?

[Jim Albert]

OK... last email on this topic.
I feel like I'm getting replies like I'm from another planet for asking 
prudent questions.
If others want to keep their heads in the sand and get a huge surprise 
someday when a Perl update or a new version of Apache they just 
installed breaks mod_perl or there's a vulnerability that requires a fix 
and there's no one to fix... go ahead and roll  your dice... it's your 
party.


If you care at all about your software environment you should want to 
have an understanding of when you need  to look for a replacement and 
when a product  hits EOL. No, I don't want to look  for a replacement, 
but I do want to have an understanding of when to recognize when that is 
going to be a necessity given a software package's managed lifecycle. 
Perhaps others here are still looking for devices to play their 1970s 
8-track tapes?


For anyone who actually does care given Adam's direction to the attic 
description at https://attic.apache.org/.
If mod_perl hits The Apache Attic, I consider that fair warning. I don't 
think that 100% indicates an absolute final nail, but reasonable fair 
warning. I appreciate the responses of those that have lead me to that 
information.


Jim

On 3/18/2021 2:14 PM, Michel Jansen wrote:

Hi there,

If it broken it doesnt have to be fixed. Our purchase system is running almost 
20 years on modperl and there is no reason for is to stop this. We are very 
happy with it. How about that?

Michel Jansen


Op 18 mrt. 2021 om 17:48 heeft adam.pr...@utoronto.ca het volgende geschreven:

If you go back to Sander's original email, he outlines what will happen if we 
can't staff the PMC sufficiently to meet Apache's guidelines. The project woudl 
go to the attic[1].  There are lots of projects in the Attic. Some of them have 
been forked and continue to have development done on them. At any rate, there 
will be some notice, though probably not years of notice, and the source code 
absolutely will not 'suddenly disappear'. I'd suggest following the link below 
and reading about what the attic is, and what it would mean to get more context 
if you're interested in more detail.

Adam

[1] http://attic.apache.org/




Quoting Jim Albert :


When mod_perl does come to an end what would an End of Life look like?
I'm told mod_perl is an Apache Software Foundation project. Do Apache
Software Foundation projects have a structured life cycle or do some
just suddenly disappear with no warning given various situations that
result in the need for EOL?

Jim