Re: Question and problem with graphics and Apache:ASP running.
Steve Hurley wrote: > > When I turn on Apache:ASP and try to load a few html files it messes up the graphics >at the top. > > Now if I turn off the ASP, graphics load fine... > Page with banner graphics split up: http://www.clark.cc.oh.us/asp/student.html > page with one banner graphic...: http://www.clark.cc.oh.us/asp/student2.html > > in http.conf: > > SetHandler perl-script > PerlHandler Apache::ASP > PerlSetVar Global /tmp > > If you want to mix media types in the same directory, use the Files Apache config to mark certain files for Apache::ASP execution like so: SetHandler perl-script PerlHandler Apache::ASP PerlSetVar NoState 1 I'm guessing that Apache::ASP was trying to parse anything under /asp/, including graphics, which just _might_ mess things up :) -- Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks >> free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: Apache::Request problem (possible bug)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At 1:07 AM +1000 4/7/01, Cees Hek wrote:
> $r->param('newlist' => [qw(one two three)]);
>
> my @newlist = $r->param('newlist');
my @newlist = @{$r->param('newlist')};
What you stored was not an array, but a reference to an array.
- --
Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects
Now Playing - Folk, Rock, odd stuff - http://www.somewhere.com/playlist.cgi
Now Writing - Technosocial buzz - http://commons.somewhere.com/buzz/
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
-BEGIN PGP SIGNATURE-
Version: PGPfreeware 7.0.3 for non-commercial use
iQA/AwUBOs3IhyZsPfdw+r2CEQKJdgCggzcUkVZyshv0FlIon8adiDRqOIwAnRWv
EDOxp/nQOjVxPJRyhd/BydE3
=Eyiy
-END PGP SIGNATURE-
Question and problem with graphics and Apache:ASP running.
When I turn on Apache:ASP and try to load a few html files it messes up the graphics at the top. Now if I turn off the ASP, graphics load fine... Page with banner graphics split up: http://www.clark.cc.oh.us/asp/student.html page with one banner graphic...: http://www.clark.cc.oh.us/asp/student2.html in http.conf: SetHandler perl-script PerlHandler Apache::ASP PerlSetVar Global /tmp The split up version will work but the one banner will be distorted. Now if I save as on the graphic and view it, it looks fine Any ideas??? Thanks, Steve
RE: Apache::Request problem (possible bug)
this was fixed in cvs this past month. check out the archive of the
apreq-dev list (if there is one somewhere) to see the details. basically it
was because using param() to set a variable was calling Apache::Table->set,
which stringifies its arguments. Now it calls Apache::Table->add and does
some undef'ing, allowing you to set multiple values from a ref.
--Geoff
-Original Message--
From: Cees Hek
To: [EMAIL PROTECTED]
Sent: 4/6/01 11:07 AM
Subject: Apache::Request problem (possible bug)
Either I've found a problem with Apache::Request, or I don't know what
I'm
doing :)
Setting variables with $r->param() doesn't seem to work for array
references. ie the following line from the man page doesn't work
correctly
$r->param('foo' => [qw(one two three)]);
When you look at foo afterwards it returns the string 'ARRAY(0x8c04fd8)'
instead of an actual reference to the array.
I have include a basic handler that demostrates this on my machine
(Apache/1.3.17 mod_perl/1.24 perl 5.005_03)
package Apache::Test;
# File: Apache/Test.pm
use strict;
use Apache::Constants qw(:common);
use Apache::Request ();
sub handler {
my $r = new Apache::Request(shift);
$r->content_type('text/html');
$r->send_http_header();
my @list = $r->param('list');
$r->param('newlist' => [qw(one two three)]);
my @newlist = $r->param('newlist');
my $list = join ', ', @list;
my $newlist = join ', ', @newlist;
print <<"EOM";
list - $list
newlist - $newlist
Blue
Green
Red
Yellow
EOM
return OK;
}
1;
--
Cees Hek
SiteSuite Corporation
[EMAIL PROTECTED]
Apache::Request problem (possible bug)
Either I've found a problem with Apache::Request, or I don't know what I'm
doing :)
Setting variables with $r->param() doesn't seem to work for array
references. ie the following line from the man page doesn't work
correctly
$r->param('foo' => [qw(one two three)]);
When you look at foo afterwards it returns the string 'ARRAY(0x8c04fd8)'
instead of an actual reference to the array.
I have include a basic handler that demostrates this on my machine
(Apache/1.3.17 mod_perl/1.24 perl 5.005_03)
package Apache::Test;
# File: Apache/Test.pm
use strict;
use Apache::Constants qw(:common);
use Apache::Request ();
sub handler {
my $r = new Apache::Request(shift);
$r->content_type('text/html');
$r->send_http_header();
my @list = $r->param('list');
$r->param('newlist' => [qw(one two three)]);
my @newlist = $r->param('newlist');
my $list = join ', ', @list;
my $newlist = join ', ', @newlist;
print <<"EOM";
list - $list
newlist - $newlist
Blue
Green
Red
Yellow
EOM
return OK;
}
1;
--
Cees Hek
SiteSuite Corporation
[EMAIL PROTECTED]
Re: Problem with Apache::DBI
On Thu, 5 Apr 2001, Alec Smith wrote:
> In my module I've got:
>
> use DBI;
> use Apache::DBI;
> $db = DBI->connect('DBI:mysql:dbname', 'username', 'password', {RaiseError
> => 1, AutoCommit => 1});
Have a read of the Apache::DBI man page and it will explain what is wrong
here.
You don't need to add Apache::DBI in your module.
> and in startup.pl:
>
> use DBI;
> use Apache::DBI;
> Apache::DBI->connect_on_init('DBI:mysql:dbname', 'username',
> 'password',{RaiseError => 1, AutoCommit => 1});
The use Apache::DBI should come bofore the use DBI call. In fact, the use
Apache::DBI should come before you load any DBI enabled modules in you
config files.
Cees Hek
>
> yet I'm still seeing the error
>
> Issuing rollback() for database handle being DESTROY'd without explicit
> disconnect() at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 139.
>
> in the logs.
>
> Still lost,
> Alec
>
>
> At 09:24 AM 4/5/01 +0100, you wrote:
> >You would only get that message if AutoCommit was off.
> >It should not be off for DBD::mysql (since it doesn't yet support
> >the transaction features of newer versions).
> >
> >Plus, disconnect doesn't do anything when using Apache::DBI
> >(by design).
> >
> >Tim.
> >
> >On Wed, Apr 04, 2001 at 11:49:17PM -0400, Alec Smith wrote:
> > > Issuing rollback() for database handle being DESTROY'd without explicit
> > > disconnect() at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 139.
> > >
> > > Using Apache::DBI 0.88+DBI 1.14+mod_perl 1.25+MySQL 3.23.36 I'm getting
> > the
> > > above in my error_log and am not sure why. Any ideas? I do have a
> > > $db->disconnect; line in my modules.
> > >
> > > Just a tad lost,
> > > Alec
>
>
>
--
Cees Hek
SiteSuite Corporation
[EMAIL PROTECTED]
Re: Problem with Apache::DBI
In my module I've got:
use DBI;
use Apache::DBI;
$db = DBI->connect('DBI:mysql:dbname', 'username', 'password', {RaiseError
=> 1, AutoCommit => 1});
and in startup.pl:
use DBI;
use Apache::DBI;
Apache::DBI->connect_on_init('DBI:mysql:dbname', 'username',
'password',{RaiseError => 1, AutoCommit => 1});
yet I'm still seeing the error
Issuing rollback() for database handle being DESTROY'd without explicit
disconnect() at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 139.
in the logs.
Still lost,
Alec
At 09:24 AM 4/5/01 +0100, you wrote:
>You would only get that message if AutoCommit was off.
>It should not be off for DBD::mysql (since it doesn't yet support
>the transaction features of newer versions).
>
>Plus, disconnect doesn't do anything when using Apache::DBI
>(by design).
>
>Tim.
>
>On Wed, Apr 04, 2001 at 11:49:17PM -0400, Alec Smith wrote:
> > Issuing rollback() for database handle being DESTROY'd without explicit
> > disconnect() at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 139.
> >
> > Using Apache::DBI 0.88+DBI 1.14+mod_perl 1.25+MySQL 3.23.36 I'm getting
> the
> > above in my error_log and am not sure why. Any ideas? I do have a
> > $db->disconnect; line in my modules.
> >
> > Just a tad lost,
> > Alec
Re: Problem with Apache::DBI
I have exactly the same errors in my log. AutoCommit not specified in connect method, therefore 'on' by default. Now, specify AutoCommit explicitly and wait for errors. - Sergey Polyakov aka "BeerBong" Chief of WebZavod http://www.webzavod.ru Tel. +7 (8462) 43-93-85 | +7 (8462) 43-93-86 mailto:[EMAIL PROTECTED] - Original Message - From: "Tim Bunce" <[EMAIL PROTECTED]> To: "Alec Smith" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, April 05, 2001 12:24 PM Subject: Re: Problem with Apache::DBI > You would only get that message if AutoCommit was off. > It should not be off for DBD::mysql (since it doesn't yet support > the transaction features of newer versions). > > Plus, disconnect doesn't do anything when using Apache::DBI > (by design). > > Tim. > > On Wed, Apr 04, 2001 at 11:49:17PM -0400, Alec Smith wrote: > > Issuing rollback() for database handle being DESTROY'd without explicit > > disconnect() at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 139. > > > > Using Apache::DBI 0.88+DBI 1.14+mod_perl 1.25+MySQL 3.23.36 I'm getting the > > above in my error_log and am not sure why. Any ideas? I do have a > > $db->disconnect; line in my modules. > > > > Just a tad lost, > > Alec >
Re: Problem with Apache::DBI
Similar problem here but not quite
First time now I want to use a database handler more persistent.
Not yet by using Apache::DBI but in a global $DBH
Shouldn't this just work?
I did not put Apache::DBI in startup file
I also tried code outside handler and I tried server restarts.
I always get a server has gone
use DBI ();
use Apache::Reload;
use vars qw($DBH $DB_TABLE $ID_LENGTH, %SESSION);
sub handler {
my $r = shift;
$DBH = DBI->connect(DSN,undef,undef) unless defined($DBH) ;
or: $DBH ||= DBI->connect(DSN,undef,undef) unless defined($DBH) ;
my $bla = $DBH->do("select 1 from $DB_TABLE");
[Thu Apr 5 12:33:21 2001] null: DBD::mysql::db do failed: MySQL server
has gone away at /usr/local/apache/lib/perl/Navvy/NavvyLijst.pm line 59.
Arnold
On Thu, 5 Apr 2001, Tim Bunce wrote:
> You would only get that message if AutoCommit was off.
> It should not be off for DBD::mysql (since it doesn't yet support
> the transaction features of newer versions).
>
> Plus, disconnect doesn't do anything when using Apache::DBI
> (by design).
>
> Tim.
>
> On Wed, Apr 04, 2001 at 11:49:17PM -0400, Alec Smith wrote:
> > Issuing rollback() for database handle being DESTROY'd without explicit
> > disconnect() at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 139.
> >
> > Using Apache::DBI 0.88+DBI 1.14+mod_perl 1.25+MySQL 3.23.36 I'm getting the
> > above in my error_log and am not sure why. Any ideas? I do have a
> > $db->disconnect; line in my modules.
> >
> > Just a tad lost,
> > Alec
>
Re: Problem with Apache::DBI
You would only get that message if AutoCommit was off. It should not be off for DBD::mysql (since it doesn't yet support the transaction features of newer versions). Plus, disconnect doesn't do anything when using Apache::DBI (by design). Tim. On Wed, Apr 04, 2001 at 11:49:17PM -0400, Alec Smith wrote: > Issuing rollback() for database handle being DESTROY'd without explicit > disconnect() at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 139. > > Using Apache::DBI 0.88+DBI 1.14+mod_perl 1.25+MySQL 3.23.36 I'm getting the > above in my error_log and am not sure why. Any ideas? I do have a > $db->disconnect; line in my modules. > > Just a tad lost, > Alec
Problem with Apache::DBI
Issuing rollback() for database handle being DESTROY'd without explicit disconnect() at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 139. Using Apache::DBI 0.88+DBI 1.14+mod_perl 1.25+MySQL 3.23.36 I'm getting the above in my error_log and am not sure why. Any ideas? I do have a $db->disconnect; line in my modules. Just a tad lost, Alec
Compress::Zlib problem
One of my developers is looking for a way to take records output from a database and compress them into a gzip file on the fly, without using a file on disk. To do this, he's using Compress::Zlib and passing \*STDOUT as the output file. Since this is mod_perl, STDOUT is blessed to Apache, and appears to be missing Apache::TELL. # $fh is \*STDOUT my $gz = gzopen($fh, 'wb'); $gz->gzwrite($line); # $line is from db. He's also played with deflating the content on his own, but is unable to get the checksum correct on the output. Has anyone ever compressed something like this on the fly with Compress::Zlib. As I understand it, Apache::Compress creates seperate files, which is not acceptable in this case. Thanks, Robert Landrum -- As soon as you make something foolproof, someone will create a better fool.
Strange Problem with opendir / readdir
Hi!
I have strange problems while using opendir / readdir
under MasonHQ. I'm not shure, but it seems to be a perl / modperl / Apache
or Mason Bug.
I have no problem to run the same directly from the shell.
Is the a known bug?
Kind regards
Cornelius Kuschnereit
Environement:
Apache 1.3.19
modperl 1.25
mason 1.01
RedHat 7.0
reiserfs
--
test1_opendir.html
my little test:
--
<%init>
my $directory = qq[/usr/local/apache];
my $dir;
my @dirs= ();
opendir( DIR, $directory );
@dirs = readdir( DIR );
close( DIR );
Test -
% foreach $dir (sort @dirs) {
file:<% $dir %>
% }
<<<<
--
the (wrong) result:
--
Test -
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
<<<<
--
--
test1_opendir.pl
my little (working) test:
--
#!/usr/bin/perl
my $directory = qq[/usr/local/apache];
my $dir;
my @dirs= ();
opendir( DIR, $directory );
@dirs = readdir( DIR );
close( DIR );
print "Test - \n";
foreach $dir (sort @dirs) {
print "file: $dir\n";
}
print "<<<<<\n";
--
the (right) result:
--
Test -
file: .
file: ..
file: bin
file: cgi-bin
file: conf
file: htdocs
file: htdocs_mason_data_cache
file: icons
file: include
file: libexec
file: logs
file: man
file: perlmod
file: proxy
<<<<<
--
RE: [Mason] Strange Problem with opendir / readdir
Yes! I can see all Files and Dirs without . and .. Can this be a hint why readdir dosn't work? Thanx! Cornelius -- the (right) result: -- Test -x 1 file:"/usr/local/apache/bin" length of filename:21 2 file:"/usr/local/apache/cgi-bin" length of filename:25 3 file:"/usr/local/apache/conf" length of filename:22 4 file:"/usr/local/apache/htdocs" length of filename:24 5 file:"/usr/local/apache/htdocs_mason_data_cache" length of filename:41 6 file:"/usr/local/apache/htdocs_mason_data_cache2" length of filename:42 7 file:"/usr/local/apache/icons" length of filename:23 8 file:"/usr/local/apache/include" length of filename:25 9 file:"/usr/local/apache/libexec" length of filename:25 10 file:"/usr/local/apache/logs" length of filename:22 11 file:"/usr/local/apache/man" length of filename:21 12 file:"/usr/local/apache/perlmod" length of filename:25 13 file:"/usr/local/apache/proxy" length of filename:23 >Does glob() work? >my @files = glob( "$directory/*" );
Re: [Mason] Strange Problem with opendir / readdir
Does glob() work?
my @files = glob( "$directory/*" );
Thanks,
Tim Tompkins
--
Staff Engineer / Programmer
http://www.arttoday.com/
--
- Original Message -
From: "Cornelius Kuschnereit" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, March 30, 2001 3:27 AM
Subject: [Mason] Strange Problem with opendir / readdir
> Hi!
> I have strange problems while using opendir / readdir
> under MasonHQ. I'm not shure, but it seems to be a perl / modperl / Apache
> or Mason Bug.
> I have no problem to run the same directly from the shell.
>
> Is the a known bug?
>
> Kind regards
> Cornelius Kuschnereit
>
> Environement:
> Apache 1.3.19
> modperl 1.25
> mason 1.01
> RedHat 7.0
> reiserfs
>
> --
> test1_opendir.html
> my little test:
> --
> <%init>
> my $directory = qq[/usr/local/apache];
> my $dir;
> my @dirs= ();
>
> opendir( DIR, $directory );
> @dirs = readdir( DIR );
> close( DIR );
>
> Test -
> % foreach $dir (sort @dirs) {
> file:<% $dir %>
> % }
> <<<<
> --
> the (wrong) result:
> --
> Test -
> file:
> file:
> file:
> file:
> file:
> file:
> file:
> file:
> file:
> file:
> file:
> file:
> file:
> file:
> <<<<
> --
>
> --
> test1_opendir.pl
> my little (working) test:
> --
> #!/usr/bin/perl
>
> my $directory = qq[/usr/local/apache];
> my $dir;
> my @dirs= ();
>
> opendir( DIR, $directory );
> @dirs = readdir( DIR );
> close( DIR );
> print "Test - \n";
>
> foreach $dir (sort @dirs) {
> print "file: $dir\n";
> }
> print "<<<<<\n";
> --
> the (right) result:
> --
> Test -
> file: .
> file: ..
> file: bin
> file: cgi-bin
> file: conf
> file: htdocs
> file: htdocs_mason_data_cache
> file: icons
> file: include
> file: libexec
> file: logs
> file: man
> file: perlmod
> file: proxy
> <<<<<
> --
>
>
>
>
>
> ___
> Mason-users mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/mason-users
>
Re: Strange Problem with opendir / readdir
On Fri, 30 Mar 2001, Cornelius Kuschnereit wrote: > I have strange problems while using opendir / readdir > under MasonHQ. I'm not shure, but it seems to be a perl / modperl / Apache > and not a Mason Bug. > I have no problem to run the same directly from the shell. > > Is there a known bug? As far as I can tell, it's a mod_perl, glibc2.2 compatibility bug. - Paul
[OT] Re: Strange Problem with opendir / readdir
Cornelius Kuschnereit wrote:
> @dirs = readdir( DIR );
> foreach $dir (sort @dirs) {
next unless -d "directory/$dir";
> print "file: $dir\n";
> }
[OT] Re: Strange Problem with opendir / readdir
Cornelius Kuschnereit wrote: > opendir( DIR, $directory ); opendir( DIR, $directory ) or die "Can't read $directory because of $!";
Re: Strange Problem with opendir / readdir
On Fri, 30 Mar 2001, Cornelius Kuschnereit wrote: > Hi! > I have strange problems while using opendir / readdir > under MasonHQ. I'm not shure, but it seems to be a perl / modperl / Apache > and not a Mason Bug. > I have no problem to run the same directly from the shell. > > Is there a known bug? A known bug: http://forum.swarthmore.edu/epigone/modperl/landchoigrerm :( _ 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/
Strange Problem with opendir / readdir
Hi!
I have strange problems while using opendir / readdir
under MasonHQ. I'm not shure, but it seems to be a perl / modperl / Apache
and not a Mason Bug.
I have no problem to run the same directly from the shell.
Is there a known bug?
Kind regards
Cornelius Kuschnereit
Environement:
Apache 1.3.19
modperl 1.25
mason 1.01
RedHat 7.0
reiserfs
--
test1_opendir.html
my little test:
--
<%init>
my $directory = qq[/usr/local/apache];
my $dir;
my @dirs= ();
opendir( DIR, $directory );
@dirs = readdir( DIR );
close( DIR );
Test -
% foreach $dir (sort @dirs) {
file:<% $dir %>
% }
<<<<
--
the (wrong) result:
--
Test -
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
<<<<
--
--
test1_opendir.pl
my little (working) test:
--
#!/usr/bin/perl
my $directory = qq[/usr/local/apache];
my $dir;
my @dirs= ();
opendir( DIR, $directory );
@dirs = readdir( DIR );
close( DIR );
print "Test - \n";
foreach $dir (sort @dirs) {
print "file: $dir\n";
}
print "<<<<<\n";
--
the (right) result:
--
Test -
file: .
file: ..
file: bin
file: cgi-bin
file: conf
file: htdocs
file: htdocs_mason_data_cache
file: icons
file: include
file: libexec
file: logs
file: man
file: perlmod
file: proxy
<<<<<
--
Problem reading postdata
Hello. When I try to read in modperl/apache/win32 the script just ignore the $/ and read all of it to the end. It works fine to read single lines from STDIN in cgi-bin scripts. Any tips? (i'm using Randy Kobes' binary Perl-5.6.0, mod_perl-1.23, and Apache_1.3.12) kind regards Tomas
Re: File upload problem
Actually I've tried the following piece of code.
$inputfile = $Request->Form('Offer');
%><%=$inputfile%><%
open (OUTFILE,">/export/home0/www/biznet/offers/newfile")
or die "Can not write to file because of
$!";
binmode OUTFILE;
binmode $inputfile;
while (read($inputfile,$buffer,1024))
{
print OUTFILE $buffer;
} ## end while
close OUTFILE;
The form that leads to this code is the following
My problem is that ithe ASP page creates the file wanted but it is
empty.
Am I doing something wrong??
At 09:04 ðì 26/3/2001 -0800, you wrote:
--- Sophokles Zafeiris
<[EMAIL PROTECTED]> wrote:
> Hi,
> I'm new in mod_perl.
> I'm trying to write an ASP script using Perlscript that will be
able
> to perform file uploading from an html form.
> Is there any script that I could use?
Check the docs on CGI.pm, which will handle practically all the
painful
parts for you. Just be *SURE* to create a multipart form! It won't
work
otherwise. (It's all in the docs. =o)
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
File upload problem
Hi, I'm new in mod_perl. I'm trying to write an ASP script using Perlscript that will be able to perform file uploading from an html form. Is there any script that I could use?
Problem with mod_perl 1.25 as a DSO with Apache 1.3.19 on Digital Unix 4.0F
I am trying to use mod_perl 1.25 with Apache 1.3.19 on Digital Unix version 4.0F. When I build the DSO and try to load it into Apache, I get: Syntax error on line 486 of /usr/local/www/apache/1.3.19/conf/httpd.conf: Cannot load /usr/local/www/apache/1.3.19/libexec/libperl.so into server: Unresolved symbol in /usr/local/www/apache/1.3.19/libexec/libperl.so: PL_tmps_ix This is with perl 5.6.0 (I tried first with 5.005_03). When building perl on Digital Unix, the default is to build libperl as a shared library instead of a static library. This is called libperl.so. I thought that mod_perl being libperl.so might be a problem, so I renamed it to libmodperl.so, but that didn't seem to help. It appears that Apache is not loaded the perl library when loading the mod_perl DSO for some reason. I would prefer to keep mod_perl as a DSO (I have several instances of Apache on this server, and I only want mod_perl available in one of them, and it makes upgrading MUCH easier if there is only one Apache binary). Any ideas? Anyone else using mod_perl as a DSO with libperl as a shared library? -- Chris Adams <[EMAIL PROTECTED]> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Problem with mod_perl 1.25 as a DSO with Apache 1.3.19 on Digital Unix 4.0F
I am trying to use mod_perl 1.25 with Apache 1.3.19 on Digital Unix version 4.0F. When I build the DSO and try to load it into Apache, I get: Syntax error on line 486 of /usr/local/www/apache/1.3.19/conf/httpd.conf: Cannot load /usr/local/www/apache/1.3.19/libexec/libperl.so into server: Unresolved symbol in /usr/local/www/apache/1.3.19/libexec/libperl.so: PL_tmps_ix This is with perl 5.6.0 (I tried first with 5.005_03). When building perl on Digital Unix, the default is to build libperl as a shared library instead of a static library. This is called libperl.so. I thought that mod_perl being libperl.so might be a problem, so I renamed it to libmodperl.so, but that didn't seem to help. It appears that Apache is not loaded the perl library when loading the mod_perl DSO for some reason. I would prefer to keep mod_perl as a DSO (I have several instances of Apache on this server, and I only want mod_perl available in one of them, and it makes upgrading MUCH easier if there is only one Apache binary). Any ideas? Anyone else using mod_perl as a DSO with libperl as a shared library? -- Chris Adams <[EMAIL PROTECTED]> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Problem with Tie::DBI and DBI in modperl
On Tue, 20 Mar 2001, John Mulkerin wrote: > There is no error message returned, it just goes back to the httpd 403 > error screen. What about in the error log? Have you read the DBI docs on how to get your error message to print? You should either have RaiseError on or be checking return codes from every DBI call. If you haven't turned PrintError off, DBI will issue a warning that goes to your log when it fails to connect. - Perrin
Re: Problem with Tie::DBI and DBI in modperl
Searched this list, dbiusers, and a bunch more.I'm not sure if its something so dump it's never discussed or what. There is no error message returned, it just goes back to the httpd 403 error screen. I've added a print statement in the middle of the connect and had it print to the screen and it looks the same rather I'm in Perl or via Mod_perl. Here is the result from the print: "dbi:mysql:its,helpman,secret01,HASH(0xaf798b4)" Looks like it should work, but nothing seems to be returned from the "return DBI->connect($dsn,$user,$password,$options)" statement. John - Original Message - From: "Perrin Harkins" <[EMAIL PROTECTED]> To: "John Mulkerin" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, March 19, 2001 11:34 PM Subject: Re: Problem with Tie::DBI and DBI in modperl > On Mon, 19 Mar 2001, John Mulkerin wrote: > > I'm trying to use the plain vanilla TicketTool.pm from O'Reilly's mod > > perl book, Apache Modules with Perl and C. It uses Tie::DBI to create > > a hash of the mysql connection. When I run just the authentication > > subroutine with Perl -d "authenticate.pm" it runs fine. Whe I run it > > as part of the web server, it fails in the connect statement in the > > Tie:DBI routine. > > What is the exact error message? Have you tried searching the mailing > list archive for that message? Are you using PHP in your server? > > - Perrin >
Re: Problem with Tie::DBI and DBI in modperl
On Mon, 19 Mar 2001, John Mulkerin wrote: > I'm trying to use the plain vanilla TicketTool.pm from O'Reilly's mod > perl book, Apache Modules with Perl and C. It uses Tie::DBI to create > a hash of the mysql connection. When I run just the authentication > subroutine with Perl -d "authenticate.pm" it runs fine. Whe I run it > as part of the web server, it fails in the connect statement in the > Tie:DBI routine. What is the exact error message? Have you tried searching the mailing list archive for that message? Are you using PHP in your server? - Perrin
Problem with Tie::DBI and DBI in modperl
O mighty Wizards please help if you can:
I'm trying to use the plain vanilla TicketTool.pm from O'Reilly's mod perl
book, Apache Modules with Perl and C. It uses Tie::DBI to create a hash of
the mysql connection. When I run just the authentication subroutine with
Perl -d "authenticate.pm" it runs fine. Whe I run it as part of the web
server, it fails in the connect statement in the Tie:DBI routine. I've
been struggling for months on this. Could anyone help? I figured maybe I
have a "use statement wrong but I've tried more combos than I'll ever
remember.
John Mulkerin
Use lines from TicketTool.pm:
package Apache::TicketTool; use strict;use Tie::DBI ();use
CGI::Cookie ();use MD5 ();use LWP::Simple ();use Apache::File
();use Apache::URI (); use DBI;
Problem line in script:
tie my %DB, 'Tie::DBI', {
'db' => 'mysql:its',
'table' => 'passwd', 'key' => 'username',
'user' => 'helpman', password => 'secret01',
} or print "Couldn not open database \n";
Problem line in Tie::DBI
sub connect {
my ($class,$dsn,$user,$password,$options) = @_;
return DBI->connect($dsn,$user,$password,$options);
Startup.pl (from apache conf directory)
BEGIN {
use Apache ();
use lib Apache->server_root_relative('libexec/perl');
}
# Commonly used modules
use Tie::DBI ();
use Apache::DBI ();
use Apache::Registry ();
use Apache::Constants();
use CGI qw(-compile :all);
use CGI::Carp ();
1;
~
Re: problem with installation
Henri Delebecque writes: Henri for future please make sure you reply to the [EMAIL PROTECTED] list as well then others can see the entire conversation it seems i was wrong in telling you what i said as evidenced be stas's reply to your post i was unaware of the problem he described (thanks stas) please refer to his reply thanks > Hello, > > Thanks for your answer. > > > > >this would suggest to me that there is something wrong with the > >Makefile in that directory or a Makefile doesnt exist there > You're right: the Makefile in this directory is relatively old, > much older that the Makefile in the mod_perl directory. > It seems that the perl script doesn't generate a Makefile > in the /webmaster/apache/src directory... > > > > >the APACHE_SRC directive should point to the src subdirectory of the > >apache source you are compiling mod_perl with > Yes, I have check it . > > I have currently tried to delete the whole mod_perl directory, > and regenerate it from the tar archive. I have renamed the > Makefile in the /webmaster/apache/src to another name, and > relaunch the perl script. It never creates a Makefile in the > /webmaster/apache/src directory... > > a suggestion ? > Thanks
Re: problem with installation
On Mon, 5 Mar 2001, Henri Delebecque wrote: > hello, > > I'm sure that's trivial, but I'm a newbie in using mod_perl. > I have read the FAQ, which tells that I should read the documentation. > I have read the http://perl.apache.org/guide/install.html page, > and the "A Summary of a Basic mod_perl installation" section. > > when I execute the following command: > perl Makefile.PL APACHE_SRC=/webmaster/apache/src \ > DO_HTTPD=1 EVERYTHING=1 USE_APACI=1 \ > APACHE_PREFIX=/webmaster/apache/httpd.perl, > > the perl script runs well, but when I try to make httpd, I > encounter the following error message: > > "entering /webmaster/apache/src" > "no rule to make target 'all'. Stop" > > My server is a Digital/Unix, under Digital Unix 4 > > any hint ? > thanks alot Hmm, may be it has something to do with Digital, but if not, make sure that /webmaster/apache actually includes the apache sources. I'll repeat the steps here: % cd /usr/src % lwp-download http://www.apache.org/dist/apache_x.x.x.tar.gz % lwp-download http://perl.apache.org/dist/mod_perl-x.xx.tar.gz % tar xzvf apache_x.x.x.tar.gz % tar xzvf mod_perl-x.xx.tar.gz % cd mod_perl-x.xx % perl Makefile.PL APACHE_SRC=../apache_x.x.x/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 % make && make test && make install % cd ../apache_x.x.x % make install replace x.x.x and x.xx with the versions that you use. if that doesn't help what do you see if you go to apache_x.x.x/src and type: % ./configure % make ? _ 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: problem with installation
Henri Delebecque writes: > hello, > > I'm sure that's trivial, but I'm a newbie in using mod_perl. > I have read the FAQ, which tells that I should read the documentation. > I have read the http://perl.apache.org/guide/install.html page, > and the "A Summary of a Basic mod_perl installation" section. > > when I execute the following command: > perl Makefile.PL APACHE_SRC=/webmaster/apache/src \ > DO_HTTPD=1 EVERYTHING=1 USE_APACI=1 \ > APACHE_PREFIX=/webmaster/apache/httpd.perl, > > the perl script runs well, but when I try to make httpd, I > encounter the following error message: > > "entering /webmaster/apache/src" > "no rule to make target 'all'. Stop" this would suggest to me that there is something wrong with the Makefile in that directory or a Makefile doesnt exist there the APACHE_SRC directive should point to the src subdirectory of the apache source you are compiling mod_perl with > My server is a Digital/Unix, under Digital Unix 4
problem with installation
hello, I'm sure that's trivial, but I'm a newbie in using mod_perl. I have read the FAQ, which tells that I should read the documentation. I have read the http://perl.apache.org/guide/install.html page, and the "A Summary of a Basic mod_perl installation" section. when I execute the following command: perl Makefile.PL APACHE_SRC=/webmaster/apache/src \ DO_HTTPD=1 EVERYTHING=1 USE_APACI=1 \ APACHE_PREFIX=/webmaster/apache/httpd.perl, the perl script runs well, but when I try to make httpd, I encounter the following error message: "entering /webmaster/apache/src" "no rule to make target 'all'. Stop" My server is a Digital/Unix, under Digital Unix 4 any hint ? thanks alot __ | Henri Delebecque[EMAIL PROTECTED] | | Webmaster | | Supelec Tel (33) 01.69.85.14.91 | | 3 rue Joliot-Curie | | Plateau de Moulon Fax:(33) 01.69.85.12.34 | | 91190 Gif sur Yvette| | FRANCE | |_|
Problem with connect to mysql - seg faults
Hi, I wrote a script that search the mysql database. At first I ran it as plain CGI it works well, but problem is when it runs with mod_perl - it starts with seg fault, apache log: [Sat Feb 24 10:44:51 2001] [notice] child pid 24856 exit signal Segmentation fault (11) It seems that seg fault caused by the connect method of DBI, because when I comment this line the script runs OK. But the strange thing is that: when I put this line (with DBI->connect) out of the program flow, to some place where it won't be executed the script still seg faults - maybe it is something wrong at compile time? My config: Debian Potato, Mysql 3.22.32, Apache 1.3.14, mod_perl 1.25, Perl 5.6, DBI 1.14, mysql DBD 1.2215 Thanks for any help. Regards, Mirek Rewak [EMAIL PROTECTED]
RE: Apache::DBI::connect problem, please help
Thank you, Geoff and Arun. I am doing it the way you suggest.
My problem turned out to be a bad installation of Apache::DBI.pm.
(it was just a copy of DBI.pm).
> -Original Message-
> From: Arun Theeban [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 20, 2001 11:39 PM
> To: Geoffrey Young; 'Brad Howerter'; '[EMAIL PROTECTED]'
> Subject: RE: Apache::DBI::connect problem, please help
>
>
> You have to put Apache::DBI before any of the DBI's
> you are using in httpd.conf file.
>
> In your cgi programs use only "DBI" not "Apache::DBI"
> module.
>
> a simple program would be.
>
> #! /usr/bin/perl
> print "Content-type:text/html\n\n";
> $dbh=DBI->connect("DBI::Pg::dbname=emp","user","passwod");
> print " connected successfully ";
> $dbh->disconnect;
>
> if Apache::DBI was loaded before DBI, some of the
> fuctions would be overridden.
>
> Even if you give $dbh->disconnect,Apache::DBI will
> override funtion to nothing.
> -Arun
>
> --- Geoffrey Young <[EMAIL PROTECTED]> wrote:
> >
> >
> > > -Original Message-
> > > From: Brad Howerter [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, February 20, 2001 12:57 PM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: Apache::DBI::connect problem, please
> > help
> > >
> > [snip]
> > > So Apache/DBI.pm must be installed incorrectly on
> > my system.
> > > It's supposed to be different from the DBI.pm?
> >
> > yup, you need both. DBI is, well, DBI. Apache::DBI
> > is a persistent
> > framework under mod_perl that uses DBI.
> >
> > HTH
> >
> > --Geoff
> k
>
> __
> Do You Yahoo!?
> Yahoo! Auctions - Buy the things you want at great prices!
http://auctions.yahoo.com/
RE: Apache::DBI::connect problem, please help
You have to put Apache::DBI before any of the DBI's
you are using in httpd.conf file.
In your cgi programs use only "DBI" not "Apache::DBI"
module.
a simple program would be.
#! /usr/bin/perl
print "Content-type:text/html\n\n";
$dbh=DBI->connect("DBI::Pg::dbname=emp","user","passwod");
print " connected successfully ";
$dbh->disconnect;
if Apache::DBI was loaded before DBI, some of the
fuctions would be overridden.
Even if you give $dbh->disconnect,Apache::DBI will
override funtion to nothing.
-Arun
--- Geoffrey Young <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: Brad Howerter [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, February 20, 2001 12:57 PM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: Apache::DBI::connect problem, please
> help
> >
> [snip]
> > So Apache/DBI.pm must be installed incorrectly on
> my system.
> > It's supposed to be different from the DBI.pm?
>
> yup, you need both. DBI is, well, DBI. Apache::DBI
> is a persistent
> framework under mod_perl that uses DBI.
>
> HTH
>
> --Geoff
k
__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
RE: Apache::DBI::connect problem, please help
> -Original Message- > From: Brad Howerter [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 20, 2001 12:57 PM > To: '[EMAIL PROTECTED]' > Subject: RE: Apache::DBI::connect problem, please help > [snip] > So Apache/DBI.pm must be installed incorrectly on my system. > It's supposed to be different from the DBI.pm? yup, you need both. DBI is, well, DBI. Apache::DBI is a persistent framework under mod_perl that uses DBI. HTH --Geoff
RE: Apache::DBI::connect problem, please help
> -Original Message- > From: Brad Howerter [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 20, 2001 12:42 PM > To: ''[EMAIL PROTECTED]' ' > Subject: RE: Apache::DBI::connect problem, please help > > > > > > From: Geoffrey Young [mailto:[EMAIL PROTECTED]] > > you need both, DBI and Apache::DBI, with DBI loaded first... > > I tried this, but I still get the same error. sorry, I gave you bad information - Apache::DBI needs to be loaded first... it was late :) use Apache::DBI; use DBI; > > > > see the Apache::DBI manpage for more detail > > That man page is the same as the DBI manpage- it doesn't include > any modperl specific information. um, not so... man Apache::DBI and man DBI should definitely yield different results. HTH --Geoff
RE: Apache::DBI::connect problem, please help
> > > From: Geoffrey Young [mailto:[EMAIL PROTECTED]] > > > you need both, DBI and Apache::DBI, with DBI loaded first... > > > > I tried this, but I still get the same error. > > sorry, I gave you bad information - Apache::DBI needs to be > loaded first... > it was late :) That's okay- I've tried it both ways, and I get the same result. > > use Apache::DBI; > use DBI; > > > > > > > see the Apache::DBI manpage for more detail > > > > That man page is the same as the DBI manpage- it doesn't include > > any modperl specific information. > > um, not so... man Apache::DBI and man DBI should definitely > yield different > results. So Apache/DBI.pm must be installed incorrectly on my system. It's supposed to be different from the DBI.pm?
RE: Apache::DBI::connect problem, please help
> From: Geoffrey Young [mailto:[EMAIL PROTECTED]]
> you need both, DBI and Apache::DBI, with DBI loaded first...
I tried this, but I still get the same error.
>
> see the Apache::DBI manpage for more detail
That man page is the same as the DBI manpage- it doesn't include
any modperl specific information.
> -Original Message-
> From: Brad Howerter
> To: '[EMAIL PROTECTED]'
> Sent: 2/19/01 6:54 PM
> Subject: Apache::DBI::connect problem, please help
>
> I'm getting this error:
>
> [error] Can't locate object
> method "connect" via package "Apache::DBI::connect" at
> /usr/local/lib/perl5/site_perl/5.6.0/i386-dynixptx/DBI.pm line 408.
>
> One way I can avoid the error is to change startup.pl
> to use DBI() instead of use Apache::DBI(). Why does that
> fix it? And does it hurt anything if I don't use Apache::DBI()?
> What's that for, anyway? Is Apache/DBI.pm supposed to be
> the same as the other one in the perl library? (It is)
>
> my startup.pl has this in it:
>
> #!/usr/bin/perl
> use strict;
> $ENV{MOD_PERL} or die "Not running under mod_perl!";
>
> use Apache::Registry;
> use Apache::DBI ();
>
> # Tell me more about warnings
> use Carp;
> $SIG{__WARN__} = \&Carp::cluck;
>
> use CGI qw(-compile :all);
> 1;
>
> and my test program is this:
>
> #!/usr/local/bin/perl
> use strict;
>
> use Carp;
> $SIG{__WARN__} = \&Carp::cluck;
>
> use DBI;
> use DBD::Oracle;
> use CGI ();
>
> my $cgi = new CGI;
> print $cgi->header; my $db = DBI->connect('', 'scott',
> 'tiger', { } ) or
> die
> DBI::errstr;
> print "Connected!\n";
>
RE: Apache::DBI::connect problem, please help
you need both, DBI and Apache::DBI, with DBI loaded first...
see the Apache::DBI manpage for more detail
HTH
--Geoff
-Original Message-
From: Brad Howerter
To: '[EMAIL PROTECTED]'
Sent: 2/19/01 6:54 PM
Subject: Apache::DBI::connect problem, please help
I'm getting this error:
[error] Can't locate object
method "connect" via package "Apache::DBI::connect" at
/usr/local/lib/perl5/site_perl/5.6.0/i386-dynixptx/DBI.pm line 408.
One way I can avoid the error is to change startup.pl
to use DBI() instead of use Apache::DBI(). Why does that
fix it? And does it hurt anything if I don't use Apache::DBI()?
What's that for, anyway? Is Apache/DBI.pm supposed to be
the same as the other one in the perl library? (It is)
my startup.pl has this in it:
#!/usr/bin/perl
use strict;
$ENV{MOD_PERL} or die "Not running under mod_perl!";
use Apache::Registry;
use Apache::DBI ();
# Tell me more about warnings
use Carp;
$SIG{__WARN__} = \&Carp::cluck;
use CGI qw(-compile :all);
1;
and my test program is this:
#!/usr/local/bin/perl
use strict;
use Carp;
$SIG{__WARN__} = \&Carp::cluck;
use DBI;
use DBD::Oracle;
use CGI ();
my $cgi = new CGI;
print $cgi->header; my $db = DBI->connect('', 'scott', 'tiger', { } ) or
die
DBI::errstr;
print "Connected!\n";
Apache::DBI::connect problem, please help
I'm getting this error:
[error] Can't locate object
method "connect" via package "Apache::DBI::connect" at
/usr/local/lib/perl5/site_perl/5.6.0/i386-dynixptx/DBI.pm line 408.
One way I can avoid the error is to change startup.pl
to use DBI() instead of use Apache::DBI(). Why does that
fix it? And does it hurt anything if I don't use Apache::DBI()?
What's that for, anyway? Is Apache/DBI.pm supposed to be
the same as the other one in the perl library? (It is)
my startup.pl has this in it:
#!/usr/bin/perl
use strict;
$ENV{MOD_PERL} or die "Not running under mod_perl!";
use Apache::Registry;
use Apache::DBI ();
# Tell me more about warnings
use Carp;
$SIG{__WARN__} = \&Carp::cluck;
use CGI qw(-compile :all);
1;
and my test program is this:
#!/usr/local/bin/perl
use strict;
use Carp;
$SIG{__WARN__} = \&Carp::cluck;
use DBI;
use DBD::Oracle;
use CGI ();
my $cgi = new CGI;
print $cgi->header; my $db = DBI->connect('', 'scott', 'tiger', { } ) or die
DBI::errstr;
print "Connected!\n";
[OT] intermitant path info problem
I think this message if probably off-topic, but I am getting rather desperate and I don't know where to turn. I have a script that produces quite a large report. When trying to print it using Netscape netscape tell me 'POST DATA MISSING', in order to prevent that from happening, I convert the POST request to a GET request by putting the passed parameters in the path info. (The added advantage of doing that is that the proxy will then cache the report.) This seems to work on some reports, however for some reports I get a '404 File Not Found' error. I have got no idea why this happens or where to look. I am currently using apache 1.3.12, mod_perl 1.21, mason 1.0, perl 5.003_03 Kees Vonk Internet Programmer 7249 27705 __ The views expressed in this email are not necessarily the views of Transco plc, and the company, its directors, officers or employees make no representation or accept any liability for its accuracy or completeness unless expressly stated to the contrary. This e-mail, and any attachments are strictly confidential and intended for the addressee(s) only. The content may also contain legal, professional or other privileged information. If you are not the intended recipient, could you please notify the sender immediately and then delete the e-mail and any attachments, you should not disclose, copy or take any action in reliance of this transmission. Unless expressly stated to the contrary, no contracts may be concluded on behalf of Transco plc by means of e-mail communication. You may report the matter by calling us on +44 (0)1455 230999. You should not copy, forward or otherwise disclose the contents of this e-mail or any of its attachments without express consent. Please ensure you have adequate virus protection before you open or detach any documents from this transmission. Transco plc does not accept any liability for viruses. Transco plc is part of Lattice Group Transco plc is registered in England: Company number: 2006000 Registered Office: 130 Jermyn Street, London, SW1Y 4UR http://www.transco.uk.com
Re: mod_vhost_alias / ProxyPassReverse problem
Ime Smits <[EMAIL PROTECTED]> wrote: > >Now this all works fine except when a client side redirect using meta >http-equiv tags occurs, in which case the hostname part in the url holds a >:81 suffix, effectively bypassing the proxy. Use the following config: Listen 81 Port 80 In the presence of a Listen directive, the Port directive acts like ServerName, i.e. it's what the server calls itself regardless of the name that other people use to get to it. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] FISHER: NORTHWEST 5 OR 6 DECREASING 3. SHOWERS. GOOD.
RE: baffled by vs. problem [SOLVED]
Thanks ... I finally figured out what it was ... the path I was using in was not consistent with the one used in DocumentRoot because of the use of symlinks. I fixed that and things are working fine now. Ray
RE: baffled by vs. problem
> -Original Message- > From: Ray Zimmerman [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 13, 2001 4:10 PM > To: modperl List > Subject: baffled by vs. problem > > [snip] > > When I put the following in my httpd.conf ... > > > SetHandler perl-script > PerlHandler Apache::Hello > > > and access the same URL, mod_perl handles it. But if I > change the > entry in httpd.conf to ... > > > SetHandler perl-script > PerlHandler Apache::Hello > > > it goes back to executing the CGI. Do you have an Alias set up for /home/ray/www/hello? make sure you do and that it's not a ScriptAlias. you may also want to check your AddHandler directive and remove the .cgi entry if there is one - looks like mod_cgi is stepping in where you don't want it to... HTH --Geoff
baffled by vs. problem
I ran into a problem trying to get MysqlTool running under mod_perl
using the instructions in the included README, so I've broken down my
problem into a simple Hello World script (modified from the one in
the Eagle book) that demonstrates the same problem.
The problem I'm having is that I can get directives to
pass control to a mod_perl handler OK, but if I try to switch it to a
, it stops working.
I have an Apache::Hello.pm that just displays the values of the
MOD_PERL and GATEWAY_INTERFACE env vars.
I have a CGI script /hello/index.cgi that just calls
Apache::Hello::handler. This CGI works fine ( $ENV{MOD_PERL} and
$ENV{GATEWAY_INTERFACE} as expected for outside of mod_perl ).
When I put the following in my httpd.conf ...
SetHandler perl-script
PerlHandler Apache::Hello
... and access the same URL, mod_perl handles it. But if I change the
entry in httpd.conf to ...
SetHandler perl-script
PerlHandler Apache::Hello
... it goes back to executing the CGI.
I must be missing something obvious, right?
Ray
P.S. In case it matters, this is Perl 5.00503, Apache 1.3.17,
mod_perl 1.25 running on Red Hat 6.2.
NISPlus-0.06-alpha problem
Hi,
I recently build Apache_1.3.14 with Mod_perl-1.24_01 on Solaris system
when I testing NIS+ portion I got terminal hung in Module Table.pm
The code actually hung is in sub colnames. I also cut that portion onto
here.
The line that atually waitting for return is the bolded blue line(which I
don't have a clue what it is doing.)
I was using interactive debugger to be able to isloate to this point.
Is there any person can point me in the right direction?
I'll appreciate any help
Thanks,
PC
sub colnames
{
my($me) = shift;
my($ret, $res);
if (!defined($me->{'colnames'}))
{
($ret, $res) = Net::NISPlus::table_info($me->fullPath);
if ($ret != 0)
{
Warning("colnames error: ", niserror($ret), "\n");
return ();
}
else
{
$me->{'colnamesarr'} = $res->{'ta_cols'};
foreach ($[..$#{@{$me->{'colnamesarr'}}})
{
$me->{'colnameshash'}->{$me->{'colnamesarr'}->[$_]} = $_;
}
}
}
return(@{$me->{'colnamesarr'}}) if wantarray;
return($me->{'colnameshash'});
}
Re: Problem with libapreq on RH 6.2
Hi, your system may have perl libraries installed in more than one place -- set the PERLLIB variable in the root profile to all the places perl modules may be (if you have multiple copies of perl, just stick together the @INC from the different ones, or pick one that works...). here's an example from a root .bash_profile on a machine that had that problem: PERLLIB="/usr/lib/perl5/5.6.0/i386linux:/usr/lib/perl5/5.6.0:/usr/lib/perl5/site_perl/5.6.0/i386-linux:/usr/lib/perl5/site_perl/5.6.0:/usr/lib/perl5/site_perl:/usr/local/lib/perl5/5.6.0/i586linux:/usr/local/lib/perl5/5.6.0:/usr/local/lib/perl5/site_perl/5.6.0/i586-linux:/usr/local/lib/perl5/site_perl/5.6.0:/usr/local/lib/perl5/site_perl:.:/usr/local/lib/perl5/5.6.0/i686-linux:/usr/local/lib/perl5/5.6.0:/usr/local/lib/perl5/site_perl/5.6.0/i686-linux:/usr/local/lib/perl5/site_perl/5.6.0:/usr/local/lib/perl5/site_perl:." export ... PERLLIB ... -Noam x Andy Williams wrote: > I have seen mails flying around about a problem on RH using RPMs for > Apache/mod_perl and libapreq. > So I decided to build Apache (1.3.17), mod_perl (1.25) and libapreq > (0.31_03) from source. > > All installed without any suggestion of a problem. However, when I try to > run Apache (configured to use OpenInteract 1.05) I get the following > error: > OpenInteract::Startup::require_module (236) >> --require error: > Apache::Request : Can't load > '/usr/lib/perl5/site_perl/5.005/i386-linux/auto/Apache/Request/Request.so' > for module Apache::Request: libapreq.so.0: cannot open shared object file: > No such file or directory at > /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169, chunk 4. > > at /usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 65535 > > OpenInteract::Startup::require_module (236) >> --require error: > Apache::Cookie : Can't load > '/usr/lib/perl5/site_perl/5.005/i386-linux/auto/Apache/Cookie/Cookie.so' > for module Apache::Cookie: libapreq.so.0: cannot open shared object file: > No such file or directory at > /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169, chunk 5. > > at /usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 65535 > > Does anyone have any idea why this is happening? > > TIA > > Andy > > > > "Talkie Toaster: Given that God is infinite, and that the > Universe is also infinite, would you like a toasted tea > cake?" > >
Re: mod_vhost_alias / ProxyPassReverse problem
I was going to suggest having the backend server listen on localhost:80, with the proxying server listening on :80, then the redirects from either would be to port 80. This suggestion of Tony's certainly seems like a cleaner solution though. (Plus, I learned something I didn't know about this interaction of Listen and Port directives -- always "a good thing" (tm) ;^) On Mon, 12 Feb 2001, Ime Smits wrote: > | Use the following config: > | Listen 81 > | Port 80 > | In the presence of a Listen directive, the Port directive acts like > | ServerName, i.e. it's what the server calls itself regardless of the > | name that other people use to get to it. > > OK, thanks a lot, that does the trick. I tried that earlier today, but I > overlooked an explicit ServerName directive somewhere else in httpd.conf, > overruling mod_vhost_alias... > > Thanks again! > > Ime > =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-= Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ |
Re: mod_vhost_alias / ProxyPassReverse problem
| Use the following config: | Listen 81 | Port 80 | In the presence of a Listen directive, the Port directive acts like | ServerName, i.e. it's what the server calls itself regardless of the | name that other people use to get to it. OK, thanks a lot, that does the trick. I tried that earlier today, but I overlooked an explicit ServerName directive somewhere else in httpd.conf, overruling mod_vhost_alias... Thanks again! Ime
Problem with libapreq on RH 6.2
I have seen mails flying around about a problem on RH using RPMs for Apache/mod_perl and libapreq. So I decided to build Apache (1.3.17), mod_perl (1.25) and libapreq (0.31_03) from source. All installed without any suggestion of a problem. However, when I try to run Apache (configured to use OpenInteract 1.05) I get the following error: OpenInteract::Startup::require_module (236) >> --require error: Apache::Request : Can't load '/usr/lib/perl5/site_perl/5.005/i386-linux/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.0: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169, chunk 4. at /usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 65535 OpenInteract::Startup::require_module (236) >> --require error: Apache::Cookie : Can't load '/usr/lib/perl5/site_perl/5.005/i386-linux/auto/Apache/Cookie/Cookie.so' for module Apache::Cookie: libapreq.so.0: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169, chunk 5. at /usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 65535 Does anyone have any idea why this is happening? TIA Andy "Talkie Toaster: Given that God is infinite, and that the Universe is also infinite, would you like a toasted tea cake?"
Re: mod_vhost_alias / ProxyPassReverse problem
For what it is worth, I once again fixed my own problem by hacking
http_core.c on the backend:
[root@nobel src]# diff -U 6 ../build/apache_1.3.14/src/main/http_core.c
http_core_hack-1.3.14.c
--- ../build/apache_1.3.14/src/main/http_core.c Tue Oct 10 19:33:09 2000
+++ http_core_hack-1.3.14.c Mon Feb 12 17:02:53 2001
@@ -758,16 +758,17 @@
API_EXPORT(char *) ap_construct_url(pool *p, const char *uri,
request_rec *r)
{
unsigned port = ap_get_server_port(r);
const char *host = ap_get_server_name(r);
-if (ap_is_default_port(port, r)) {
+// XXX HACK: get rid of the port number on redirects
+// if (ap_is_default_port(port, r)) {
return ap_pstrcat(p, ap_http_method(r), "://", host, uri, NULL);
-}
-return ap_psprintf(p, "%s://%s:%u%s", ap_http_method(r), host, port,
uri);
+//}
+// return ap_psprintf(p, "%s://%s:%u%s", ap_http_method(r), host, port,
uri);
}
Dunno if this will break other things, it doesn't seem to in my setup, and
for the moment I'm happy.
Ime
Re: mod_vhost_alias / ProxyPassReverse problem
On Mon, 12 Feb 2001, Ime Smits wrote:
> Hi,
>
> I have a mod_perl backend listening on *:81 and a proxy in front of it
> listening on *:80, both using mod_vhost_alias configured with
>
I'm using squid in httpd-accellerator mode on port 80.
And I have no problems with redirects and with any other specific things
in web sites programming process.
And in fact, squid eating less memory and cpu resources than apache proxy
module.
> VirtualDocumentRoot /www/site/%0
>
> i.e. www.mydomain.com will have /www/site/www.mydomain.com as it's document
> root. The frontend has
>
>
> RewriteEngine On
> ...
> RewriteRule \.(jpg|png|swf|css|html|txt|cgi)$ - [last]
> RewriteRule ^/(.*)$ http://%{HTTP_HOST}:81/$1 [proxy]
>
>
> Now this all works fine except when a client side redirect using meta
> http-equiv tags occurs, in which case the hostname part in the url holds a
> :81 suffix, effectively bypassing the proxy. Now, the problem is I cannot
> use ProxyPassReverse because it doesn't eat hostnames as its first argument.
>
> What's the advisable thing here? Should I consider hacking around in
> src/main/util_uri.c? Can this be fixed by a fixup handler (maybe replacing
> r->uri_components->port?) Or should I just drop mod_vhost_alias on the
> backend and start using perl sections to do a directory scan on /www/site
> and setup all my VirtualHosts that way? Has anybody done this before?
>
> Ime
>
>
Vasily Petrushin
+7 (095) 2508363
http://www.interfax.ru
mailto:[EMAIL PROTECTED]
mod_vhost_alias / ProxyPassReverse problem
Hi,
I have a mod_perl backend listening on *:81 and a proxy in front of it
listening on *:80, both using mod_vhost_alias configured with
VirtualDocumentRoot /www/site/%0
i.e. www.mydomain.com will have /www/site/www.mydomain.com as it's document
root. The frontend has
RewriteEngine On
...
RewriteRule \.(jpg|png|swf|css|html|txt|cgi)$ - [last]
RewriteRule ^/(.*)$ http://%{HTTP_HOST}:81/$1 [proxy]
Now this all works fine except when a client side redirect using meta
http-equiv tags occurs, in which case the hostname part in the url holds a
:81 suffix, effectively bypassing the proxy. Now, the problem is I cannot
use ProxyPassReverse because it doesn't eat hostnames as its first argument.
What's the advisable thing here? Should I consider hacking around in
src/main/util_uri.c? Can this be fixed by a fixup handler (maybe replacing
r->uri_components->port?) Or should I just drop mod_vhost_alias on the
backend and start using perl sections to do a directory scan on /www/site
and setup all my VirtualHosts that way? Has anybody done this before?
Ime
Re: PerlRun problem: undefined variables (Was: can't find method "uri")
On Thu, 11 Jan 2001, Doug MacEachern wrote:
> On Thu, 4 Jan 2001, Jie Gao wrote:
>
> > Another problem with PerlRun is that it seems to interfere with mod_perl
> > handlers.
> >
> > I have an authentication/authorisation handler, which reads in from a
> > file for someinformation. After a script under PerlRun is run, the handler
> > fails to read anything from that file anymore.
>
> i can't see what's happening from this, too much missing. can you provide
> a small, but complete drop-in test case?
Sorry for this late reply, Doug. Here are some details.
This is from my authentication handler, which gets the location of a
file from a PerlSetVar directive, and then opens the file and reads
username and password into the variables to be used for database
connection:
---
my ($dsf, $db_f_name, $db_user_name, $db_user_pwd, $ds_name, $AuthenQueryValue);
# Get the db data source file.
$dsf = $r->dir_config( 'DSF' );
if (!defined $dsf || $dsf eq '') {
$r->log_error("DSF not defined.") if ($debug > 3);
return SERVER_ERROR;
}
# Get the db server login info.
if (defined $dsf) {
open(DBCONF, "$dsf") || $r->log_error("Can't open DSF file $dsf:$!");
while(){
next if /^#/;
next unless /^$ds_name:/;
chomp;
($ds_name, $db_f_name, $db_user_name, $db_user_pwd) = split(':', $_);
$r->log_error("In loop: ds_name=\"$ds_name\", db_f_name=\"$db_f_name\",
db_user_name=\"$db_user_name\
", db_user_pwd=\"$db_user_pwd\"\n") if ($debug > 3);
last;
}
close DBCONF;
} else {
$r->log_reason("DB source file not defined.") if ($debug > 3);
return SERVER_ERROR;
}
unless (defined $db_f_name && defined $db_user_name && defined $db_user_pwd) {
$r->log_reason("DB source file error: definition incomplete:
db_f_name=\"$db_f_name\"; db_user_name=\"$db
_user_name\"; db_user_pwd=\"$db_user_pwd\".") if ($debug > 3);
return SERVER_ERROR;
}
---
Now from time to time these variables become undefined, as shown in the error_log:
[Sat Feb 10 12:30:13 2001] [error] access to / failed for 129.xx.xx.xx, reason: DB
source file error: definition
incomplete: db_f_name=""; db_user_name=""; db_user_pwd="".
This happens with 1.25 as well.
Hardcoding the variables prevents this from happening.
Regards,
Jie
Re: BSDI 4.1 libperl.so problem
Hi there, On Thu, 8 Feb 2001, Aaron Schlesinger wrote: > % apachectl configtest > Syntax error on line 207 of /usr/local/apache/conf/httpd.conf: > Cannot load /usr/local/apache/libexec/libperl.so into server: File not found > > % ls -l /usr/local/apache/libexec/libperl.so > -rwxr-xr-x 1 root wheel 210522 Feb 8 13:49 /usr/local/apache/libexec/libperl.so > As you can see the file is there. Well some of it is... c2h5oh:/usr/local/apache/libexec$ >>> ls -l libperl.so -rwxr-xr-x 1 root root 1160538 Sep 14 16:02 libperl.so* c2h5oh:/usr/local/apache/libexec$ >>> (I take it you've checked the permissions on all the directories in the path?:) 73, Ged.
BSDI 4.1 libperl.so problem
Hi there. I am having a HELL of a time trying to get mod_perl compiled into apache 1_3.17. I built it using APXS and I really have tried everything I can think of. It makes, and builds without a problem. When I try to do a configtest (after installing the new LoadModule and such into the httpd.conf file) I get this: % apachectl configtest Syntax error on line 207 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/apache/libexec/libperl.so into server: File not found % % ls -l /usr/local/apache/libexec/libperl.so -rwxr-xr-x 1 root wheel 210522 Feb 8 13:49 /usr/local/apache/libexec/libperl .so % As you can see the file is there. I am running BSDI 4.1 and Apache 1_3.17 trying to compile mod_perl 1.25 HELP :) Aaron Schlesinger __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
Antwort: Re: Problem with $r->register_cleanup()
There are no other handlers besides my own (content and auth) and the core
apache...
Also, I'd think that every reload of a page (that get's served by the same
Apache child) should execute the same code and handlers with the same
result---but here's the register_cleanup sometimes gets called and sometimes
not. I press Reload, Reload, Reload... and get the result as below...
Michael
Datum: 07.02.2001 23:37
An:Michael Jacob/EXT/GAD@GAD
Kopie: [EMAIL PROTECTED]
Betreff: Re: Problem with $r->register_cleanup()
Nachrichtentext:
Is it possible that another handler (such as CGI, or parsed-html) is
taking over before yours and exiting or returning OK.
Rob
>Hi,
>
>I just ran into a problem with $r->register_cleanup() only sometime beeing
>called.
>
>This is mod_perl 1.24_01, perl 5.6.0, apache 1.3.14 compiled with gcc 5.6.0 on
>AIX 4.3.3.
>
>Here's a sample code (snippet):
>
>sub handler { # PerlTransHandler
> my $r = shift;
> $r->register_cleanup(\&clean1);
> $r->push_handlers(PerlCleanupHandler => \&clean2);
> $r->pnotes('cleanup', bless {} );
> print STDERR 'in ";
> return DECLINE;
>}
>
>sub clean1 { print STDERR "register_cleanup "; }
>sub clean2 { print STDERR "push_handlers "; }
>sub DESTROY { print STDERR "DESTROY\n"; }
>
>And that's the error_log:
>
>in register_cleanup push_handlers DESTROY
>in register_cleanup push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in register_cleanup push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in register_cleanup push_handlers DESTROY
>in push_handlers DESTROY
>
>
>The pushed handler only get's called about a third or less of the time. :-(
>
>Any idea, bug?
>
>Michael Jacob
>
>PS: Yes I did some tests with -x...
Robert L. Landrum
Senior Programmer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"It's working correctly. It's simply working in contrast to what you have
perceived to be correct."
Re[2]: File::Cache problem
Hello DeWitt,
Wednesday, February 07, 2001, 6:51:24 PM, you wrote:
DC> On Wed, Feb 07, 2001 at 04:02:39PM +0400, BeerBong wrote:
>> Cache size after 24 hours of working
>> via 'du -s' - 53M
>> via 'perl -MFile::Cacje -e"print File::Cache::SIZE('PRTL')"' - 10M
DC> That looks like a serious bug. Can you double check on that? Where
DC> are you running the "du -s"?
maul:/tmp/File::Cache/apache# ls
PRTL PRTLDev
maul:/tmp/File::Cache/apache# du -s *
27924 PRTL
536 PRTLDev
maul:/tmp/File::Cache/apache# perl -MFile::Cache -e"print File::Cache::SIZE('PRTL')"
4178662
maul:/tmp/File::Cache/apache# perl -MFile::Cache
-e"File::Cache::REDUCE_SIZE(100,'PRTL')"
maul:/tmp/File::Cache/apache# perl -MFile::Cache -e"print File::Cache:SIZE('PRTL')"
4178662
maul:/tmp/File::Cache/apache#
DC> The SIZE( ) method returns the total size of the objects in the cache,
DC> not including the overhead of directories themselves. As the
DC> documentation explains, it isn't a perfect mechanism, but it should be
DC> a lot closer than you experienced.
I understand that, but it is not a problem. Why size of cache is not
reduced ? There are not any warnings, just nothing happens.
>> What is the best way to limit cache ?
>> May be variant when File::Cache::REDUCE_SIZE(10485760) in cron.dayly
>> will be better solution ? I this case max_size doesnt need to specify
>> in object initialization params...
DC> I personally prefer using a cron job to periodically limit the size of
DC> the cache. I don't like using "max_size" because of the overhead
DC> involved on every set. I'd rather just fine tune the number of times
DC> a cron script is executed (i.e., once an hour vs. once a day).
>> Another kind of problem appears recently.
>>
>> In logs
>> [Wed Feb 7 15:42:57 2001] [error] Couldn't rename
>/tmp/File::Cache/.description.tmp13984 to /tmp/File::Cache/.description at
>/usr/web/inc/WebCache.pm line 15
>> [Wed Feb 7 15:44:37 2001] [error] Couldn't rename
>/tmp/File::Cache/apache/PRTL/b/5/a/b5a261aa13cf0ddfd41beb7d64960248.tmp13441 to
>> /tmp/File::Cache/apache/PRTL/b/5/a/b5a261aa13cf0ddfd41beb7d64960248 at
>/usr/web/inc/WebCache.pm line 87
>> ...propagated at /usr/web/inc/Apache/Portal.pm line 109.
>>
>> What I can do ?
DC> Unfortunately the error message doesn't tell me enough. If you can,
DC> please modify lines 1578 and 1579 of Cache.pm to read as follows:
DC>rename ($temp_filename, $filename) or
DC> croak("Couldn't rename $temp_filename to $filename: $!");
DC> The next time it hangs, the error message will have more information.
DC> I'll fix that in the next version of File::Cache.
Done...
Wait for errors now.
Sergey Polyakov aka "BeerBong"
Chief of WebZavod http://www.webzavod.ru
Tel. +7 (8462) 43-93-85 | +7 (8462) 43-93-86
mailto:[EMAIL PROTECTED]
Re: Problem with $r->register_cleanup()
Is it possible that another handler (such as CGI, or parsed-html) is
taking over before yours and exiting or returning OK.
Rob
>Hi,
>
>I just ran into a problem with $r->register_cleanup() only sometime beeing
>called.
>
>This is mod_perl 1.24_01, perl 5.6.0, apache 1.3.14 compiled with gcc 5.6.0 on
>AIX 4.3.3.
>
>Here's a sample code (snippet):
>
>sub handler { # PerlTransHandler
> my $r = shift;
> $r->register_cleanup(\&clean1);
> $r->push_handlers(PerlCleanupHandler => \&clean2);
> $r->pnotes('cleanup', bless {} );
> print STDERR 'in ";
> return DECLINE;
>}
>
>sub clean1 { print STDERR "register_cleanup "; }
>sub clean2 { print STDERR "push_handlers "; }
>sub DESTROY { print STDERR "DESTROY\n"; }
>
>And that's the error_log:
>
>in register_cleanup push_handlers DESTROY
>in register_cleanup push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in register_cleanup push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in push_handlers DESTROY
>in register_cleanup push_handlers DESTROY
>in push_handlers DESTROY
>
>
>The pushed handler only get's called about a third or less of the time. :-(
>
>Any idea, bug?
>
>Michael Jacob
>
>PS: Yes I did some tests with -x...
Robert L. Landrum
Senior Programmer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"It's working correctly. It's simply working in contrast to what you have
perceived to be correct."
Problem with $r->register_cleanup()
Hi,
I just ran into a problem with $r->register_cleanup() only sometime beeing
called.
This is mod_perl 1.24_01, perl 5.6.0, apache 1.3.14 compiled with gcc 5.6.0 on
AIX 4.3.3.
Here's a sample code (snippet):
sub handler { # PerlTransHandler
my $r = shift;
$r->register_cleanup(\&clean1);
$r->push_handlers(PerlCleanupHandler => \&clean2);
$r->pnotes('cleanup', bless {} );
print STDERR 'in ";
return DECLINE;
}
sub clean1 { print STDERR "register_cleanup "; }
sub clean2 { print STDERR "push_handlers "; }
sub DESTROY { print STDERR "DESTROY\n"; }
And that's the error_log:
in register_cleanup push_handlers DESTROY
in register_cleanup push_handlers DESTROY
in push_handlers DESTROY
in push_handlers DESTROY
in push_handlers DESTROY
in register_cleanup push_handlers DESTROY
in push_handlers DESTROY
in push_handlers DESTROY
in push_handlers DESTROY
in push_handlers DESTROY
in push_handlers DESTROY
in push_handlers DESTROY
in push_handlers DESTROY
in push_handlers DESTROY
in register_cleanup push_handlers DESTROY
in push_handlers DESTROY
The pushed handler only get's called about a third or less of the time. :-(
Any idea, bug?
Michael Jacob
PS: Yes I did some tests with -x...
Re: File::Cache problem
On Wed, Feb 07, 2001 at 04:02:39PM +0400, BeerBong wrote:
> Cache size after 24 hours of working
> via 'du -s' - 53M
> via 'perl -MFile::Cacje -e"print File::Cache::SIZE('PRTL')"' - 10M
That looks like a serious bug. Can you double check on that? Where
are you running the "du -s"?
The SIZE( ) method returns the total size of the objects in the cache,
not including the overhead of directories themselves. As the
documentation explains, it isn't a perfect mechanism, but it should be
a lot closer than you experienced.
> What is the best way to limit cache ?
> May be variant when File::Cache::REDUCE_SIZE(10485760) in cron.dayly
> will be better solution ? I this case max_size doesnt need to specify
> in object initialization params...
I personally prefer using a cron job to periodically limit the size of
the cache. I don't like using "max_size" because of the overhead
involved on every set. I'd rather just fine tune the number of times
a cron script is executed (i.e., once an hour vs. once a day).
> Another kind of problem appears recently.
>
> In logs
> [Wed Feb 7 15:42:57 2001] [error] Couldn't rename
>/tmp/File::Cache/.description.tmp13984 to /tmp/File::Cache/.description at
>/usr/web/inc/WebCache.pm line 15
> [Wed Feb 7 15:44:37 2001] [error] Couldn't rename
>/tmp/File::Cache/apache/PRTL/b/5/a/b5a261aa13cf0ddfd41beb7d64960248.tmp13441 to
>/tmp/File::Cache/apache/PRTL/b/5/a/b5a261aa13cf0ddfd41beb7d64960248 at
>/usr/web/inc/WebCache.pm line 87
> ...propagated at /usr/web/inc/Apache/Portal.pm line 109.
>
> What I can do ?
Unfortunately the error message doesn't tell me enough. If you can,
please modify lines 1578 and 1579 of Cache.pm to read as follows:
rename ($temp_filename, $filename) or
croak("Couldn't rename $temp_filename to $filename: $!");
The next time it hangs, the error message will have more information.
I'll fix that in the next version of File::Cache.
> And another question (I'm use Linux Debian Potato)...
> Is there way to define params of the currently performing request
> (URI, script, etc) of hanging mod_perl process ? I browsed /proc/[PID of
> mod_perl]/, but I think this info is about first request. Am I wrong ?
Are you looking in /proc/[pid]/environ for the request parameters?
I'm surprised this information was available even for the first
request. I don't believe environ is updated dynamically (I think it
is filled out once on the exec of the process). It certainly won't
provide the information on subsequent requests. In any case, the
format and behavior of /proc is so dependent on the particular version
of the Linux kernel that I wouldn't want to rely on it for anything
more than occasional debugging.
Two options for you would be to log the request every time via warn.
It will fill your logs very quickly, but hopefully it will hang
quickly and you can get the debugging information out.
Another solution is to compile apache and mod_perl with debugging
symbols and attach to it with "gdb". I have tried this a long time,
though. Please see the current thread about using gdb.
Best of luck!
-DeWitt
Re: File::Cache problem
At 11:56 AM 02/07/01 +0400, BeerBong wrote:
>And when cache size is exceeded all mod_perl processes are hanging.
I had this happen to me a few days back on a test server. I thought I'd
made a mistake by doing a rm -rf /tmp/File::Cache while the server was
running (and while the File::Cache object was persistent).
>And another question (I'm use Linux Debian Potato)...
>Is there way to define params of the currently performing request
You could use a USR2 hander in your code, if that's what you are asking.
This is what my spinning httpd said the other day:
[DIE] USR2 at /data/_g/lii/perl_lib/lib/5.00503/File/Spec/Unix.pm line 57
File::Spec::Unix::catdir('File::Spec', '') called at
/data/_g/lii/perl_lib/lib/5.00503/File/Spec/Functions.pm line 41
File::Spec::Functions::__ANON__('') called at
/data/_g/lii/perl_lib/lib/site_perl/5.005/File/Cache.pm line 862
File::Cache::_GET_PARENT_DIRECTORY('/') called at
/data/_g/lii/perl_lib/lib/site_perl/5.005/File/Cache.pm line 962
But I haven't seen it happen since then.
Bill Moseley
mailto:[EMAIL PROTECTED]
File::Cache problem
Hello modperl,
There is Apache Perl module, which uses File::Cache.
File::Cache object is initialized in every request with params
namespace PRTL
max_size 10485760
expires_in 86400
cache_depth 3
Cache size after 24 hours of working
via 'du -s' - 53M
via 'perl -MFile::Cacje -e"print File::Cache::SIZE('PRTL')"' - 10M
Count of cache nodes is several thousands.
And when cache size is exceeded all mod_perl processes are hanging.
In logs
[Wed Feb 7 08:50:50 2001] [error] Undefined subroutine &File::Cache::thaw called at
/usr/local/lib/site_perl/File/Cache.pm line 601.
What is the best way to limit cache ?
May be variant when File::Cache::REDUCE_SIZE(10485760) in cron.dayly
will be better solution ? I this case max_size doesnt need to specify
in object initialization params...
And another question (I'm use Linux Debian Potato)...
Is there way to define params of the currently performing request
(URI, script, etc) of hanging mod_perl process ? I browsed /proc/[PID of
mod_perl]/, but I think this info is about first request. Am I wrong ?
Sergey Polyakov aka "BeerBong"
Chief of WebZavod http://www.webzavod.ru
Tel. +7 (8462) 43-93-85 | +7 (8462) 43-93-86
mailto:[EMAIL PROTECTED]
Re: Apache::ASP installation problem
"Wang, Pin-Chieh" wrote: > > Hi, > I am using Apache 1.3.14 with mod_perl-1.24_01 on Solaris system > The Apache/Mod_perl part of build is working fine. > But when I installed Apache-ASP-2.07, during the make test part I got > Undefied Routine Devel/Symdump error > therefore the make test failed. > So, I download and try to install Devel-Symdump-2.00, > the make test failed with error code 29 on Command failed for target > 'test-dynamic' > Your other mail said that you got Devel-Symdump-2.01 working. Just closing this thread. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks >> free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Apache::ASP installation problem
Hi, I am using Apache 1.3.14 with mod_perl-1.24_01 on Solaris system The Apache/Mod_perl part of build is working fine. But when I installed Apache-ASP-2.07, during the make test part I got Undefied Routine Devel/Symdump error therefore the make test failed. So, I download and try to install Devel-Symdump-2.00, the make test failed with error code 29 on Command failed for target 'test-dynamic' Any person can provide any assistance will be appreciated. Thanks PC
RE: Translation handler continuous loop problem
This is a repost because my earlier message from this morning bounced. Since
then I feel we have located the source of the problem. It looks like there
is a most bizarre interaction between Netscape clients and the proxy server.
Netscape was configured with manual proxy settings identifying the web
server with Apache/mod_perl. Once this was done, Netscape is able to
successfully connect to Apache/mod_perl with no more continuous loops!! I
don't know the whys or hows.
The following text is a copy of what I posted this morning.
Thanks for the example. I inserted the statement "return DECLINED unless
$r->is_initial_req;" but the handler still enters a continuous loop. I
also stripped out my code and tried the example from Doug's module book with
debug statements but still a continuous loop. The problem is bizarre. It
only enters the loop for a URL like http://lions/sp9/whatever Any other URL
such as http://lions/here/there works fine. I wrote the original handler to
extract a session id from a URL with sp9 in the path but now there is no
reference. I have checked my httpd.conf for anything out of ordinary as
well. As can be seen, the translation handler below is very very basic but
it still enters a continuous loop for that specific URL. If I place a fully
qualified donamin name like http://lions.access.com/sp9/whatever, there is
no loop!!
Any ideas?
package Apache::URIsid;
use strict;
use Apache::Constants qw(:common);
use CGI::Carp;
sub handler {
my $r = shift;
return DECLINED unless $r->is_initial_req;
my($junk,$session,@rest) = split '/', $r->uri;
# warn "junk: $junk";
# warn "session: $session";
# foreach (@rest) {
#warn "rest: $_";
# }
my $uri = $r->uri;
warn "URI in: $uri";
return DECLINED;
# my $uri_in = $r->uri;
# warn "sp9 URL detected $uri_in";
# $r->subprocess_env('SESSION_ID' => $session);
# my $translated_uri = join "/", "",@rest;
# $r->uri($translated_uri);
# return DECLINED;
}
1;
__END__
-Original Message-
From: Greg Cope [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 31, 2001 5:47 PM
To: Sinclair, Alan (CORP, GEAccess)
Cc: '[EMAIL PROTECTED]'
Subject: Re: Translation handler continuous loop problem
"Sinclair, Alan (CORP, GEAccess)" wrote:
>
> I am hoping someone might have a clue on how to resolve this awkward
> problem.
>
> I have just installed a mod_perl URI translation handler to extract a
> session id from the URI. In general the translation works correctly by
> removing the session id from the URL when detected. However, a Netscape
> browser client triggers Apache to enter a continuous loop if I do not
> specify the domain name in the hostname component of the URL. The problem
> does not occur in Internet Explorer (that surprised me.)
>
> All these examples are from Nestcape on both NT and Unix.
> For example, say I enter http://lions.access.com/sp9/outage.html The
> translation handler works correctly.
> If I then enter: http://lions/sp9/outage.html There is a continuous loop
in
> Apache and on each iteration, an entry is written to access_log. I have to
> stop the request in Netscape.
>
> The bizarre thing is I can enter any other URL such as
> http://lions/internal/whatever and there is no problem. The mod_perl
> translation header goal is stripping session id info from the URL in the
> form http://hostname/SESSION_ID/sp9/whatever It looks for sp9 in the path.
I
> have attempted to debug by trying to send error messages to the error log
> without success.
>
> Does anyone have any suggestions on how I can determine why the
translation
> handler is entering into a continuous loop when a request is sent from
> Netscape?
>
> I would be appreciative of any help!!
I could be completely wrong but ...
I can't see a problem here - although I would need to see the code.
There could be an issue with how IE and Netscape actually format the
header (i.e you may enter the above, but the header that gets sent may
be different) - but I could be completely wrong on this !
You may wish to look at http://sourceforge.net/projects/sessionmanager/
Which is URI transhandler / session manager that I wrote for a project
that never came about. I may make another release that uses PerlSetVars
to configure the module if I get a chance to test it.
If this does not help, then post either the code, or a URL to the code
if its long, so that some of us can have a look.
Greg
>
> Env is: Solaris 2.6 Apache 1.3.14 mod_perl 1.24_01
Translation handler continuous loop problem
I am hoping someone might have a clue on how to resolve this awkward problem. I have just installed a mod_perl URI translation handler to extract a session id from the URI. In general the translation works correctly by removing the session id from the URL when detected. However, a Netscape browser client triggers Apache to enter a continuous loop if I do not specify the domain name in the hostname component of the URL. The problem does not occur in Internet Explorer (that surprised me.) All these examples are from Nestcape on both NT and Unix. For example, say I enter http://lions.access.com/sp9/outage.html The translation handler works correctly. If I then enter: http://lions/sp9/outage.html There is a continuous loop in Apache and on each iteration, an entry is written to access_log. I have to stop the request in Netscape. The bizarre thing is I can enter any other URL such as http://lions/internal/whatever and there is no problem. The mod_perl translation header goal is stripping session id info from the URL in the form http://hostname/SESSION_ID/sp9/whatever It looks for sp9 in the path. I have attempted to debug by trying to send error messages to the error log without success. Does anyone have any suggestions on how I can determine why the translation handler is entering into a continuous loop when a request is sent from Netscape? I would be appreciative of any help!! Env is: Solaris 2.6 Apache 1.3.14 mod_perl 1.24_01
Re: Translation handler continuous loop problem
"Sinclair, Alan (CORP, GEAccess)" wrote: > > I am hoping someone might have a clue on how to resolve this awkward > problem. > > I have just installed a mod_perl URI translation handler to extract a > session id from the URI. In general the translation works correctly by > removing the session id from the URL when detected. However, a Netscape > browser client triggers Apache to enter a continuous loop if I do not > specify the domain name in the hostname component of the URL. The problem > does not occur in Internet Explorer (that surprised me.) > > All these examples are from Nestcape on both NT and Unix. > For example, say I enter http://lions.access.com/sp9/outage.html The > translation handler works correctly. > If I then enter: http://lions/sp9/outage.html There is a continuous loop in > Apache and on each iteration, an entry is written to access_log. I have to > stop the request in Netscape. > > The bizarre thing is I can enter any other URL such as > http://lions/internal/whatever and there is no problem. The mod_perl > translation header goal is stripping session id info from the URL in the > form http://hostname/SESSION_ID/sp9/whatever It looks for sp9 in the path. I > have attempted to debug by trying to send error messages to the error log > without success. > > Does anyone have any suggestions on how I can determine why the translation > handler is entering into a continuous loop when a request is sent from > Netscape? > > I would be appreciative of any help!! I could be completely wrong but ... I can't see a problem here - although I would need to see the code. There could be an issue with how IE and Netscape actually format the header (i.e you may enter the above, but the header that gets sent may be different) - but I could be completely wrong on this ! You may wish to look at http://sourceforge.net/projects/sessionmanager/ Which is URI transhandler / session manager that I wrote for a project that never came about. I may make another release that uses PerlSetVars to configure the module if I get a chance to test it. If this does not help, then post either the code, or a URL to the code if its long, so that some of us can have a look. Greg > > Env is: Solaris 2.6 Apache 1.3.14 mod_perl 1.24_01
Re: Translation handler continuous loop problem
you will probably need to post the handler if you want any help with it. "Sinclair, Alan (CORP, GEAccess)" wrote: > > I have just installed a mod_perl URI translation handler to extract a > session id from the URI. In general the translation works correctly by > removing the session id from the URL when detected. However, a Netscape > browser client triggers Apache to enter a continuous loop if I do not > specify the domain name in the hostname component of the URL. The problem > does not occur in Internet Explorer (that surprised me.) > > All these examples are from Nestcape on both NT and Unix. > For example, say I enter http://lions.access.com/sp9/outage.html The > translation handler works correctly. > If I then enter: http://lions/sp9/outage.html There is a continuous loop in > Apache and on each iteration, an entry is written to access_log. I have to > stop the request in Netscape. > -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
Re: make problem - mod_perl.h not found by Apache::modules
On Sat, 27 Jan 2001, Lynn Winebarger wrote: > >Hi. I'm having problems getting mod_perl (1.24<_01>) to compile. > I'm using perl 5.6.0, apache 1.3.14, RH Linux 6.2/Intel (with upgrades). > This is odd since I've previously built mod_perl successfully as a DSO > (and the problem appears to be in the configure - I don't get far enough > in the make to be worried about run-time incompatibilies with 1.3.14). > Of course, I don't have the options used in the previous mod_perl build. > WITH_APXS=/usr/local/apache/bin/apxs > USE_APXS=1 > DYNAMIC=1 skip the DYNAMIC=1 option, i don't think it works in combonation with USE_APXS=1
Re: make problem - mod_perl.h not found by Apache::modules (more)
Hi again, On Sat, 27 Jan 2001, Lynn Winebarger wrote: > since tried it with the 5.005 and 1.3.12 installs, using a configuration > that was successful less than a month ago, and no go. Last time something like this happened I spent quite a long time figuring out that the customer had screwed his directory structure by adding symlinks and moving/editing files to solve a problem that wasn't there. In that case I got it to build by putting the files back like they ought to be and modifying the makefile but it just shouldn't be that much trouble. I'm pretty sure you have (or someone else has:) done something similar. It doesn't take much to mess up. I'd wipe the lot (including Perl) and start again with perl5.005_03 only. 73, Ged.
Re: make problem - mod_perl.h not found by Apache::modules (more)
A little more on my configuration - I've got both a /usr/ install of perl (5.005) and 5.6.0 installed in /usr/local/perl (for chrooting purposes). I also have /usr/local install of apache 1.3.12 and a /usr/local/apache install of 1.3.14 (again, for chrooting). The attempt below was trying to use the perl 5.6.0 and apache 1.3.14 installs. I have since tried it with the 5.005 and 1.3.12 installs, using a configuration that was successful less than a month ago, and no go. The configuration was perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/local/sbin/apache EVERYTHING=1 It gets the same error (Apache/Apache.c can't include mod_perl.h or mod_perl_xs.h). Those header files are in fact in blib/arch/auto/Apache/perl/ (at the point it attempts to compile Apache/Apache.c). The generated Apache.c's include statements are: #include "mod_perl.h" #include "mod_per_xs.h" and those headers aren't in Apache/ Now, the odd thing is that the last time I built it, make output this: make[1]: Entering directory `/home/lynn/http/mod_perl-1.24/Apache' mkdir ../blib/lib/auto/Apache cp Apache.pm ../blib/lib/Apache.pm (after building the files from apaci/). In other words, in that instance, it didn't try to build Apache/Apache.c. Of course, it built Apache.c statically into libperl.so, so why would it? But as I said, this option doesn't appear to work now (even in the attempts where I turned off DYNAMIC, or where I set EVERYTHING=1 (on the command line, without a .makepl_args.mod_perl, as above). My first guess would be there's something screwy in my perl configuration, but I don't think I've updated the 5.005 one since the last successful build. If anyone can offer me a clue, I'd greatly appreciate it. (Although I'm pretty set on building it as a DSO - even if I install it in the apache source tree statically, this is a puzzler). Thanks, Lynn PS The snippit from the successful build came from a log file of the shell session the last time I built Apache and all the components I use. I was surprised to find it - I usually don't have that kind of foresight ;-) On Sat, 27 Jan 2001, Lynn Winebarger wrote: > >Hi. I'm having problems getting mod_perl (1.24<_01>) to compile. > I'm using perl 5.6.0, apache 1.3.14, RH Linux 6.2/Intel (with upgrades). > This is odd since I've previously built mod_perl successfully as a DSO > (and the problem appears to be in the configure - I don't get far enough > in the make to be worried about run-time incompatibilies with 1.3.14). > Of course, I don't have the options used in the previous mod_perl build. [snip]
make problem - mod_perl.h not found by Apache::modules
Hi. I'm having problems getting mod_perl (1.24<_01>) to compile. I'm using perl 5.6.0, apache 1.3.14, RH Linux 6.2/Intel (with upgrades). This is odd since I've previously built mod_perl successfully as a DSO (and the problem appears to be in the configure - I don't get far enough in the make to be worried about run-time incompatibilies with 1.3.14). Of course, I don't have the options used in the previous mod_perl build. My .makepl_args.mod_perl reads APACHE_PREFIX=/usr/local/apache WITH_APXS=/usr/local/apache/bin/apxs USE_APXS=1 #USE_DSO=1 #turns on all standard Apache:: modules, compiles them as #dynamic libraries DYNAMIC=1 # turn on all those Perl*Handler directives ALL_HOOKS=1 #misc features # in config files PERL_SECTIONS=1 # Don't allow #perl in SSI PERL_SSI=0 PERL_DIRECTIVE_HANDLERS=1 PERL_STACKED_HANDLERS=1 PERL_METHOD_HANDLERS=1 Making yields (lines mangled by pasting into pine): (cd ./apaci && make) make[1]: Entering directory `/home/lynn/http/mod_perl-1.24_01/apaci' cc -fpic -O2 -I/usr/local/perl/lib/5.6.0/i686-linux/CORE -fno-strict-aliasing -I/usr/local/include -DMOD_PERL_VERSION=\"1.24_01\" -DMOD_PERL_STRING_VERSION=\"mod_perl/1.24_01\" -DNO_PERL_SSI=1 -I/usr/local/apache/include -DMOD_PERL -DLINUX=2 -DMOD_SSL=207101 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I../lib/expat-lite -c mod_perl.c && mv mod_perl.o mod_perl.lo /usr/local/perl/bin/perl -MExtUtils::Embed -e xsinit -- -o perlxsi.c -std cc -fpic -O2 -I/usr/local/perl/lib/5.6.0/i686-linux/CORE -fno-strict-aliasing -I/usr/local/include -DMOD_PERL_VERSION=\"1.24_01\" -DMOD_PERL_STRING_VERSION=\"mod_perl/1.24_01\" -DNO_PERL_SSI=1 -I/usr/local/apache/include -DMOD_PERL -DLINUX=2 -DMOD_SSL=207101 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I../lib/expat-lite -c perlxsi.c && mv perlxsi.o perlxsi.lo cc -fpic -O2 -I/usr/local/perl/lib/5.6.0/i686-linux/CORE -fno-strict-aliasing -I/usr/local/include -DMOD_PERL_VERSION=\"1.24_01\" -DMOD_PERL_STRING_VERSION=\"mod_perl/1.24_01\" -DNO_PERL_SSI=1 -I/usr/local/apache/include -DMOD_PERL -DLINUX=2 -DMOD_SSL=207101 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I../lib/expat-lite -c perl_config.c && mv perl_config.o perl_config.lo cc -fpic -O2 -I/usr/local/perl/lib/5.6.0/i686-linux/CORE -fno-strict-aliasing -I/usr/local/include -DMOD_PERL_VERSION=\"1.24_01\" -DMOD_PERL_STRING_VERSION=\"mod_perl/1.24_01\" -DNO_PERL_SSI=1 -I/usr/local/apache/include -DMOD_PERL -DLINUX=2 -DMOD_SSL=207101 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I../lib/expat-lite -c perl_util.c && mv perl_util.o perl_util.lo cc -fpic -O2 -I/usr/local/perl/lib/5.6.0/i686-linux/CORE -fno-strict-aliasing -I/usr/local/include -DMOD_PERL_VERSION=\"1.24_01\" -DMOD_PERL_STRING_VERSION=\"mod_perl/1.24_01\" -DNO_PERL_SSI=1 -I/usr/local/apache/include -DMOD_PERL -DLINUX=2 -DMOD_SSL=207101 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I../lib/expat-lite -c perlio.c && mv perlio.o perlio.lo cc -fpic -O2 -I/usr/local/perl/lib/5.6.0/i686-linux/CORE -fno-strict-aliasing -I/usr/local/include -DMOD_PERL_VERSION=\"1.24_01\" -DMOD_PERL_STRING_VERSION=\"mod_perl/1.24_01\" -DNO_PERL_SSI=1 -I/usr/local/apache/include -DMOD_PERL -DLINUX=2 -DMOD_SSL=207101 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I../lib/expat-lite -c mod_perl_opmask.c && mv mod_perl_opmask.o mod_perl_opmask.lo rm -f libperl.so cc -shared -L/usr/local/apache/lib -L/usr/local/openssl/lib -L/usr/local/perl/lib -L/usr/local/lib -o libperl.so mod_perl.lo perlxsi.lo perl_config.lo perl_util.lo perlio.lo mod_perl_opmask.lo -rdynamic -L/usr/local/apache/lib -L/usr/local/openssl/lib -L/usr/local/perl/lib -L/usr/local/lib /usr/local/perl/lib/5.6.0/i686-linux/auto/DynaLoader/DynaLoader.a -L/usr/local/perl/lib/5.6.0/i686-linux/CORE -lperl -lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt make[1]: Leaving directory `/home/lynn/http/mod_perl-1.24_01/apaci' mkdir blib mkdir blib/lib mkdir blib/arch mkdir blib/arch/auto mkdir blib/arch/auto/mod_perl mkdir blib/lib/auto mkdir blib/lib/auto/mod_perl mkdir blib/man3 cp lib/Apache/Registry.pm blib/lib/Apache/Registry.pm cp lib/Apache/SizeLimit.pm blib/lib/Apache/SizeLimit.pm cp lib/Apache/Resource.pm blib/lib/Apache/Resource.pm cp lib/Apache/PerlSections.pm blib/lib/Apache/PerlSections.pm cp lib/Apache/RegistryNG.pm blib/lib/Apache/RegistryNG.pm cp lib/Apache/PerlRun.pm blib/lib/Apache/PerlRun.pm cp lib/Apache/Debug.pm blib/lib/Apache/Debug.pm cp lib/mod_perl_hooks.pm.PL blib/lib/mod_perl_hooks.pm.PL cp lib/Apache/MyConfig.pm blib/lib/Apache/MyConfig.pm cp src/modules/perl/mod_perl_xs.h blib/arch/auto/Apache/include/modules/perl/mod_perl_xs.h cp mod_perl_tuning.pod blib/lib/mod_perl_tuning.pod cp src/modules/perl/mod_perl_version.h blib/arch/auto/Apache/include/modules/perl/mod_perl_version.h cp lib/Apache/ExtUtils.pm blib/lib/Apache/ExtUtils.pm cp lib/Apache/httpd_conf.pm bl
Re: problem to configure perl with apache
I would suggest that you visit www.apachetoolbox.com and get the toolbox. Use that to install. Since it uses sources that are known to work with each other, it should be relatively painless. It should come off without a hitch. Also, next time you post, you might want to mention what your platform is (Linux, Unix, NT, etc.). You also need to be accurate about what versions you have installed. I'm pretty sure you "fat fingered" the Apache version. Perl hasn't been version 1 since...well, let's just say that version 1 is older than I am :) and leave it at that. I'd also suggest that if you are having problems with the httpd.conf you get a copy of O'Reilly's Apache The Definitive Guide. You can get it for cheap at www.bookpool.com. The whole book is pretty much devoted to the httpd.conf and goes into it in far more detail than you can get from a mailing list. HTH, "initiative.fr : COUTEL Jean-Francois" wrote: > Hello It is my first install of perl and i have problem I have install > APACHE 10.3.14 with APXS, PHP 4.0.3 pl1 with APXS, mysql and > mod_perl-1.24_01 with apxs apache, php and mysql are okperl is install > but i can't use it can you help me about- configuration of httpd.conf > for perl- other configuration file?- file exemple to > test Thanks Jean-Francois [EMAIL PROTECTED] -- Jimi Thompson Web Master Link.com "It's the same thing we do every night, Pinky."
Re: problem to configure perl with apache
Hi there, On Fri, 26 Jan 2001, initiative.fr : COUTEL Jean-Francois wrote: > It is my first install of perl and i have problem > > I have install APACHE 10.3.14 with APXS, PHP 4.0.3 pl1 with APXS, mysql and >mod_perl-1.24_01 with apxs > > apache, php and mysql are ok > perl is install but i can't use it There isn't enough information here to figure out what kind of a problem you have. Please read the file called SUPPORT in the mod_perl directory, (and please make sure your information is accurate next time you post:). 73, Ged.
problem to configure perl with apache
Hello It is my first install of perl and i have problem I have install APACHE 10.3.14 with APXS, PHP 4.0.3 pl1 with APXS, mysql and mod_perl-1.24_01 with apxs apache, php and mysql are ok perl is install but i can't use it can you help me about - configuration of httpd.conf for perl - other configuration file? - file exemple to test Thanks Jean-Francois COUTEL [EMAIL PROTECTED]
Re: STDIN, STDOUT, Socket::PassAccessRights problem
On Tue, 9 Jan 2001, Paul Buder wrote:
> I am using a CPAN module called Socket::PassAccessRights
> that uses the recvmsg and sendmsg system calls to pass
> file descriptors over a socket. More specifically, I have a
> long living program (not modperl) that needs to communicate
> with the Apache descriptors for STDIN and STDOUT given to a CGI
> or modperl script.
>
> The following works as an ordinary CGI but not under modperl.
> use IO::Socket;
> use Socket::PassAccessRights;
>
> $client=IO::Socket::UNIX->new(Type => SOCK_STREAM,
> Peer => '/tmp/socket') or die $!;
>
> Socket::PassAccessRights::sendfd(fileno($client), fileno(STDIN)) or die;
> Socket::PassAccessRights::sendfd(fileno($client), fileno(STDOUT)) or die;
>
> # The only info my server needs from Apache other than
> # the descriptors, this is POST'ed data.
> print $client $ENV{CONTENT_LENGTH}, "\n";
> # end of script
>
> This doesn't work under modperl. I suspect that is because
> STDIN and STDOUT are not normal in some sense under modperl
> but I don't know enough to get any handle on it.
right, apache i/o is not stdio. this might help, please let us know if it
does or not. you might also need to $r->rflush before your socket thingy
writes to the fd.
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.119
diff -u -r1.119 Apache.xs
--- src/modules/perl/Apache.xs 2000/12/29 17:10:08 1.119
+++ src/modules/perl/Apache.xs 2001/01/26 06:19:30
@@ -603,7 +603,7 @@
Apache r
CODE:
-RETVAL = fileno(stdout);
+RETVAL = r->connection->client->fd;
OUTPUT:
RETVAL
PROBLEM FIXED: Redirecting a multipart/form-data POST request
I am writing to report that both suggestions that were sent in response to my problem (redirecting multipart/form-data POST requests) worked just fine. On 2001-01-16, Gerd Kortemeyer <[EMAIL PROTECTED]> wrote: > Please find the code section below that I use to get the > POSTed data. After that, in order to REDIRECT, I use Gerd, with minor modifications to construct a query string for $r->content() in order to allow me to continue to use param(), your suggestion worked just fine under Apache/1.3.12 mod_perl/1.22. On 2001-01-24, Doug MacEachern <[EMAIL PROTECTED]> wrote: > you need 1.24_01 which contains this fix: fix $r->read() so it > will not block if all data has already been read and so that > Apache will not hang during ap_discard_request_body() on error > or redirect after all data has been read Doug, I am now running Apache/1.3.14 with mod_perl/1.24_01 on a trial basis and things seem to be working fine for now without the use of Mr. Kortemeyer's code, which served well as a short-term workaround. :) Thanks to both of you, Darren -- Can the pissing-people-off business model continue to work? Darren Stuart Embry. http://www.webonastick.com/
Re: Problem with Apache::LogFile
i think you need to compile with perl Makefile.PL PERL_DIRECTIVE_HANDLERS=1 or EVERYTHING=1 On Tue, 23 Jan 2001, Liddick, Scott wrote: > I am currently writing a PerlLogHandler that will (hopefully) write request > info to a rolling logfile in a pipe delimeted format for hourly loading via > Oracle SQL*Load into a database (I know about Apache::LogDBI, but my DBA > group will not let me do this). I wish to use Apache::LogFile to utilize > the Apache logging mechanisms to allow all httpd children to write to a > common file w/o having to worry about flocking or other methods to allow > write access by many processes. The environment is Apache 1.3.12/mod_perl > 1.21. Apache::LogFile seems to compile ok, but when I try to initialize the > log handle in a startup.pl script, I get this error: > > Can't load > '/opt/merc/perl/5.005_03/lib/site_perl/5.005/i686-linux/auto/Apache/LogFile/ > Config/Config.so' for module Apache::LogFile::Config: > /opt/merc/perl/5.005_03/lib/site_perl/5.005/i686-Linux/auto/Apache/LogFile/C > onfig/Config.so: undefined symbol: perl_cmd_perl_TAKE2 at > /opt/merc/perl/5.005_03/lib/5.00503/i686-linux/DynaLoader.pm line 169. > > I read about the args_how directive parsing stuff, and found this symbol in > mod_perl.h and a few other places but really don't know what I am doing. > Can anyone point me in the right direction for getting this module properly > installed? Is there a special way that I need to build Apache/mod_perl? > Help. > > Thanks, > Scott >
Problem: Variables randomly un-set
I'm running a CGI program under mod_perl, and am getting erratic
behavior. Every 3 or 4 hits, a variable will be undefined. Fortunately,
the program does enough sanity checks to barf when some vital data is
missing... One variable that seems particularly prone to disappear is the
$table variable (see below).
The CGI program has multiple "pages" of potential output depending on the
action requested, and variables are passed around these pages using hidden
input tags. Pretty standard stuff. Here's some sample code:
# UltraForm2 is a module/API I've made. Not a CPAN module...
use UltraForm2;
$uf = new UltraForm2;
$profile = $uf->getformdata('UF','profile') || &print_loginpage;
$uf->readprofile($profile)
|| $uf->error("Cannot read the specified profile: $profile");
$table = $uf->getprofilekeyword('db_table');
($table)
|| $uf->error("No db_table was specified in the profile \'$profile\'");
Not pictured here: All of these variables are my()'d at the top of the
program, "use strict" is used, and the programs checks out just fine with
"perl -cw"
Like I said, it works just fine, then after 3 or 4 hits, the $table
variable is suddenly null/undef. This does not occur when the program is
run via standard CGI.
I read the cgi_to_modperl document, and none of the mentioned pitfalls
about loading packages seemed to apply here... Where do I start looking to
find the problem?
-gm
Re: Problem with Apache::ASP
isaac wrote:
>
> Has anyone noticed that they get errors when trying to use else or elsif statements
>with Apache::ASP.
>
> If I form my statements like this:
>
> <% if($foo eq bar){ %>
> bar
> <% } %>
> <% elsif($foo eq bar2){ %>
> bar2
> <% } %>
>
> I get syntax errors.
> ...
> Then I get no syntax errors. Is there a way around this? Any help would be much
>appreciated.
> ...
Realize that html between %> ... <% , the ... get's printed
even if its white space.
Try writing it like this:
<% if($foo eq bar){ %>
bar
<% } elsif($foo eq bar2){ %>
bar2
<% } %>
-- Josh
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks >> free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
Re: Problem with Apache::ASP
Hi there,
On Tue, 23 Jan 2001, isaac wrote:
> Has anyone noticed that they get errors when trying to use else or elsif
> statements with Apache::ASP.
Nope.
> If I form my statements like this:
>
> <% if($foo eq bar¹){ %>
> bar
> <% } %>
> <% elsif($foo eq bar2¹){ %>
> bar2
> <% } %>
Hmmm. What's this \214 and \271 stuff?
Don't use extended character sets in your code.
> syntax error at (eval 28498) line 39, near "; elsif" (Might be a runaway
> multi-line '' string starting on line 38) ,
I think it's trying to tell you...
73,
Ged.
Problem with Apache::ASP
Title: Problem with Apache::ASP
Has anyone noticed that they get errors when trying to use else or elsif statements with Apache::ASP.
If I form my statements like this:
<% if($foo eq ‘bar’){ %>
bar
<% } %>
<% elsif($foo eq ‘bar2’){ %>
bar2
<% } %>
I get syntax errors.
syntax error at (eval 28498) line 39, near "; elsif" (Might be a runaway multi-line '' string starting on line 38) , /usr/local/www/users/jpmktg/html/Global/Lib/5.005/Apache/ASP.pm line 1840
If I form my statements like this:
<% if($foo eq ‘bar’){
print(’Hello’);
}
elsif($foo eq ‘bar2’){
print(’bar2’);
}
%>
Then I get no syntax errors. Is there a way around this? Any help would be much appreciated.
--
Problem with Apache::LogFile
I am currently writing a PerlLogHandler that will (hopefully) write request info to a rolling logfile in a pipe delimeted format for hourly loading via Oracle SQL*Load into a database (I know about Apache::LogDBI, but my DBA group will not let me do this). I wish to use Apache::LogFile to utilize the Apache logging mechanisms to allow all httpd children to write to a common file w/o having to worry about flocking or other methods to allow write access by many processes. The environment is Apache 1.3.12/mod_perl 1.21. Apache::LogFile seems to compile ok, but when I try to initialize the log handle in a startup.pl script, I get this error: Can't load '/opt/merc/perl/5.005_03/lib/site_perl/5.005/i686-linux/auto/Apache/LogFile/ Config/Config.so' for module Apache::LogFile::Config: /opt/merc/perl/5.005_03/lib/site_perl/5.005/i686-Linux/auto/Apache/LogFile/C onfig/Config.so: undefined symbol: perl_cmd_perl_TAKE2 at /opt/merc/perl/5.005_03/lib/5.00503/i686-linux/DynaLoader.pm line 169. I read about the args_how directive parsing stuff, and found this symbol in mod_perl.h and a few other places but really don't know what I am doing. Can anyone point me in the right direction for getting this module properly installed? Is there a special way that I need to build Apache/mod_perl? Help. Thanks, Scott
Re: Problem when i install mod_perl
On Mon, 22 Jan 2001, initiative.fr : COUTEL Jean-Francois wrote: > Hello, > > I Want to install Apache 1.3.14 / gd 1.8.3 / php4 / mod_perl 1.24 / perl 5.6 > > It is the first time i tried to install apache with php and perl and i have a >problem when i install mod_perl > > Can you give me the solution for this problem Ignore them - they are just warnings. But you should probably check out ApacheToolbox if you're not used to installing Apache modules. -- /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: Problem when i install mod_perl
It is okey you simply do not have LWP(Library for world wide web for perl) you will not need it for successful installation you just will not be able to run make test to check if your installation is correct You can install LWP if you want it is free at cpan On Mon, 22 Jan 2001 19:19:57 +0100 "initiative.fr : COUTEL Jean-Francois" <[EMAIL PROTECTED]> wrote: > Hello, > > I Want to install Apache 1.3.14 / gd 1.8.3 / php4 / mod_perl 1.24 / perl 5.6 > > It is the first time i tried to install apache with php and perl and i have a >problem when i install mod_perl > > Can you give me the solution for this problem > > Thanks a lot > > > > > > > Creating Makefile in src/modules/standard > Creating Makefile in src/modules/perl > Checking CGI.pm VERSION..ok > Checking for LWP::UserAgent..failed > Can't locate LWP/UserAgent.pm in @INC (@INC contains: ./lib >/usr/local/apacheperlphp/perl56/lib/5.6.0/i686-linux >/usr/local/apacheperlphp/perl56/lib/5.6.0 >/usr/local/apacheperlphp/perl56/lib/site_perl/5.6.0/i686-linux >/usr/local/apacheperlphp/perl56/lib/site_perl/5.6.0 >/usr/local/apacheperlphp/perl56/lib/site_perl .) at Makefile.PL line 1072. > > 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 (@INC contains: ./lib >/usr/local/apacheperlphp/perl56/lib/5.6.0/i686-linux >/usr/local/apacheperlphp/perl56/lib/5.6.0 >/usr/local/apacheperlphp/perl56/lib/site_perl/5.6.0/i686-linux >/usr/local/apacheperlphp/perl56/lib/site_perl/5.6.0 >/usr/local/apacheperlphp/perl56/lib/site_perl .) at Makefile.PL line 1090. > > The HTML-Parser package is needed (by libwww-perl) to run the test suite. > Writing Makefile for Apache > Writing Makefile for Apache::Connection > Writing Makefile for Apache::Constants > > > > > Best regards.. > Jean-Francois COUTEL > [EMAIL PROTECTED] > Sincerely, Al Abdullaev. ** Al Abdullaev University of Virginia Department of Computer Science http://www.people.virginia.edu/~eva2e/
Problem when i install mod_perl
Hello, I Want to install Apache 1.3.14 / gd 1.8.3 / php4 / mod_perl 1.24 / perl 5.6 It is the first time i tried to install apache with php and perl and i have a problem when i install mod_perl Can you give me the solution for this problem Thanks a lot Creating Makefile in src/modules/standardCreating Makefile in src/modules/perlChecking CGI.pm VERSION..okChecking for LWP::UserAgent..failedCan't locate LWP/UserAgent.pm in @INC (@INC contains: ./lib /usr/local/apacheperlphp/perl56/lib/5.6.0/i686-linux /usr/local/apacheperlphp/perl56/lib/5.6.0 /usr/local/apacheperlphp/perl56/lib/site_perl/5.6.0/i686-linux /usr/local/apacheperlphp/perl56/lib/site_perl/5.6.0 /usr/local/apacheperlphp/perl56/lib/site_perl .) at Makefile.PL line 1072. The libwww-perl library is needed to run the test suite.Installation of this library is recommended, but not required. Checking for HTML::HeadParserfailedCan't locate HTML/HeadParser.pm in @INC (@INC contains: ./lib /usr/local/apacheperlphp/perl56/lib/5.6.0/i686-linux /usr/local/apacheperlphp/perl56/lib/5.6.0 /usr/local/apacheperlphp/perl56/lib/site_perl/5.6.0/i686-linux /usr/local/apacheperlphp/perl56/lib/site_perl/5.6.0 /usr/local/apacheperlphp/perl56/lib/site_perl .) at Makefile.PL line 1090. The HTML-Parser package is needed (by libwww-perl) to run the test suite.Writing Makefile for ApacheWriting Makefile for Apache::ConnectionWriting Makefile for Apache::Constants Best regards.. Jean-Francois COUTEL [EMAIL PROTECTED]
Re: problem with Perl5.6?
Obviously!!! Thanks. Rmk: since I had made a copy/paste from a mod_perl 1.21 config, it means PerlSetupEnv directive didn't work before... Matt Sergeant a écrit : > On Mon, 22 Jan 2001, Emmanuel Levasseur wrote: > > > Hi, > > > > I have installed Apache.1.3.14/mod_perl.1.24_01/Perl5.6 on Solaris 2.8. > > Everything seems to work fine (no error in error_logs) but when I try to > > use the classical > > printenv tool thru URL: http://myserver.com/perl/tools/printenv > > > > I only get 4 variables: > > GATEWAY_INTERFACE="CGI-Perl/1.1" > > MOD_PERL="mod_perl/1.24_01" > > PATH=... > > TZ="CET" > > > > Of course, if I replace /perl with /cgi-bin, evrything is ok. > > > > This is a sample of my httpd.conf file: > > > > ... > > Alias /perl/ ".../cgi-bin/" > > ... > > # > > # Perl handlers > > # > > PerlRequire conf/startup.pl > > PerlFreshRestart On > > PerlSetupEnv Off > ^ > > You just asked it *not* to setup the environment variables. Hence you > don't get them. > > -- > > > /||** Director and CTO ** >//||** AxKit.com Ltd ** ** XML Application Serving ** > // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** > // \\| // ** Personal Web Site: http://sergeant.org/ ** > \\// > //\\ > // \\
Re: problem with Perl5.6?
On Mon, 22 Jan 2001, Emmanuel Levasseur wrote: > Hi, > > I have installed Apache.1.3.14/mod_perl.1.24_01/Perl5.6 on Solaris 2.8. > Everything seems to work fine (no error in error_logs) but when I try to > use the classical > printenv tool thru URL: http://myserver.com/perl/tools/printenv > > I only get 4 variables: > GATEWAY_INTERFACE="CGI-Perl/1.1" > MOD_PERL="mod_perl/1.24_01" > PATH=... > TZ="CET" > > Of course, if I replace /perl with /cgi-bin, evrything is ok. > > This is a sample of my httpd.conf file: > > ... > Alias /perl/ ".../cgi-bin/" > ... > # > # Perl handlers > # > PerlRequire conf/startup.pl > PerlFreshRestart On > PerlSetupEnv Off ^ You just asked it *not* to setup the environment variables. Hence you don't get them. -- /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
problem with Perl5.6?
Hi, I have installed Apache.1.3.14/mod_perl.1.24_01/Perl5.6 on Solaris 2.8. Everything seems to work fine (no error in error_logs) but when I try to use the classical printenv tool thru URL: http://myserver.com/perl/tools/printenv I only get 4 variables: GATEWAY_INTERFACE="CGI-Perl/1.1" MOD_PERL="mod_perl/1.24_01" PATH=... TZ="CET" Of course, if I replace /perl with /cgi-bin, evrything is ok. This is a sample of my httpd.conf file: ... Alias /perl/ ".../cgi-bin/" ... # # Perl handlers # PerlRequire conf/startup.pl PerlFreshRestart On PerlSetupEnv Off SetHandler perl-script PerlHandler Apache::Registry PerlInitHandler Apache::StatINC Options +ExecCGI PerlSendHeader On PerlSendHeader Off Is there incompatibility beetween mod_perl1.24_01 & perl5.6 or apache1.3.14? Should I go back to Perl5.005 version since I have never had troubles with it? Thanks
IPC::SharedCache - problem
Hi,
I'm having a problem with IPC::SharedCache module:
when executing a code like this:
tie(%cache, 'IPC::SharedCache',load_callback => sub {return undef},
validate_callback => sub {return 1},ipc_key => 'hash');
for ($i=1;$i<=1000;$i++) {
$cache{"key_$i"}=[$i];
}
it allocates a separate memory segment and a separate
semaphore for each cache record, thus exceeding system limit
on the number of semaphores and shared memory segments.
Is there any way to change that behaviour, in other
words, to allocate an entire hash in only one shared memory
segment?
Alexander
'PerlModule Apache' creates a error when include in httpd.conf-trying to fix 'Apache.pm failed to load' problem
Problem: I configure apache and mod_perl. One day it runs fine. The next day I stop and start the server and get a 'Apache.pm failed' problem. I looked at the web site and found I needed to add ' PerlModule Apache' to my httpd.conf file. I get the error message listed below. I looked at the web site again and made sure that I was performing the 'make' and 'make install' steps for mod_perl. I get the same syntax error. I looked at the 'PerlSetEnv' command and didn't think it was the solution. Does anyone have any ideas? The error message and other details are listed below. Peggy Malone System Details: Apache version: 1.3.14 mod_perl version: 1.24_01 OS version: SunOS Generic_106541-09 sun4u sparc SUNW,Ultra-1 perl version: 5.005_03 built for sun4-solaris perl location:/usr/local/bin/perl complier version: gcc 2.95.2 -Error message # /usr/local/apache/bin/apachectl start [Thu Jan 11 16:08:15 2001] [error] Can't locate Apache.pm in @INC (@INC contains: /usr/local//lib/perl5/5.00503/sun4-solaris /usr/local//lib/perl5/5.00503 /usr/local//lib/perl5/site_perl/5.005/sun4-solaris /usr/local//lib/perl5/site_perl/5.005 . /usr/local/apache/ /usr/local/apache/lib/perl) at (eval 1) line 3. Syntax error on line 745 of /usr/local/apache/conf/httpd.conf: Can't locate Apache.pm in @INC (@INC contains: /usr/local//lib/perl5/5.00503/sun4-solaris /usr/local//lib/perl5/5.00503 /usr/local//lib/perl5/site_perl/5.005/sun4-solaris /usr/local//lib/perl5/site_perl/5.005 . /usr/local/apache/ /usr/local/apache/lib/perl) at (eval 2) line 3. /usr/local/apache/bin/apachectl start: httpd could not be started -Perl configuration file perl /apsrc/systems/mod_perl/mod_perl-1.24_01/Makefile.PL \ APACHE_SRC=/apsrc/systems/apache/apache_1.3.14/src \ DO_HTTPD=1 \ EVERYTHING=1 \ USE_APACI=1 \ PREP_HTTPD=1 ---Apache configuration file ./configure --prefix=/usr/local/apache \ --verbose \ --with-port=80 \ --logfiledir=/logrpt/apache \ --server-uid=http \ --server-gid=http \ --htdocsdir=/export/www2_root \ --enable-module=so \ --activate-module=src/modules/perl/libperl.a \ --activate-module=src/modules/php4/libphp4.a \ --enable-module=stats
Re: PerlRun problem: can't find method "uri"
On Thu, 4 Jan 2001, Jie Gao wrote: > Another problem with PerlRun is that it seems to interfere with mod_perl > handlers. > > I have an authentication/authorisation handler, which reads in from a > file for someinformation. After a script under PerlRun is run, the handler > fails to read anything from that file anymore. i can't see what's happening from this, too much missing. can you provide a small, but complete drop-in test case?
Re: getting rid of nested sub lexical problem
On Sat, 30 Dec 2000, Chris Nokleberg wrote: > oooh, cool. I've added this to Apache::DB.xs: > > int > stop_debugger() nice, i'll add that for the next version. > It appears that setting PL_perldb to zero is all that's required to turn > off the debugger! I thought I might have to fiddle with the symbol tables > but this seems to work. yeah, that should do it. > I've attached the latest version of Apache::NiceRegistry (suggestions > welcome) below. Not sure this is the right thing to do , but I call > Apache::DB::init_debugger directly because I need the return value (don't > want to stop_debugger if it was turned on outside of this handler), and I > don't want the warning that Apache::DB->init produces. calling init_debugger is fine. > Also, why does Apache::DB unset $Apache::Registry::MarkLine? it was breaking Apache::SmallProf i think. it should local-ize that change at least.
Re: Apache::DBI problem and writting a perl module!!!
On Thu, 11 Jan 2001, R. K . Mallah wrote:
> Stas , I do not face the problem anymore and Apache::DBI is loading
> without any problem. But i remember of facing problem at one point of time.
> may be with some older version.
Ok
> Could u please explain me what does Apache->module do and where is
> it defined ?
Why does it matter? You won't be able to test most of the Apache:: modules
from the command line, since the environment is wrong.
>From ch9 in the eagle book:
=item module()
If you need to find out if a Perl module has already been loaded, the
I method will tell you. Pass it the package name of the
module you're interested in. It will return a true value if the
module is loaded.
Example:
do { #something } if Apache->module('My::Module');
This method can also be used to test if a C module is loaded. In this
case, pass it the filename of the module, just as you would use with the
I directive. It will return a true value if the
module is loaded.
Example:
do { #something } if Apache->module('mod_proxy.c');
_
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: Apache::DBI problem and writting a perl module!!!
Stas , I do not face the problem anymore and Apache::DBI is loading
without any problem. But i remember of facing problem at one point
of time.
may be with some older version.
Could u please explain me what does Apache->module do and where
is
it defined ?
and Edmar could you please post the exact problem u are facing,
Regards
Mallah.
Stas Bekman wrote:
On Wed, 10 Jan 2001, R. K . Mallah wrote:
> I faced the same problem and had posted similar
email
> but I found an workaround that is there in the posting.
>
>
>
> I get following error when i do
>
> perl -e 'use Apache::Status;use Apache::DBI'
>
> Can't locate object method "module" via package "Apache" at
> /usr/lib/perl5/site_perl/5.6.0/Apache/DBI.pm line 202.
> Compilation failed in require at -e line 1.
> BEGIN failed--compilation aborted at -e line 1.
>
>
> the problem is when preparing menu_item for Apache::Status method
module
> is
> not found under Apache,
>
> do i have to install some other Apache module?
it has nothing to do with this. You cannot test Apache modules from
the
command line since you aren't running in mod_perl environment.
please read the documentation -- you have to load the Apache::Status
before Apache::DBI.
> anyway i commented out the if part and made it work like
>
> Apache::Status->menu_item(
>
> 'DBI' => 'DBI connections',
> sub {
> my($r, $q) = @_;
> my(@s) =
> qw(DatasourceUsername);
> for (keys %Connected)
{
>
push @s, '', join('', (split($;,
> $_))[0,1]), "\n";
> }
> push @s, '';
> return \@s;
> }
>
> );
>
> # ) if ($INC{'Apache.pm'} and Apache->module('Apache::Status'));
>
>
> is it correct ?
>
> why shouldn't it load without any modifications ?
>
> Regards
> Mallah
>
>
>
>
>
> --
> Rajesh Kumar Mallah,
> Learning Universe Pvt. Ltd,
> Piccadily House, 4th Floor,
> 275-276, Capt. Gaur Marg,
> Okhla, Sriniwas puri,
> New Delhi 110 065.
> M : +919811255597
> T : 91-11 6931601-04
> W : http://www.egurucool.com
> E : [EMAIL PROTECTED]
>
>
>
>
>
>
>
>
>
>
> Edmar Edilton da Silva wrote:
>
> > Hi all,
> >
> > I still didn't solve the problem of the
Apache::DBI. It can not be
> >
> > loaded into the apache's startup.pl file because happens a error
> > during
> > the starting of the apache, the child processes are not created.
For
> > using the Apache::DBI I had to add the "use Apache::DBI ()" code
at
> > the
> > beginning of each perl script.
> > Is it correct? Is the performance of the system damaged? I am working
> > in
> > this problem for some days, How I dont solve it, I intend to write
my
> > own connection pool. Please, can anyone tell me where I can find
docs
> > about this? Thanks for all.
> >
> >
> >
Edmar Edilton da Silva
> > Bacharel em Ciência da Computacão
- UFV
> > Mestrando em Ciência da Computacão - UNICAMP
> >
>
> --
> __ Technology Rules __
> Rajesh Kumar Mallah,
> M : +919811255597
>
>
>
>
>
_
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.orghttp://perlmonth.com/
--
__ Technology Rules __
Rajesh Kumar Mallah,
M : +919811255597
FW: Problem after rebooting apache with Oracle
Does anyone have ideas why we would get this error periodically after our
system has been running for about 20 minutes?
thanks,
-tom
[Wed Jan 10 16:22:45 2001] [error] DBI->connect(RSPD1) failed: ORA-12154:
TNS:could not resolve service name (DBD ERROR: OCIServerAttach) at
/usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris/DBI.pm line 411
DBI::connect('DBI', 'dbi:Oracle:RSPD1', 'username', 'password',
'HASH(0x192fb60)') called at /data/www/racesearch/htdocs/CGI/LIB/RSDBI.pm
line 323
RSDBI::connect('RSDBI') called at
/data/www/racesearch/htdocs/CGI/search_modules/SBPN.pm line 72
SBPN::main('SBPN', 'HASH(0x191d284)') called at
/data/www/racesearch/htdocs/CGImp/mhp line 132
Apache::ROOTwww_2eracesearch_2ecom::CGImp::mhp::mode_sbpn('HASH(0x191d284)')
called at /data/www/racesearch/htdocs/CGImp/mhp line 63
Apache::ROOTwww_2eracesearch_2ecom::CGImp::mhp::handler('Apache=SCALAR(0x237
cd74)') called at
/usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris/Apache/Registry.pm line
143
require 0 called at
/usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris/Apache/Registry.pm line
143
Apache::Registry::handler('Apache=SCALAR(0x237cd74)') called at
/dev/null line 0
require 0 called at /dev/null line 0
> Everything works fine for about 1/2 an hour and then we start getting the
> message below. We used to get an error that Oracle home was not found, so
we
> hard-coded it in and now we just get the message below.
was the ORACLE_HOME an error or just a warning? if your oratab is
set up properly it shouldn't need ORACLE_HOME once the instance is
found.
> Does anyone have any suggestions? If our code produces an oracle error,
does
> that corrupt the mod_perl process and therefore give any future users who
> connect to that particular process the error below?
>
> perl version 5.6.0
> Oracle 8.1.5
> mod_perl 1.21
> apache 1.3.12
i have a similar setup (5.6.0, 8.1.6, 1.21_1, 1.3.14) w/o any
problems IFF tnslsnr is set up properly and started. otherwise
there is chaos.
connecting via:
my @dbinfo =
qw(
dbi:Oracle:host=somehost;sid=foo
username
password
);
my $dbh = DBI->connect( @dbinfo ) or croak "Roadkill: $!";
the ORA-12154 gives me a freudian feeling that your tnslsnr is
not set up properly.
quick check:
. oraenv
lsnrctl;
> stop
> start
should tell you about stopping and starting properly. if it doesn't
then fix this before worrying about DBD::Oracle (or dump oracle for
a database that isn't living hell to set up).
note: i've just had to go through this in order to set up a demo
for one of our clients. i can haul my system in on monday and
we can go over the setup steps if anyone else is interested in this.
--
Steven Lembark 2930 W. Palmer St.
Chicago, IL 60647
[EMAIL PROTECTED] 800-762-1582
Re: Problem with installation mod_perl-1.24_01 and apache_1.3.14
Hi there, On Wed, 10 Jan 2001, Boris Lipsman wrote: > Can't located loadable object for module Apache::Constants in @INC Where is Constants.pm in your system? (There might be several of them, don't worry about it:) 73, Ged.
