Re: Question on possible effects of mod_perl on mod_cgi
That was it. I redefined Sig{__WARN__} to drop all STDERR output and my
script output everything it was supposed to and exited cleanly. Now
there is another bug that undoubtedly came from my trying to track down
the original issue...
Thanks. That saved me a ton of time.
Tom
Terra Info wrote:
Ugh! I checked the users list archives but I never checked the dev
archives. I liked p5p back in the day because it was all one in the
same. Chaos, but oddly efficient. Thanks for the pointer.
As for the docs, I freely admit I missed it. I was not looking for
PerlRun stuff when I went through that migration piece (I was looking
for a different project) so when I started dealing with this I did not
remember seeing it, therefore in my warped mind it did not exist.
Right now, int/0 looks perfectly fine to me. Anyhow, I doubt listing
all of them would help, just add in Apache::PerlRun into the header so
it reads The Apache::Registry and Apache::PerlRun Families (or ~)
and that would get people's attention a little bit better.
Thanks,
Tom
Stas Bekman wrote:
OK, now it's clear, thanks for the explanation. FWIW, there were
discussions of possible pipes read/write deadlocks in the current
mod_cgi implementation in Apache 2.0, so you may experience just
that. Check the httpd-dev list archives.
[...]
* Given that, I noticed PerlRun was no longer prominintly displayed
in the docs
What made you think so? The PerlRun docs weren't touched for ages.
and the migration FAQ did not to my knowledge even touch on it.
Because all you have to do is to s/Apache::/ModPerl::/ for all
registry handlers, which includes PerlRun. Do you think that it'll
help to explicitly list them all?
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
-
Terra Novum Research
[EMAIL PROTECTED]
www.terranovum.com
(617) 923-4132
PO Box 362
Watertown, MA 02471-0362
They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.
Benjamin Franklin,
Historical Review of Pennsylvania, 1759
Re: Question on possible effects of mod_perl on mod_cgi
[When starting a new thread, please remember to create a new mail, rather than doing a reply to one of the threads. If you don't do that, your mail software attaches reference ids to the original thread and your post gets folded into the thread you've replied to. people may delete the whole thread without seeing your post if they weren't interested in this thread. it also has an ill effect on mail archives.] Terra Info wrote: I am debugging a particularly nasty issue right now on a perl script that when written 2+ yrs ago worked fine. NB: It does not run under mod_perl and it has not been modified since then. You mean, it has never worked under mod_perl 1.0? Can you test it with mod_perl 1.0? I run it from the cmd line (with the identical query string and all referenced %ENV vars set identical as well) and it runs fine. I run it as a typical CGI and it has problems that, in *some* ways, mirror the behavior of a poorly written (symptoms associated with unscoped globals, etc;) perl app under mod_perl. And since this is a poorly written app I am curious. Is there any link between mod_perl (1.99..) and mod_cgi (Apache 2)? Does mod_perl in anyway influence or maybe cause PerlRun like caching under mod_cgi? I am just trying to eliminate all possibilities as this one has been a real PITFA. You can turn the debugging on and see whether it gets cached. in ModPerl::RegistryCooker set: use constant DEBUG = 4; restart the server and watch error_log, compare the output of Registry with PerlRun. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Question on possible effects of mod_perl on mod_cgi
The threads issue is my bag. I know better but was busy and distracted,
hence I just did a reply to all and trimmed out the excess. Anyhow, I
think you may have misunderstood my question. Although I have a specific
issue at hand, my question was more generic. My questions are more
related to the overall design of mod_perl and its effects on the
functioning of Apache's other components. Anyhow, in answer to your
question, I have not tried it under mod_perl 1 or 2 because this script
would never function under them. It is that poorly written.
So, is there any link between mod_perl (1.99..) and mod_cgi (Apache 2)?
Does mod_perl in anyway influence or maybe cause PerlRun like caching
under mod_cgi? I realize the answers are probably no but I am at my wits
end with this bug and am trying to elminate things as causes that
normally I would not even think were related.
So you have a better handle on why I am asking, I have a script that
runs fine from the cmd line under all parameter combinations, runs fine
in most situations under CGI but when a few param combinations occur it
fails to execute to completion. The odd thing is the place it hangs up
is the line before exit;. I added a warn('foo at line nnn') after every
line and it warns all they way to the line for exit; but never exists
and apache tells me that the script times out. That combined with the
fact that the script, when executed on the command line, under a faked
up ENV that matches exactly what it gets from httpd runs flawlessly and
to completion, seems to suggest something is happening in the in-process
handling of the CGI script. Does that problem lie in mod_cgi, perl or in
some funky interaction between components? With some of the symptoms I
saw I wanted to rule out mod_perl before I went any further.
Thanks and I hope this made it more clear what I was looking for and why,
Tom
Stas Bekman wrote:
[When starting a new thread, please remember to create a new mail,
rather than doing a reply to one of the threads. If you don't do that,
your mail software attaches reference ids to the original thread and
your post gets folded into the thread you've replied to. people may
delete the whole thread without seeing your post if they weren't
interested in this thread. it also has an ill effect on mail archives.]
Terra Info wrote:
I am debugging a particularly nasty issue right now on a perl script
that when written 2+ yrs ago worked fine. NB: It does not run under
mod_perl and it has not been modified since then.
You mean, it has never worked under mod_perl 1.0? Can you test it with
mod_perl 1.0?
I run it from the cmd line (with the identical query string and all
referenced %ENV vars set identical as well) and it runs fine. I run
it as a typical CGI and it has problems that, in *some* ways, mirror
the behavior of a poorly written (symptoms associated with unscoped
globals, etc;) perl app under mod_perl. And since this is a poorly
written app I am curious. Is there any link between mod_perl (1.99..)
and mod_cgi (Apache 2)? Does mod_perl in anyway influence or maybe
cause PerlRun like caching under mod_cgi? I am just trying to
eliminate all possibilities as this one has been a real PITFA.
You can turn the debugging on and see whether it gets cached.
in ModPerl::RegistryCooker set:
use constant DEBUG = 4;
restart the server and watch error_log, compare the output of Registry
with PerlRun.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
-
Terra Novum Research
[EMAIL PROTECTED]
www.terranovum.com
(617) 923-4132
PO Box 362
Watertown, MA 02471-0362
In time-keeping, in trading, in fighting, men counted numbers;
and finally, as the habit grew, only numbers counted.
Lewis Mumford
Re: Question on possible effects of mod_perl on mod_cgi
Terra Info wrote:
The threads issue is my bag. I know better but was busy and distracted,
hence I just did a reply to all and trimmed out the excess.
No prob. the comment was addressed to all subscribers.
Anyhow, I
think you may have misunderstood my question. Although I have a specific
issue at hand, my question was more generic. My questions are more
related to the overall design of mod_perl and its effects on the
functioning of Apache's other components. Anyhow, in answer to your
question, I have not tried it under mod_perl 1 or 2 because this script
would never function under them. It is that poorly written.
I meant the Apache::PerlRun from mod_perl 1.0. Obviously I wasn't trying
to suggest for you to run it as a pure handler ;)
Notice that ModPerl::PerlRun and others aren't exactly the same as their
1.0 counterparts. Due to the threading issues, currently 2.0's registry
aren't chdir()'ing to the scripts directory. That may change in the
future. But this may be unrelated to your problem.
So, is there any link between mod_perl (1.99..) and mod_cgi (Apache 2)?
No.
Does mod_perl in anyway influence or maybe cause PerlRun like caching
under mod_cgi?
The two has nothing to do with each other.
I realize the answers are probably no but I am at my wits
end with this bug and am trying to elminate things as causes that
normally I would not even think were related.
So you have a better handle on why I am asking, I have a script that
runs fine from the cmd line under all parameter combinations, runs fine
in most situations under CGI but when a few param combinations occur it
fails to execute to completion. The odd thing is the place it hangs up
is the line before exit;. I added a warn('foo at line nnn') after every
line and it warns all they way to the line for exit; but never exists
and apache tells me that the script times out. That combined with the
fact that the script, when executed on the command line, under a faked
up ENV that matches exactly what it gets from httpd runs flawlessly and
to completion, seems to suggest something is happening in the in-process
handling of the CGI script. Does that problem lie in mod_cgi, perl or in
some funky interaction between components? With some of the symptoms I
saw I wanted to rule out mod_perl before I went any further.
Thanks and I hope this made it more clear what I was looking for and why,
I still don't understand you. When do you see the problem? When you run
the script under mod_cgi or mod_perl? I don't understand why do you keep
referring to mod_cgi.
And we are talking about Apache/mod_perl 2.0 here, right?
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Question on possible effects of mod_perl on mod_cgi
Stas Bekman wrote: I still don't understand you. When do you see the problem? When you run the script under mod_cgi or mod_perl? I don't understand why do you keep referring to mod_cgi. And we are talking about Apache/mod_perl 2.0 here, right? No. I am talking about mod_cgi when I say mod_cgi. In short you answered my questions with answers I pretty much expected but I wanted my asumptions valiidated. For that I am grateful. Long answer: Let me state why I was looking (ie; the [il]logic to my thinking) to eliminate mod_perl from the list of of possible reasons why a standard CGI would be failing. * It was a perl CGI. * It was failing in ways that were similar, although not directly alike, ways that poorly written perl apps under mod_perl fail. For example, it would hangup, it would bahave oddly like there were variables set that should have been cleared (ie; unscoped globals). * It was a perl CGI. Hence I know that because of the excellent integration of perl into apache (perl in conf files, etc) as a result of mod_perl, I was looking to see if anyone here on mod_perl's list knew of any interactions, etc that could have spilled over into mod_cgi's handling of perl scripts for instance. * Given that, I noticed PerlRun was no longer prominintly displayed in the docs and the migration FAQ did not to my knowledge even touch on it. I was thiking maybe it had become an automatic thing in mod_cgi for mod_perl enabled httpds to try to speed up perl CGI's by using an in-process perl interpretor instead of backticking it. If that was happening I figured someone here would probably know about it. I posted questions to apache's list but it has been slow going getting people knowledgable about mod_cgi to answer. * There was more (il)logic but I think that should be enough to fill in the holes. Thanks, Tom -- - Terra Novum Research [EMAIL PROTECTED] www.terranovum.com (617) 923-4132 PO Box 362 Watertown, MA 02471-0362 The wireless telegraph is not difficult to understand. The ordinary telegraph is like a very long cat. You pull the tail in New York, and it meows in Los Angeles. The wireless is the same, only without the cat. -- Einstein
Re: Question on possible effects of mod_perl on mod_cgi
OK, now it's clear, thanks for the explanation. FWIW, there were discussions of possible pipes read/write deadlocks in the current mod_cgi implementation in Apache 2.0, so you may experience just that. Check the httpd-dev list archives. [...] * Given that, I noticed PerlRun was no longer prominintly displayed in the docs What made you think so? The PerlRun docs weren't touched for ages. and the migration FAQ did not to my knowledge even touch on it. Because all you have to do is to s/Apache::/ModPerl::/ for all registry handlers, which includes PerlRun. Do you think that it'll help to explicitly list them all? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Question on possible effects of mod_perl on mod_cgi
Ugh! I checked the users list archives but I never checked the dev archives. I liked p5p back in the day because it was all one in the same. Chaos, but oddly efficient. Thanks for the pointer. As for the docs, I freely admit I missed it. I was not looking for PerlRun stuff when I went through that migration piece (I was looking for a different project) so when I started dealing with this I did not remember seeing it, therefore in my warped mind it did not exist. Right now, int/0 looks perfectly fine to me. Anyhow, I doubt listing all of them would help, just add in Apache::PerlRun into the header so it reads The Apache::Registry and Apache::PerlRun Families (or ~) and that would get people's attention a little bit better. Thanks, Tom Stas Bekman wrote: OK, now it's clear, thanks for the explanation. FWIW, there were discussions of possible pipes read/write deadlocks in the current mod_cgi implementation in Apache 2.0, so you may experience just that. Check the httpd-dev list archives. [...] * Given that, I noticed PerlRun was no longer prominintly displayed in the docs What made you think so? The PerlRun docs weren't touched for ages. and the migration FAQ did not to my knowledge even touch on it. Because all you have to do is to s/Apache::/ModPerl::/ for all registry handlers, which includes PerlRun. Do you think that it'll help to explicitly list them all? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- - Terra Novum Research [EMAIL PROTECTED] www.terranovum.com (617) 923-4132 PO Box 362 Watertown, MA 02471-0362 The wireless telegraph is not difficult to understand. The ordinary telegraph is like a very long cat. You pull the tail in New York, and it meows in Los Angeles. The wireless is the same, only without the cat. -- Einstein
