Re: unable to makefile of the modperl
Anuradha, Please don't turn mailing lists replies into private threads. If I've replied to the list and not privately to you, this means that I wanted the replies and follow-ups to go to the list. We [supporting community] do this for these reasons: * We didn't volunteer to be your private help-desk, we reply when we can and know, so by keeping the replies on the list we distribute the work between us all. * Other people might encounter the same problem, and they will benefit from reading the replies and troubleshooting notes for the same problem. * Finally the list is archived and people reuse the answers later on, without bothering the list with repeated questions. * Also very infrequently you might receive a bad advice, and you might not be aware of it. The list dwellers will detect this (almost) immediately. Please understand these rules and keep list replies at the list. [ Of course if someone replies to your question in private you should keep the reply private, don't repost it in public unless you have the other person's permission to do that! ] Thanks! See some hints below: On Fri, 4 May 2001, Anuradha Satyanarayana wrote: > > > > Thanks a lot !!! > After all i got a reply. I am still stuck with the same problem. > I have already installed LW P modules, HTML::HeadParser is also installed, > Apache 1.3.4, libwwwp, and all the other modules. Still then i am getting > these daignostic messages. > In some mails in the mailing list, some guy had got the same problem and u > had mentioned him to upgrade his Apache Version. Please tell me if i need > to do so. > I have Apache1.3.4 installed on my machine and modperl 1.25 version. > The problem comes once i give the Makefile command. > Perl Makefile APACHE_SRC=../../src NO_HTTPD=1 USE APACI=1 EVERYTHING=1 > I have thoroughly gone throught the documentation but could not find any > exact answer. > Will be waiting for your reply. > Thanks and regards > Anuradha Chances are that you have a few different Perl installations and you use a different Perl when you build mod_perl. To check this, run: $ perl -V look at the @INC and make sure that the reported missing modules installed in one of the paths reported in @INC. This should resolve your problem. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: unable to makefile of the modperl
Thanks a lot !!! After all i got a reply. I am still stuck with the same problem. I have already installed LW P modules, HTML::HeadParser is also installed, Apache 1.3.4, libwwwp, and all the other modules. Still then i am getting these daignostic messages. In some mails in the mailing list, some guy had got the same problem and u had mentioned him to upgrade his Apache Version. Please tell me if i need to do so. I have Apache1.3.4 installed on my machine and modperl 1.25 version. The problem comes once i give the Makefile command. Perl Makefile APACHE_SRC=../../src NO_HTTPD=1 USE APACI=1 EVERYTHING=1 I have thoroughly gone throught the documentation but could not find any exact answer. Will be waiting for your reply. Thanks and regards Anuradha Stas Bekman wrote: > On Thu, 3 May 2001, Anuradha Satyanarayana wrote: > > > Unable to make the modperl Makefile.PL downloaded from perl.apache.org. > > throwing errors like the following: > > > > > > Checking for LWP::UserAgent..failed > > Can't locate HTTP/Request.pm in @INC at lib/LWP/UserAgent.pm line 97. > > BEGIN failed--compilation aborted at lib/LWP/UserAgent.pm line 97. > > > > The libwww-perl library is needed to run the test suite. > > Installation of this library is recommended, but not required. > > > > Checking for HTML::HeadParserfailed > > Can't locate HTML/HeadParser.pm in @INC at Makefile.PL line 1129. > > > > > > Can anyone help? > > Aren't the diagnostic messages clear enough? You need to install these > modules before you build mod_perl (at least to run 'make test')... > > One of the easy ways to do that: > > $ perl -MCPAN -eshell > cpan> install LWP::UserAgent HTML::HeadParser > > Hope this helps... > > P.S. Make sure you read various and copious mod_perl documentation before > it starts raining here on the list :) See http://perl.apache.org/#docs > > _ > Stas Bekman JAm_pH -- Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide http://perl.apache.org/guide > mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ > http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: unable to makefile of the modperl
On Thu, 3 May 2001, Anuradha Satyanarayana wrote: > Unable to make the modperl Makefile.PL downloaded from perl.apache.org. > throwing errors like the following: > > > Checking for LWP::UserAgent..failed > Can't locate HTTP/Request.pm in @INC at lib/LWP/UserAgent.pm line 97. > BEGIN failed--compilation aborted at lib/LWP/UserAgent.pm line 97. > > The libwww-perl library is needed to run the test suite. > Installation of this library is recommended, but not required. > > Checking for HTML::HeadParserfailed > Can't locate HTML/HeadParser.pm in @INC at Makefile.PL line 1129. > > > Can anyone help? Aren't the diagnostic messages clear enough? You need to install these modules before you build mod_perl (at least to run 'make test')... One of the easy ways to do that: $ perl -MCPAN -eshell cpan> install LWP::UserAgent HTML::HeadParser Hope this helps... P.S. Make sure you read various and copious mod_perl documentation before it starts raining here on the list :) See http://perl.apache.org/#docs _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
unable to makefile of the modperl
Unable to make the modperl Makefile.PL downloaded from perl.apache.org. throwing errors like the following: Checking for LWP::UserAgent..failed Can't locate HTTP/Request.pm in @INC at lib/LWP/UserAgent.pm line 97. BEGIN failed--compilation aborted at lib/LWP/UserAgent.pm line 97. The libwww-perl library is needed to run the test suite. Installation of this library is recommended, but not required. Checking for HTML::HeadParserfailed Can't locate HTML/HeadParser.pm in @INC at Makefile.PL line 1129. Can anyone help? Regds Anuradha
Re: PerlAccessHandler -- struggling and drowning
will trillich said... > problem: some browsers see 'redirect' and ignore all other > headers, so the cookies aren't set. when the browser arrives at > the login area, there's no cookie to send there, to formulate > a return-to address from. What percentage of 'some browsers' is your user base? I do the following: $r->err_headers_out() to set cookie for decent browsers In my /Login routine, I check for the cookie that was set in err_headers_out. If that cookie does not exist (bad browser), I go to the Apache config and grab DEFAULT_LOGIN_URL, which is set via: PerlSetVar DEFAULT_LOGIN_URL http://foo.com/bad_browsers/welcome.html I then redirect to that location, and explain in that location why they don't get to magically go where they are supposed to. If this is a feature they REALLY want, then they can change browsers. But I see that most people don't really care, and they just happily point and click to the appropriate portion of the site. Now, if you were using Apache::Session, this would probably be moot. You could just add something special to your %session before the redirect in your authhandler, and yank it out after the successful /Login and redirect from it. Hope this makes sense. -- David S. Kenzik [EMAIL PROTECTED] - http://kenzik.com Original Music - http://text.org
[OT] Re: mod_perl subs defined, but don't exist? SOLVED mostly
[EMAIL PROTECTED] (will trillich) wrote:
> >sub search {
> >#
> >{
> >use CGI qw/:standard/;
> >my $form = join '',
> >map {
> >hidden(
> >-name => $_,
> >-value => $arg->{$_},
> >) . "\n"
> >}
> >grep(
> >$arg->{$_} and ($_ ne 'd') and ($_ ne 'go')
>
>as is, the functions that follow (top-level 'sub xyz {}') get
>screwy. code disappears.
>
>replace "and" with "&&" and all is well. boggles my mind.
Well, as far as I can tell, the original code doesn't even compile
because there aren't enough arguments to grep(). That's why I couldn't
test it. I suppose changing the precedence helped things out. Perhaps
you should use the more explicit BLOCK version:
my $form = join '',
map
{
hidden(
-name => $_,
-value => $arg->{$_},
) . "\n"
}
grep
{
$arg->{$_} and ($_ ne 'd') and ($_ ne 'go')
}
keys %$arg;
>
>with 'and' *{$My::Debacle::{handler}}{CODE} doesn't exist.
That's an illusion. The truth is that with 'and' the code is checking
something completely different, or not working at all.
This is turning out to be pretty well off-topic for the mod_perl list,
so we should cease.
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: mod_perl subs defined, but don't exist? SOLVED mostly
On Thu, May 03, 2001 at 08:52:38PM -0500, Ken Williams wrote:
> I can't follow this test case. Your previous message had a test case,
> but it was way too big. Can you whittle this down into the smallest
> possible program that demonstrates something you don't understand, and
> post that? My guess is that you'll figure out the problem in the
> process, but if not, post it here.
i found the culprit, but it's like finding out that a butterfly
burned down your house. i still don't see how it's possible.
when i distill it, of course, the problem vanishes. but see
below--
> By the way, I don't think you mean $My::Debacle::handler{CODE}. If you
> look closely, you'll see that it's just a regular hash entry. I think
> you mean *{$My::Debacle::{handler}}{CODE}. That's the CODE component of
> a symbol table entry.
right. whoops. boy, that stuff gets deep, quick.
> If you have "Effective Perl Programming", look on page 239.
eagle book, camel book, but no "shiny ball book". yet. :)
> I know this stuff is hard to spot when you've been banging your head
> against it for days. For that, I recommend "Zen and the Art of
> Motorcycle Maintenance".
a very good read, that.
> [EMAIL PROTECTED] (will trillich) wrote:
> >okay, here was the problem.
> >
> >package My::Debacle;
> >
> >sub search {
> >#
> >{
> >use CGI qw/:standard/;
> >my $form = join '',
> >map {
> >hidden(
> >-name => $_,
> >-value => $arg->{$_},
> >) . "\n"
> >}
> >grep(
> >$arg->{$_} and ($_ ne 'd') and ($_ ne 'go')
as is, the functions that follow (top-level 'sub xyz {}') get
screwy. code disappears.
replace "and" with "&&" and all is well. boggles my mind.
> >, keys %$arg
> >)
> >;
> >#
> >}
> >#
> >}
> >
> >sub this { # ...
> >}
> >sub that { # ...
> >}
> >sub something_else { # ...
> >}
> >sub whatever_the_hell { # ...
> >}
> >sub handler { # ...
> >}
with 'and' *{$My::Debacle::{handler}}{CODE} doesn't exist.
i've got a similar snag in a different module, now, where defined
subs are disappearing. but i can't trace it to a stray 'and'
here... must be something deeper?
--
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
Re: Insecure dependency errors
On Fri, 4 May 2001, Cees Hek wrote: > On Thu, 3 May 2001, Barry Veinotte wrote: > > > [Thu May 3 15:06:57 2001] [error] Insecure dependency in open while > > running with -T switch at >/usr/local/www/vhosts/ad-eagle.com/cgi-bin/ad-eagle/lib/AdEagle.pm line 472. > > The scripts using the .pm are running under Apache::Registry and have been running > > fine. Then last night a "major" upgrade was done to the servers. Now the scripts >are > > dying with this error. None of them are running -T I don't think any on the >server are, > > and know none under Apache::Registry are. > > Only Apache::Registry scripts are being affected. Anyone have any ideas as to > > where I could start looking? % perldoc perlsec > Check your Apache config files for PerlTaintCheck On, and check all your > registry scripts for the -T switch. Also, taint checking is automatically > turned on when scripts are run setuid (I don't know if that can affect > Registry scripts, but it's probably worth checking the file permissions on > all your scripts and modules) -T doesn't affect mod_perl scripts, only PerlTaintCheck. The same goes for setuid, Apache::Registry scripts aren't executed as plain perl scripts. Instead they are being read as plain files, placed into the handler() function (and the package) and only then executed. See: http://perl.apache.org/guide/porting.html#Taint_Mode _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_perl subs defined, but don't exist? SOLVED mostly
I can't follow this test case. Your previous message had a test case,
but it was way too big. Can you whittle this down into the smallest
possible program that demonstrates something you don't understand, and
post that? My guess is that you'll figure out the problem in the
process, but if not, post it here.
By the way, I don't think you mean $My::Debacle::handler{CODE}. If you
look closely, you'll see that it's just a regular hash entry. I think
you mean *{$My::Debacle::{handler}}{CODE}. That's the CODE component of
a symbol table entry.
If you have "Effective Perl Programming", look on page 239.
I know this stuff is hard to spot when you've been banging your head
against it for days. For that, I recommend "Zen and the Art of
Motorcycle Maintenance".
[EMAIL PROTECTED] (will trillich) wrote:
>okay, here was the problem.
>
>package My::Debacle;
>
>sub search {
>#
>{
>use CGI qw/:standard/;
>my $form = join '',
>map {
>hidden(
>-name => $_,
>-value => $arg->{$_},
>) . "\n"
>}
>grep(
>$arg->{$_} and ($_ ne 'd') and ($_ ne 'go')
>, keys %$arg
>)
>;
>#
>}
>#
>}
>
>sub this { # ...
>}
>sub that { # ...
>}
>sub something_else { # ...
>}
>sub whatever_the_hell { # ...
>}
>sub handler { # ...
>}
>
>can you spot the problem?
>
>with that, poof! $My::Debacle::handler{CODE} doesn't exist.
>WHY?
>
>--
>[EMAIL PROTECTED]
>http://sourceforge.net/projects/newbiedoc -- we need your brain!
>http://www.dontUthink.com/ -- your brain needs us!
>
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: mod_perl subs defined, but don't exist? SOLVED mostly
On Thu, May 03, 2001 at 01:19:45AM -0500, will trillich wrote:
> On Thu, May 03, 2001 at 12:29:53AM -0500, will trillich wrote:
> > long version--
> >
> > I have a subroutine that IS DEFINED, but it's not showing up as
> > defined. I used the *Symbol::Table::name{CODE} method myself and
> > sure enough, there's no CODE for the defined subroutine...
>
> [snip]
>
> > ANY wild-ass guesses would be appreciated. (Do i win a prize for
> > the most difficulty with a simple situation? Or at least an
> > honorable mention for most belligerent refusal to move on and get
> > a life?)
> >
> > ###
> >
> > short version--
> >
> > WTF?
>
> how can a defined subroutine NOT have any code in the symbol
> table? grr! this is quite a puzzle...
okay, here was the problem.
package My::Debacle;
sub search {
#
{
use CGI qw/:standard/;
my $form = join '',
map {
hidden(
-name => $_,
-value => $arg->{$_},
) . "\n"
}
grep(
$arg->{$_} and ($_ ne 'd') and ($_ ne 'go')
, keys %$arg
)
;
#
}
#
}
sub this { # ...
}
sub that { # ...
}
sub something_else { # ...
}
sub whatever_the_hell { # ...
}
sub handler { # ...
}
can you spot the problem?
with that, poof! $My::Debacle::handler{CODE} doesn't exist.
WHY?
--
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: PERL.COM, ORA and Songline mailservers SUCK!
FMTEYEWTKA pissing off Jesse. :-) Cheers, Richard > Subject: PERL.COM, ORA and Songline mailservers SUCK! >Date: Thu, 3 May 2001 20:09:02 -0400 >From: Jesse Erlbaum <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > I've been trying for THREE DAYS to email SOMEBODY at PERL.COM about taking > out a damn ad in their Perl.Com newsletter. > > . > . > . > > FRUSTRATED AS HELL, > > -Jesse- -- Richard Dice * Personal 519 635 9568 * Fax 519 635 9569 ShadNet Creator * http://shadnet.shad.ca/ * [EMAIL PROTECTED] Occasional Writer, HotWired * http://www.hotwired.com/webmonkey/ "squeeze the world 'til it's small enough to join us heel to toe" - jesus jones
PERL.COM, ORA and Songline mailservers SUCK!
I've been trying for THREE DAYS to email SOMEBODY at PERL.COM about taking
out a damn ad in their Perl.Com newsletter.
EVERY EMAIL ADDRESS LISTED IN THE NEWSLETTER AND WEBSITE BOUNCES.
It's not like they bounce with the same cause, either! That's the FUNNY
part. It looks like Songline's sever (magic.songline.com) simply refuses
ALL mail.. Nice touch, guy!
The backup MX for Perl.com (lists.oreillynet.com) bounces with another
error. A result of songline's F*CKED UP server.
The BEST OF ALL is Top Christiansen's snot-nosed mail rejection scheme.
NICE WORK TOM! I am including the ENTIRE DAMN REPLY I got from it. You can
see my TINY MESSAGE quoted at the bottom. Tom -- your reply is WAY out of
line. Get a grip, man! Rude, rude, RUDE!
FRUSTRATED AS HELL,
-Jesse-
-Original Message-
From: Mail Delivery Subsystem [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 03, 2001 7:58 PM
To: [EMAIL PROTECTED]
Subject: Returned mail: see transcript for details
The original message was received at Thu, 3 May 2001 17:57:27 -0600 (MDT)
from kyle.vm.com [209.73.238.18]
- The following addresses had permanent fatal errors -
"|/home/tchrist/.audit_mail tchrist"
(reason: service unavailable)
(expanded from: <[EMAIL PROTECTED]>)
- Transcript of session follows -
***
EMT (Email Abuse Toolkit) Intercept
***
Your message appears to be in violation of 1855 due to
overquoting or forwarding the complete messages, probably following
rather than preceding your reply. These are improper.
Please reconfigure your User Mail Agent to act more responsibly,
and resend your message after reading the following explanation.
Following you will find some code that mind be of use in diagnosing
other netiqutte issues that your User Mail Agent may be violating.
EXECUTIVE SUMMARY:
To send better messages, please trim and summarize what you're
replying to, and integrate your quoted text with the body of your
message. Don't just put everything at the end. This isn't Jeopardy.
People expect question-and-answer, not answer-and-question responses.
LONG STORY:
Wouldn't you like to make your messages easier for others to read and
understand? If so, I have some news posting tips for you. If not,
just ignore this. (Of course, if you don't want your messages
easier to read and understand, it's not clear why you bother to
send them in the first place. :-) I'm going to take a bit of
time to explain this, because newcomers to Usenet often lack the
cultural background were I to send a superbrief message.
Here's the issue: you appear to have quoted the entire message to which
you were replying. Worst of all, you have done so by merely appending
the complete message at the bottom. Folks are used to reading the
original material first, then the follow-up. That's why it's called a
"follow-up", you know. :-)
If all you want to do is forward a copy of the message, that's one thing,
but here you seem to have just blindly pasted the complete old message at
the end without providing any content. This is neither a proper public
followup nor even a decent private reply. Here's why.
First of all, this is massive overkill -- you're supposed to trim your
quoted text to only what you're replying to. Otherwise you'll probably
violate the netiquette target quoting percentage of 50%. See below.
This isn't really an issue of space (I know that a few bytes here and
there mean less today than 20 years go), so much as it is of integrating
your comments with the old material for continuity.
Second, putting everything at the bottom does little good. It doesn't
provide the proper context. It's far too late. When you reply to
someone's content, the reason you quote the previous message is so that
you can provide some degree of contextual continuity. The best way to
do this is to interleave what you're quoting with your responses to that
particular piece. That means that you should provide a quoted portion,
then address what the points therein, then another quoted section, etc.
For example, here's how followup replies *should* look if you'd
like them to be more effective.
> Joe said we should eat noodles.
But I don't like noodles. They are a pain to prepare -- remember
that what started this thread was how to cook using only a microwave,
not real cooking -- and they provide you with very little sustenance
in the long run. It's like eating cardboard, nutritionally speaking.
> He also suggests adding anchovies.
What is this fish fetish? Not all of us like the little minnows
with the lingering briny taste swimming around our mouths for the
next few hours or days. Can you imagine this on a date? Ich!
Notice how in the text above, alternate quoted passages are interleaved
with new response text. Notice also that the new text far exceeds t
Re: Insecure dependency errors
On Thu, 3 May 2001, Barry Veinotte wrote: > [Thu May 3 15:06:57 2001] [error] Insecure dependency in open while > running with -T switch at >/usr/local/www/vhosts/ad-eagle.com/cgi-bin/ad-eagle/lib/AdEagle.pm line 472. > > The scripts using the .pm are running under Apache::Registry and have been running > fine. Then last night a "major" upgrade was done to the servers. Now the scripts are > dying with this error. None of them are running -T I don't think any on the server >are, > and know none under Apache::Registry are. > > Only Apache::Registry scripts are being affected. Anyone have any ideas as to > where I could start looking? Check your Apache config files for PerlTaintCheck On, and check all your registry scripts for the -T switch. Also, taint checking is automatically turned on when scripts are run setuid (I don't know if that can affect Registry scripts, but it's probably worth checking the file permissions on all your scripts and modules) Cees
Re: Apache Processes hanging
This answer has nothing to do with modperl - sorry. I have had the same problem on a Sybase database with a 'normal' application. This situation can occur due to a database (b)locks, particularly if a transaction is composed of more than one update, or it fires a referential trigger which has the same effect. The first question is what is the lock-level. Is it at the row or at the page - I presume the row. If the insert causes a 'fault' such that an index page becomes full and has to split then the whole index page will be locked regardless of row-level locking. If the second part of transaction is waiting on someone else then we can get the deadly embrace situation. However, it can normally be cleared on time-outs. If however you are acquiring these blocks faster then they time out, then in very short order you will be .. er.. screwed. Sometimes it can help to do dirty reads if the data you need to present does not need to be up to date. One of the cures for this is an update pipe. Instead of each 'program' doing the insert on the database they funnel the updates to a single threading process. Reads of course can be be done by the individual 'programs'. Can you confirm that the connection is freed if you kill the process that is blocked? If so this gives you another way out. - Original Message - From: "Robert Landrum" <[EMAIL PROTECTED]> To: "Kevin Slean" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, 03 May, 2001 03:40 PM Subject: Re: Apache Processes hanging > At 10:37 AM -0400 5/3/01, Kevin Slean wrote: > >Mod_perlers, > > > >I have a problem with Apache and was looking for your thoughts on my problem > >or some additional mailing lists more focused on just Apache. > > > >I have 70 httpd daemons running and some of them just appear to hang. As > >time goes by, the number of hung processes increases such that there are no > >working ones left to perform real work. Consequently transaction processing > >performance drops eventually to zero. > > > >Our web transactions running through these httpd daemons should not take > >more than 60 seconds in a worst case scenario. Yet, some of these 'hung' > >processes have been on the same transaction for over 30 hours. I > >originally thought that this was a mod_perl problem and was buried in the > >CGI/Perl routines performing the transactions. However, upon closer > >inspection, I have found that these hanging processes are also running JAVA > >servlets and gif gets. This makes me suspect that it is an Apache problem. > > > >I ran truss on the hung processes and found that they fell into two camps. > >The first group was sitting at a read system call. The second group was in > >a loop with sigalarm going off every 10 seconds. > > > I'm having similar problems, but we think it's directly related to > Oracle. Basically, a connection is made to the Oracle database, a > transaction is started and finished, but the connection to the > database doesn't go away and the statement (at least from the oracle > side) never seems to finish. The data is present in the database > (these are insert statement, btw). Over time, every process collects > one of these hanging statements and it eventually overwhelms our > oracle database. The only solution is to restart apache every 5 > minutes to eliminate the built-up non-finished transactions. > > Has anyone seen this before? > > Rob > > -- > As soon as you make something foolproof, someone will create a better fool. >
RE: Apache Processes hanging
> I'm having similar problems, but we think it's directly related to
> Oracle. Basically, a connection is made to the Oracle database, a
> transaction is started and finished, but the connection to the
> database doesn't go away and the statement (at least from the oracle
> side) never seems to finish. The data is present in the database
> (these are insert statement, btw). Over time, every process collects
> one of these hanging statements and it eventually overwhelms our
> oracle database. The only solution is to restart apache every 5
> minutes to eliminate the built-up non-finished transactions.
Yeah... two things: CONCURRENCY and TRANSACTIONS.
Concurrency: Are there any other processes/reports/queries running at the
time of insert? That will lock ALL of them, waiting for the insert to
complete so the lock is released. Or, Another Interesting Way To Lock A
Really Buff Linux Server (tm).
Transactions: how's this one for fun? I started experimenting with
Apache::Session::Oracle to see what I could see. Usually I run w/
$dbh->{AutoCommit} = 1, which is the default, because most of the time I'm
just running SELECT's. But ::Oracle wouldn't ever complete the transaction,
hanging that server process and eventually most of the httpd system, all
waiting for the commit() on the INSERT (from the new Session) that doesn't
complete. I ended up having to do a local block, with Commit => 1:
{
local $dbh->{AutoCommit} = 0;
tie %session, 'Apache::Session::Oracle', $session_id, { Handle => $dbh,
Commit => 1};
$session_id = $session{_session_id}; # save a copy
_set_cookie( $r, SESSION_COOKIE, $session{_session_id} );
$session{referer} ||= $referer; # preserve prior entries
untie %session;
}
HTH!
L8r,
Rob
Re: Apache Processes hanging
At 10:37 AM -0400 5/3/01, Kevin Slean wrote: >Mod_perlers, > >I have a problem with Apache and was looking for your thoughts on my problem >or some additional mailing lists more focused on just Apache. > >I have 70 httpd daemons running and some of them just appear to hang. As >time goes by, the number of hung processes increases such that there are no >working ones left to perform real work. Consequently transaction processing >performance drops eventually to zero. > >Our web transactions running through these httpd daemons should not take >more than 60 seconds in a worst case scenario. Yet, some of these 'hung' >processes have been on the same transaction for over 30 hours. I >originally thought that this was a mod_perl problem and was buried in the >CGI/Perl routines performing the transactions. However, upon closer >inspection, I have found that these hanging processes are also running JAVA >servlets and gif gets. This makes me suspect that it is an Apache problem. > >I ran truss on the hung processes and found that they fell into two camps. >The first group was sitting at a read system call. The second group was in >a loop with sigalarm going off every 10 seconds. > >We are running the following: > > Hardware: Sun Ultra-250 > OS: Solaris 5.7 patch level 106541-12 > Apache: Apache/1.3.11 (Unix) ApacheJServ/1.1.2 mod_perl/1.24 > secured_by_Raven/1.4.2 > >Any ideas, thoughts, and comments are welcome. Thanks. > >Kevin I'm having similar problems, but we think it's directly related to Oracle. Basically, a connection is made to the Oracle database, a transaction is started and finished, but the connection to the database doesn't go away and the statement (at least from the oracle side) never seems to finish. The data is present in the database (these are insert statement, btw). Over time, every process collects one of these hanging statements and it eventually overwhelms our oracle database. The only solution is to restart apache every 5 minutes to eliminate the built-up non-finished transactions. Has anyone seen this before? Rob -- As soon as you make something foolproof, someone will create a better fool.
RE: :Parser & Expat cause segfaults
Reg this problem , Paul Kulchenko ( Soap::Lite wizard ) helped me with a solution given below, back last Fall . I used it with immediate success , and I hope it is applicable: ** SOLUTION ** If using SOAP::Lite (or XML::Parser::Expat) in combination with mod_perl causes random segmentation faults in httpd processes try to configure Apache with: RULE_EXPAT=no ** Sri Lakshmanan Market Data Services Koch Petroleum Group Tel (316) 828-3820 Fax (316) 828-4151 [EMAIL PROTECTED] > -Original Message- > From: Matt Sergeant [SMTP:[EMAIL PROTECTED]] > Sent: Thursday,May 03,2001 3:27 AM > To: Oskari 'Okko' Ojala > Cc: [EMAIL PROTECTED] > Subject: RE: :Parser & Expat cause segfaults > > On Thu, 3 May 2001, Oskari 'Okko' Ojala wrote: > > > On Thu, 3 May 2001, Stephen Anderson wrote: > > > > > > Got a problem: About 250 of 1000 requests cause a segfault > > > > (11) when using XML::Parser::parse() under mod_perl. > > > > > There's (apparently) a known symbol conflict between XML::Parser 2.30 > and > > > Apache (which I only know because it happened to someone here just the > other > > > day). Drop down to 2.29 and it should work fine. > > > > No success, I tried dropping the version down to 2.25, one by one. > > > > I also tried completely removing the expat from the apache source tree. > > The script still core dumps, but I found out that the same code as a > > mod_perl .cgi does not - it happens only when done under Mason. > > Make sure you comletely remove the old apache installation before your > recompile. This has caught me once. > > -- > > > /||** Founder and CTO ** ** http://axkit.com/ ** >//||** AxKit.com Ltd ** ** XML Application Serving ** > // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** > // \\| // ** mod_perl news and resources: http://take23.org ** > \\// > //\\ > // \\ >
Insecure dependency errors
Hi People. This is a strange problem, and I am not even sure if it is directly related to mod_perl or not, but since there has been a couple guys on this for a couple of hours now with no answers, I thought I woud check to see if anyone has seen such errors: [Thu May 3 15:06:57 2001] [error] Insecure dependency in open while running with -T switch at /usr/local/www/vhosts/ad-eagle.com/cgi-bin/ad-eagle/lib/AdEagle.pm line 472. The scripts using the .pm are running under Apache::Registry and have been running fine. Then last night a "major" upgrade was done to the servers. Now the scripts are dying with this error. None of them are running -T I don't think any on the server are, and know none under Apache::Registry are. Only Apache::Registry scripts are being affected. Anyone have any ideas as to where I could start looking? Thanks, and if it turns out to not be related to mod_perl, I apologize :-) I am about to suggest reinstalling Perl ... Barry _ Barry Veinotte Veinotte.com International, Inc. E-Mail: [EMAIL PROTECTED] Phone: 709.282.3233 http://www.veinotte.com http://ad-eagle.com http://pass-iton.com Software isn't released, it's allowed to escape. _
Re: HTTP::Cookies problem
Jonas Nordström <[EMAIL PROTECTED]> writes:
> How can I copy cookies from an incoming request to a LWP-request and also
> add a custom cookie? Can I use HTTP::Cookies?
>
> I use:
> $request->header('Cookie' => $r->header_in("Cookie"));
> and it works fine, but now I want to add a cookie that the client didn't
> send.
> Can I use $cookie_jar->set_cookie() and then
> $cookie_jar->add_cookie_header($request);? But what happens with the
> original cookies?
It goes away if any cookies from the $cookie_jar applies.
$cookie_jar->add_cookie_header() currently overrides the cookie header
by calling:
$request->header(Cookie => join("; ", @cval)) if @cval;
If we change this to:
$request->push_header(...)
then you get two header lines. Don't know if most server apps can
deal with it. Still anoter alternative would be to do something like:
if (my $old_cookie = $request->header('Cookie')) {
unshift(@cval, $old_cookie);
}
$request->header(Cookie => join("; ", @cval)) if @cval;
That should append to the current value if it was set.
Do you want this?
Regards,
Gisle
Re: Apache Processes hanging
On Thu, 3 May 2001, Kevin Slean wrote: > > Mod_perlers, > > I have a problem with Apache and was looking for your thoughts on my problem > or some additional mailing lists more focused on just Apache. > > I have 70 httpd daemons running and some of them just appear to hang. As > time goes by, the number of hung processes increases such that there are no > working ones left to perform real work. Consequently transaction processing > performance drops eventually to zero. > > Our web transactions running through these httpd daemons should not take > more than 60 seconds in a worst case scenario. Yet, some of these 'hung' > processes have been on the same transaction for over 30 hours. I > originally thought that this was a mod_perl problem and was buried in the > CGI/Perl routines performing the transactions. However, upon closer > inspection, I have found that these hanging processes are also running JAVA > servlets and gif gets. This makes me suspect that it is an Apache problem. > > I ran truss on the hung processes and found that they fell into two camps. > The first group was sitting at a read system call. The second group was in > a loop with sigalarm going off every 10 seconds. > > We are running the following: > >Hardware: Sun Ultra-250 > OS: Solaris 5.7 patch level 106541-12 > Apache: Apache/1.3.11 (Unix) ApacheJServ/1.1.2 mod_perl/1.24 > secured_by_Raven/1.4.2 > > Any ideas, thoughts, and comments are welcome. Thanks. Since you already truss()ed the processes and know that it's not a mod_perl problem, you probably want to take the question to the httpd mailing list. Meanwhile you can use Apache::Watchdog::RunAway to monitor and kill the processes that hang. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: HTTP::Cookies problem
On Thu, May 03, 2001 at 12:54:46PM +0200, Jonas Nordstr?m wrote:
> How can I copy cookies from an incoming request to a LWP-request and also
> add a custom cookie? Can I use HTTP::Cookies?
>
> I use:
> $request->header('Cookie' => $r->header_in("Cookie"));
> and it works fine, but now I want to add a cookie that the client didn't
> send.
> Can I use $cookie_jar->set_cookie() and then
> $cookie_jar->add_cookie_header($request);? But what happens with the
> original cookies?
so you just wanna forward a cookie? i'm not a cookie expert
(and how, look at my recent desperate posts) but i'd say
you can send whatever cookie you want, for whatever nefarious
purposes you'd like.
$req->header('Cookie' => $r->header_in('Cookie'));
$req->header('Cookie' => &my_new_cookie_monster( $something ));
as far as 'what happens with the original cookies' they stay with
the user's browser, until they expire (if an expire date was
given) or end-of-session (when browser is quit, if no expire was
given).
i think the answer to your question is, you can chain several
cookie headers on via the same ->header('Cookie' => ...) call.
--
don't visit this page. it's bad for you. take my expert word for it.
http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
RE: Apache Processes hanging
I can't help you, but I have been having the same problem. ( I had thought it was because we're running old code - Stronghold with mod_perl 1.24. I'm really hoping it goes away when we upgrade to 1.3.19 w 1.25, or at least I can have a better chance debugging it. ) My solution for the hung readers problem is to write another daemon that looks for them and kills them off. In order to do this, the daemon uses the /server-status URL to ask the web servers what processes are in the read state. If you want, I can post the code. -P > -Original Message- > From: Kevin Slean [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 03, 2001 10:38 AM > To: [EMAIL PROTECTED] > Subject: Apache Processes hanging > > > > Mod_perlers, > > I have a problem with Apache and was looking for your > thoughts on my problem > or some additional mailing lists more focused on just Apache. > > I have 70 httpd daemons running and some of them just appear > to hang. As > time goes by, the number of hung processes increases such > that there are no > working ones left to perform real work. Consequently > transaction processing > performance drops eventually to zero. > > Our web transactions running through these httpd daemons > should not take > more than 60 seconds in a worst case scenario. Yet, some of > these 'hung' > processes have been on the same transaction for over 30 hours. I > originally thought that this was a mod_perl problem and was > buried in the > CGI/Perl routines performing the transactions. However, upon closer > inspection, I have found that these hanging processes are > also running JAVA > servlets and gif gets. This makes me suspect that it is an > Apache problem. > > I ran truss on the hung processes and found that they fell > into two camps. > The first group was sitting at a read system call. The > second group was in > a loop with sigalarm going off every 10 seconds. > > We are running the following: > >Hardware: Sun Ultra-250 > OS: Solaris 5.7 patch level 106541-12 > Apache: Apache/1.3.11 (Unix) ApacheJServ/1.1.2 mod_perl/1.24 > secured_by_Raven/1.4.2 > > Any ideas, thoughts, and comments are welcome. Thanks. > > Kevin >
[OT] *O*L*D* messages!
For no reason I can explain, a sudden flurry of year-old messages I sent seems to have just resurfaced. While I have no idea what might've caused it, please take a moment to note the timestamp on messages you see from me, so as not to waste too much of your time. Thanks, all. Paul --- Eric Cholet <[EMAIL PROTECTED]> wrote: > > I got a very strange response from [EMAIL PROTECTED] > in > > response to a previous posting to this board. "jez" responded with > an > > "anti spamming notice"! > > > > It said the message was tossed into /dev/null, and that it was > either > > because I sent a "ms-tnef" attachment (I sent no attachment at all) > or > > because I was using Word (something I preach against, lol! =o) > > > > The message ended with "If neither of the above are the case, then > we > > just don't want to talk to you!!" > > I wouldn't take it personnally :-) If *you* received a bounce, > instead of > the list's envelope sender, then it means it's a very broken mail > server. > If this happens repeatedly the list admin will unsubsribe the > offending > user. > > -- > Eric > > > __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: hang time, segfaults
--- Cliff Woolley <[EMAIL PROTECTED]> wrote: > > It hangs a lot, especially on page reloads. Sometimes it delivers > > pages perfectly, other times it takes half a minute. The other day > > the error log piled up with several dozen segfault child expirations > > while checking it from a coworkers desk, which probably explains the > > empty document pages he kept getting. I have no real clue why. > > Check your SSLRandomSeed and SSLSessionCache settings. Your > SSLRandomSeed might be set to a blocking source of entropy (such as > /dev/random as opposed to /dev/urandom on some platforms). You might > be using a DBM Session Cache and be using a broken DBM library. What > are these set to for you? SSLRandomSeed startup builtin SSLRandomSeed connect builtin SSLSessionCache dbm:/dart10/web/userdb/ssl_scache I *have* had a little trouble with the ssl_scache losing it's mind, so that it asked for the cert on every request And though this is one of those messages I sent out a year ago, it's one that I never got a solution for. I'm *still* having this problem! All too frequently, pages just don't load. ANY help on this matter is appreciated! > > The one thing amiss I can find is probably just ignorance on my > > part. When I telnet to the server, it's return output includes > > numbers that I am not seeing in my web pages, which are no logical > > part of the output that I understand, and aren't there from the > > normal server. > > >GET / HTTP/1.1(** I send request headers **) > >Host: buda.bst.bls.com > > >HTTP/1.1 302 Found(** It responds correctly **) > >Date: Tue, 30 May 2000 14:39:03 GMT > >Server: Apache/1.3.12 (Unix) mod_perl/1.23 mod_ssl/2.6.4 [line wrapped here] OpenSSL/0.9.5a > >Location: https://buda.bst.bls.com:8443/ > >Transfer-Encoding: chunked > > NOTE THIS HEADER. > > >Content-Type: text/html; charset=iso-8859-1 > > >15a (** but what is this? **) > > > > > >302 Found > > > >Found > >The document has moved >HREF="https://buda.bst.bls.com:8443/";>here. > > > >Apache/1.3.12 Server at >HREF="mailto:[EMAIL PROTECTED] > >m">bos04111.al.bst.bls.com Port 8080 > > > > > >0 (** and this? **) > > The "extra" numbers denote the beginning and end of a chunk in the > chunked encoding of the body of the response. (Transfer-Encoding: > chunked). If you had a long response, it could be in multiple > chunks. > That's all. So no, they're not part of the web page, and yes, they > are correct. =-) This is completely unrelated to > slowness/hangs/segfaults. > > Hope this helps. This I had gotten an answer for, but thanks for the time nonetheless! ;o] > --Cliff So, when SSLSessionCache uses dbm:/some/path, what dbm library does it use? I'm on an HP_UX B.10.20 OS, which has always been pretty rock-solid stable for us -- the only bug I've ever know for sure was in the EBCDIC-ASCII conversion functions in C, but I rolled my own in Perl. =o) Paul __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Apache Processes hanging
Mod_perlers, I have a problem with Apache and was looking for your thoughts on my problem or some additional mailing lists more focused on just Apache. I have 70 httpd daemons running and some of them just appear to hang. As time goes by, the number of hung processes increases such that there are no working ones left to perform real work. Consequently transaction processing performance drops eventually to zero. Our web transactions running through these httpd daemons should not take more than 60 seconds in a worst case scenario. Yet, some of these 'hung' processes have been on the same transaction for over 30 hours. I originally thought that this was a mod_perl problem and was buried in the CGI/Perl routines performing the transactions. However, upon closer inspection, I have found that these hanging processes are also running JAVA servlets and gif gets. This makes me suspect that it is an Apache problem. I ran truss on the hung processes and found that they fell into two camps. The first group was sitting at a read system call. The second group was in a loop with sigalarm going off every 10 seconds. We are running the following: Hardware: Sun Ultra-250 OS: Solaris 5.7 patch level 106541-12 Apache: Apache/1.3.11 (Unix) ApacheJServ/1.1.2 mod_perl/1.24 secured_by_Raven/1.4.2 Any ideas, thoughts, and comments are welcome. Thanks. Kevin
RE: :Parser & Expat cause segfaults
On Thu, 3 May 2001, Oskari 'Okko' Ojala wrote: > I'll let you know if the problem gets solved. Upgrading to Perl 5.6.1 seems to do the job. Thanks to all who helped! Oskari Ojala
RE: PerlAccessHandler via set_handlers()?
> -Original Message-
> From: will trillich [mailto:[EMAIL PROTECTED]]
>
> thanks one and all for the pointers on cookies. i probably grok
> 738% more than i did, but i have a feeling it's still only 13% of
> the pie. or in this case, cookie...
>
> so how's this PerlAccessHandler, for twisted logic? hole-punching
> and pitfall-warning equally welcome:
This ought to work fine, but it probably won't scale well if you ever have a
need to extend this to support multiple authentication paths (more than one
user database or user type). You'll just end up pushing more and more logic
into the handler which is going to get you into trouble. This won't scale
at all if you ever need to create a central login/ticket server.
The beauty of the example in the Eagle book (and Apache::AuthTicket) is that
it defines distinct handlers for distinct URL spaces which, in turn,
correspond to distinct functions (prompt for login, authentication,
authorization). If you ever have the need to separate these across multiple
servers, you'll have difficulties with your scheme.
Also, you'll always have to be extremely careful when extending this in the
future to always unshift login or authentication handlers when you return OK
or DECLINED. Since you've lumped login prompt/authentication/authorization
all into a single handler, returning OK without a challenge/authentication
handler will immediately grant access to the requested resource.
>
> #httpd.conf
> PerlAccessHandler My::TrollUnderTheBridge
> PerlHandler Something::OrOther
>
> #perl
> package My::TrollUnderTheBridge;
>
> sub handler {
> my $r = shift;
>
> if ( &logging_in($r) ) {
>
> my $h = $r->get_handlers( 'PerlHandler' );
> unshift @{$h},\&checkUser ; # do
> &checkUser first
> $r->set_handlers( PerlHandler => $h );
I think this is wrong. checkUser() should be a PerlAccessHandler. You
should probably simply return &checkUser rather than waiting until the
content handler phase.
>
> } elsif ( &needs_login($r) ) {
>
> $r->set_handlers( PerlHandler => [ \&login ] );
> # return AUTH_REQUIRED; or not ?
Not. Can only return OK, DECLINED or FORBIDDEN in a PerlAccessHandler.
Besides AUTH_REQUIRED (in a PerlAuthHandler) will prompt for a HTTP basic
authentication session, which you certainly don't want. Should simply
return OK or DECLINED and let the request fall through to the PerlHandler.
>
> }
>
> return OK;
> }
>
> sub checkUser {
> my $r = shift;
> if ( &bad_passwd( $r ) ) {
> # generate html for username/password
> login screen, again
> &login( $r );
> # we handled it, other handlers won't
> be called (right?)
> return OK;
> } else {
> $r->headers_out->add( 'Set-Cookie' =>
> &make_ticket( $r ) );
> # let normal handler do its thing
> return DECLINED;
> }
> }
>
> so i can keep the same url for all three stages, with no need for
> preliminary cookies:
>
> 3. valid ticket -> show web pages
> else
> 2. validate user/pass -> make ticket & show pages
> else
> 1. login -> get user/pass
>
> is this sound? or am i fuxnored?
>
> --
>
> but then from within &login() i'd like to be able to abort, like
> so--
>
HTTP::Cookies problem
How can I copy cookies from an incoming request to a LWP-request and also
add a custom cookie? Can I use HTTP::Cookies?
I use:
$request->header('Cookie' => $r->header_in("Cookie"));
and it works fine, but now I want to add a cookie that the client didn't
send.
Can I use $cookie_jar->set_cookie() and then
$cookie_jar->add_cookie_header($request);? But what happens with the
original cookies?
/Jonas
RE: :Parser & Expat cause segfaults
On Thu, 3 May 2001, Oskari 'Okko' Ojala wrote: > On Thu, 3 May 2001, Stephen Anderson wrote: > > > > Got a problem: About 250 of 1000 requests cause a segfault > > > (11) when using XML::Parser::parse() under mod_perl. > > > There's (apparently) a known symbol conflict between XML::Parser 2.30 and > > Apache (which I only know because it happened to someone here just the other > > day). Drop down to 2.29 and it should work fine. > > No success, I tried dropping the version down to 2.25, one by one. > > I also tried completely removing the expat from the apache source tree. > The script still core dumps, but I found out that the same code as a > mod_perl .cgi does not - it happens only when done under Mason. Make sure you comletely remove the old apache installation before your recompile. This has caught me once. -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
RE: :Parser & Expat cause segfaults
On Thu, 3 May 2001, Stephen Anderson wrote: > > Got a problem: About 250 of 1000 requests cause a segfault > > (11) when using XML::Parser::parse() under mod_perl. > There's (apparently) a known symbol conflict between XML::Parser 2.30 and > Apache (which I only know because it happened to someone here just the other > day). Drop down to 2.29 and it should work fine. No success, I tried dropping the version down to 2.25, one by one. I also tried completely removing the expat from the apache source tree. The script still core dumps, but I found out that the same code as a mod_perl .cgi does not - it happens only when done under Mason. Someone reported to me that he has the same behaviour with Solaris 2.8 x86. He gets core dumps with XML::Parser::parse() under Mason, too, but not without it. I'll mail to Mason's developer about this. I'll let you know if the problem gets solved. Oskari Ojala
RE: :Parser & Expat cause segfaults
> -Original Message- > From: Oskari 'Okko' Ojala [mailto:[EMAIL PROTECTED]] > Got a problem: About 250 of 1000 requests cause a segfault > (11) when using > XML::Parser::parse() under mod_perl. In FAQs it is stated that this is > because of the bundled Expat in Apache. > > I've tried disabling Apache's Expat with --disable-rule=EXPAT, but it > doesn't help. > > Have you found any workarounds or patches, or is the reason to my > segfaults somewhere else? > > Platform: > > Red Hat 7.0 > Apache 1.3.19 > mod_perl 1.25 > perl 5.6.0 > expat 1.95.1 > HTML::Mason 1.02 > XML::Parser 2.30 There's (apparently) a known symbol conflict between XML::Parser 2.30 and Apache (which I only know because it happened to someone here just the other day). Drop down to 2.29 and it should work fine. Stephen.
