Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?
Dr James A Smith <[email protected]>
| Newsgroups | gmane.comp.apache.mod-perl |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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 <[email protected]> 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.