Re: Error appears in web log but script runs ok on the command line

Just a wild guess:

mod_perl sets %ENV, but *AFTER* loading DBD::Oracle, so the XS part of 
DBD::Oracle won't see the required environment variables. It is possible 
to manipulate %ENV from inside Perl (this includes mod_perl) and then 
load DBD::Oracle, or at least it was possible for a long time.

I would try to make mod_perl execute something like the following code 
as early as possible, even before DBI is loaded:

$ENV{'ORACLE_HOME'}='/some/where';
# maybe set up other Oracle related environment variables
require DBD::Oracle; # loads the XS part AFTER setting up the environment


Alexander


On 21.10.2013 23:36, Bruce Johnson wrote:
> Nope, built and run with the same path, same install. I installed the Instant Client Basic and Development packages via the rpms, set up the proper environment variables, used cpan to install DBI, then DBD::Oracle and both built without any errors.
>
> It's absolutely a mod_perl handler thing, I just don't know where the problem is. It's acting as though it's ignoring its environment settings, even though a perl script run by that handler says the environment is correct.
>
>
> On Oct 21, 2013, at 2:19 PM, "Furst, Carl" <[email protected]> wrote:
>
>> So did you build DBD::Oracle with that LD_LIBRARY_PATH?
>> And against that install?
>>
>> Maybe Oracle.so is using LD_LIBRARY_PATH set at build time instead of
>> runtime?
>>
>>
>>
>>
>> Carl Furst
>>
>>
>>
>>
>>
>> On 10/21/13 4:03 PM, "Bruce Johnson" <[email protected]> wrote:
>>
>>> On Oct 20, 2013, at 1:03 PM, Bruce Johnson <[email protected]>
>>> wrote:
>>>
>>>> Oh it turned out to be even simpler than that, and for once it wasn't
>>>> MY fat fingers that fat fingered it this time :-)
>>> Cue the sad trombone, because I was wrong, again.
>>>
>>> It turns out the issue seems to have something to do with mod_perl.
>>>
>>> It works find from the command line, it works fine when the script is
>>> executed as a classic CGI script, it fails when run as a mod_perl handler
>>> with an error that indicates that LD_LIBRARY_PATH is wrong or missing.
>>>
>>> I can recreate the error in CGI mode by commenting out the server
>>> directive 'SetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib'
>>>
>>> When I found the errors in the conf file, I didn't know that my co-worker
>>> had tried that because he'd read that in some web page somewhere and he
>>> was starting to get desperate, because nothing was working.
>>>
>>> I have, however managed to isolate the problem, and it's got to do with
>>> mod_perl
>>>
>>> I'm chasing this on the mod_perl list, but without much luck and am
>>> hoping if anyone else has run into this issue using mod_perl and
>>> DBD::Oracle.
>>>
>>> We've set a directory to be handled by mod_perl as follows:
>>>
>>> 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>
>>>
>>> With those directives in place, I get the error every time. (I've added
>>> ORACLE_SID and TNS_ADMIN to the PerlSetEnv declarations, but it makes no
>>> difference.
>>>
>>> LD_LIBRARY_PATH is set, this is the contents of %ENV and %INC according
>>> to the server, with that mod_perl directive in place:
>>>
>>> DOCUMENT_ROOT --> /home/allwebfiles/static
>>> GATEWAY_INTERFACE --> CGI/1.1
>>> HTTPS --> on
>>> HTTP_ACCEPT -->
>>> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
>>> HTTP_ACCEPT_ENCODING --> gzip,deflate,sdch
>>> HTTP_ACCEPT_LANGUAGE --> en-US,en;q=0.8
>>> HTTP_CONNECTION --> keep-alive
>>> HTTP_COOKIE --> __qca=P0-1946018635-1381167733063;
>>> SESS360e9fa4a6458358b044501f2b5b21b9=4862153113fc157562a1fc7691eecb36;
>>> __utma=219252696.1214622818.1382045504.1382045504.1382045504.1;
>>> __utmz=219252696.1382045504.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(no
>>> ne); CASAUTHOK=1; COPInt=ghZxjY9mJ74QPBgWE13I8cGha
>>> HTTP_HOST --> xxxxx.pharmacy.arizona.edu
>>> HTTP_USER_AGENT --> Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5)
>>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
>>> 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
>>> QUERY_STRING -->
>>> REMOTE_ADDR --> 128.196.45.237
>>> REMOTE_PORT --> 49295
>>> REQUEST_METHOD --> GET
>>> REQUEST_URI --> /card_access/envvars.pl
>>> SCRIPT_FILENAME --> /home/allwebfiles/perl/catcard/envvars.pl
>>> SCRIPT_NAME --> /card_access/envvars.pl
>>> SERVER_ADDR --> 150.135.124.49
>>> SERVER_ADMIN --> root@localhost
>>> SERVER_NAME --> xxxxx.pharmacy.arizona.edu
>>> SERVER_PORT --> 443
>>> SERVER_PROTOCOL --> HTTP/1.1
>>> SERVER_SIGNATURE -->
>>> Apache/2.2.15 (Red Hat) Server at xxxxx.pharmacy.arizona.edu Port 443
>>>
>>> SERVER_SOFTWARE --> Apache/2.2.15 (Red Hat)
>>> SSL_TLS_SNI --> xxxx.pharmacy.arizona.edu
>>> INC
>>> 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
>>>
>>> But attempting to create a database handle results in:
>>>
>>> [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
>>>
>>> EVEN THOUGH libocci.so.11.1 is right where it's supposed to be, in
>>> $LD_LIBRARY_PATH.
>>>
>>> # cd $LD_LIBRARY_PATH
>>> # pwd
>>> /usr/lib/oracle/11.2/client64/lib
>>> # ls -al
>>> total 185024
>>> drwxr-xr-x 2 root root      4096 May 20 12:07 .
>>> drwxr-xr-x 5 root root      4096 May 20 14:12 ..
>>> -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
>>>
>>> Has anyone run into this before?
>>>
>>> -- 
>>> Bruce Johnson
>>> University of Arizona
>>> College of Pharmacy
>>> Information Technology Group
>>>
>>> Institutions do not have opinions, merely customs
>>>
>>>
>>
>>
>>
>>
>>
>> **********************************************************
>>
>> MLB.com: Where Baseball is Always On


-- 
Alexander Foken
mailto:[email protected]  http://www.foken.de/alexander/