perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dr James A Smith <...@sanger.ac.uk>
Subject Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?
Date Mon, 21 Oct 2013 20:23:46 GMT
You may have some "quirk" going on with DBD::Oracle - it has a nasty 
BEGIN block in it which
does some nasty stuff... I had a three day head scratch with this module 
moving from Lucid to
Precise as it was not finding the tnsnames files - in the end I had to 
set up the environment
before starting up apache. As the Env settings int the config were not 
in place when DBD::Oracle
was used for the first time. Not sure when it is being used tho' but it 
took a lot of "root"y
hacking to discover the problem!

James

On 21/10/2013 19:37, Bruce Johnson wrote:
> On Oct 21, 2013, at 11:20 AM, Fred Moyer <fred@redhotpenguin.com> wrote:
>
>> This is annoying but it happens on 64 bit architectures.
>>
>>> The path is correct, the script works fine on the command line, and if I comment
out the handler directives in the perl.conf script, put in a ScriptAlias and process the script
as a normal CGI script, it also works.
>> Sounds like some environment variable is not getting passed correctly to mod_perl.
Maybe dump out %ENV from the command line and see if there are additional vars you need to
pass?
> Nope, good idea but the vars I need are present, even with the modperl handler in place.
The only ones you need for DBD::Oracle to work are ORACLE_HOME and LD_LIBRARY_PATH
>
> DBD::Oracle was properly compiled, else it wouldn't work on the command line, either.
>
>> I'd dump out %INC from the command line and mod_perl also to make sure that you are
loading the needed modules. You could try to install DBD::Oracle in /usr/lib instead of /usr/local/lib
also - my guess is that it's looking for the Oracle.so in /usr/local/lib but it is located
somewhere else.
> With mod_perl there is just one more, /etc/httpd
>
> command line:
>
> INC-> /usr/local/lib64/perl5
> INC-> /usr/local/share/perl5
> INC-> /usr/lib64/perl5/vendor_perl
> INC-> /usr/share/perl5/vendor_perl
> INC-> /usr/lib64/perl5
> INC-> /usr/share/perl5
> INC-> .
>
> server:
>
> INC-> /usr/local/lib64/perl5
> INC-> /usr/local/share/perl5
> INC-> /usr/lib64/perl5/vendor_perl
> INC-> /usr/share/perl5/vendor_perl
> INC-> /usr/lib64/perl5
> INC-> /usr/share/perl5
> INC-> .
> INC-> /etc/httpd
>
>
>>
>> On Mon, Oct 21, 2013 at 10:57 AM, Bruce Johnson <johnson@pharmacy.arizona.edu>
wrote:
>> We've set a Directory directive for some perl scripts, setting a mod_perl handler:
>>
>> Alias /card_access /home/allwebfiles/perl/catcard
>>
>>   <Directory /home/allwebfiles/perl/catcard>
>>       SetHandler perl-script
>>       PerlResponseHandler ModPerl::Registry
>>       PerlOptions +ParseHeaders
>>       Options +ExecCGI
>>       PerlSetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
>>       PerlSetEnv ORACLE_HOME /usr/lib/oracle/11.2/client64
>>   </Directory>
>>
>> The %ENV variable is there, if I print the %ENV values:
>>
>> LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib
>> MOD_PERL --> mod_perl/2.0.4
>> MOD_PERL_API_VERSION --> 2
>> ORACLE_HOME --> /usr/lib/oracle/11.2/client64
>> PATH --> /sbin:/usr/sbin:/bin:/usr/bin
>>
>> But trying to initialize a DBI database connection results in the following error:
>>
>> [Mon Oct 21 10:10:37 2013] [error] install_driver(Oracle) failed: Can't load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so'
for module DBD::Oracle: libocci.so.11.1: cannot open shared object file: No such file or directory
at /usr/lib64/perl5/DynaLoader.pm line 200.\n at (eval 11) line 3\nCompilation failed in require
at (eval 11) line 3.\nPerhaps a required shared library or dll isn't installed where expected\n
at /home/allwebfiles/perl/catcard/oratest.pl line 9\n
>>
>> Which is precisely the error you get when LD_LIBRARY_PATH is unset or incorrect.
>>
>> libocci.so.11.1 is where it's supposed to be.
>>
>> [root@merthiolate catcard]# ls -l /usr/lib/oracle/11.2/client64/lib
>> total 185016
>> -rw-r--r-- 1 root root       368 Sep 17  2011 glogin.sql
>> lrwxrwxrwx 1 root root        17 May 20 12:07 libclntsh.so -> libclntsh.so.11.1
>> -rw-r--r-- 1 root root  52761218 Sep 17  2011 libclntsh.so.11.1
>> -rw-r--r-- 1 root root   7955322 Sep 17  2011 libnnz11.so
>> lrwxrwxrwx 1 root root        15 May 20 12:07 libocci.so -> libocci.so.11.1
>> -rw-r--r-- 1 root root   1971762 Sep 17  2011 libocci.so.11.1
>> -rw-r--r-- 1 root root 118408281 Sep 17  2011 libociei.so
>> -rw-r--r-- 1 root root    164836 Sep 17  2011 libocijdbc11.so
>> -rw-r--r-- 1 root root   1503303 Sep 17  2011 libsqlplusic.so
>> -rw-r--r-- 1 root root   1477446 Sep 17  2011 libsqlplus.so
>> -rw-r--r-- 1 root root   2095661 Sep 17  2011 ojdbc5.jar
>> -rw-r--r-- 1 root root   2714016 Sep 17  2011 ojdbc6.jar
>> -rw-r--r-- 1 root root    300666 Sep 17  2011 ottclasses.zip
>> -rw-r--r-- 1 root root     66779 Sep 17  2011 xstreams.jar
>>
>> The path is correct, the script works fine on the command line, and if I comment
out the handler directives in the perl.conf script, put in a ScriptAlias and process the script
as a normal CGI script, it also works.
>>
>> I'm confident the issue doesn't have anything to do with DBI or DBD::Oracle.
>>
>> It ONLY fails when the script is executed as a mod_perl handler.
>>
>> The script itself is very simple; all I do is create a database handle and if no
error is thrown, print 'It works'.
>>
>> #!/usr/bin/perl
>> use DBI;
>> use strict;
>>
>> my $login="xxxxxx";
>> my $dbpass='xxxxxxxx';
>> my $dbname="host=xxx.xxx.xxx.xx;sid=xxx";
>> my $dbh = DBI->connect("dbi:Oracle:$dbname", $login, $dbpass, {RaiseError =>1});
>>
>> print "Content-type: text/html\n\n";
>> print "It Works";
>> exit;
>>
>> (and this is just a test , any script using DBI fails with this error.)
>>
>> What am I missing?
>>
>> --
>> Bruce Johnson
>> University of Arizona
>> College of Pharmacy
>> Information Technology Group
>>
>> Institutions do not have opinions, merely customs
>>
>>
>>


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com



-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 

Mime
View raw message