perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Johnson <john...@Pharmacy.Arizona.EDU>
Subject Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?
Date Mon, 21 Oct 2013 22:25:28 GMT

On Oct 21, 2013, at 2:56 PM, Thomas M. Payerle <payerle@umd.edu> wrote:

> On Mon, 21 Oct 2013, Bruce Johnson wrote:
> 
> Based on path, sounds like you have a 64 bit version of Oracle.  I am
> assuming that you verified that your mod_perl is a 64 bit build.
> 

yes it is.

> Is your mod_perl setuid/setgid?  If so LD_LIBRARY_PATH gets ignored.
> 

I don't think so, but even so, shouldn't the PerlSetEnv directive be followed? Isn't that
the point of a PerlSetEnv directive?

> My guess would be that the dependent libraries of Oracle.so are not being
> picked up for some reason, despite ldd "finding" them.  One thing you might try
> is to set LD_PRELOAD to the paths to libocci and libclntsh (from man page
> looks like should be whitespace separated), before starting apache, and see
> if that gets things to work.  Probably not a good long term solution (as
> likely adds bloat to httpd processes), but will at least confirm that the
> problem is that it is not finding those libs during the dynamic load.

It's not strictly an Apache problem, because the script works on this server when it's set
to run as a CGI program.

Also I'm not clear what LD_PRELOAD would accomplish that LD_LIBRARY_PATH does not. These are
not subsitute libraries, they're the only libocci libraries on the system. I've had issues
like this when i have both oracle and the instant client running on the same system, but properly
setting LD_LIBRARY_PATH and ORACLE_HOME deal with that in Apache.



> 
>> 
>> On Oct 21, 2013, at 2:03 PM, John D Groenveld <jdg117@elvis.arl.psu.edu>
>> wrote:
>> 
>>> In message <48FE8314-F95B-478B-9F2B-4C83F62DD1AE@pharmacy.arizona.edu>,
Bruce J
>>> ohnson writes:
>>>> Nope, that looks right:
>>>> 
>>>> # ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>>> 	linux-vdso.so.1 =>  (0x00007fffc8980000)
>>>> 	libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1
(0
>>>> x00007fb39a816000)
>>>> 	libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.
>>>> 1 (0x00007fb397f84000)
>>>> 	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb397d5d000)
>>>> 	libc.so.6 => /lib64/libc.so.6 (0x00007fb3979ca000)
>>>> 	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb3976c3000)
>>>> 	libm.so.6 => /lib64/libm.so.6 (0x00007fb39743f000)
>>>> 	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb397229000)
>>>> 	libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007fb
>>>> 396e5c000)
>>>> 	libdl.so.2 => /lib64/libdl.so.2 (0x00007fb396c58000)
>>>> 	libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb396a3f000)
>>>> 	libaio.so.1 => /lib64/libaio.so.1 (0x00007fb39683d000)
>>>> 	/lib64/ld-linux-x86-64.so.2 (0x00007fb39acae000)
>>>> 
>>>> 
>>>> Also, if the linking was wrong here, it wouldn't work on the command line
or a
>>>> s a CGI script, either, I'd think.
>>> 
>>> As the webserver user?
>>> # su - apache
>>> $ /bin/printenv
>>> $ /bin/env -i /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>> 
>> 
>> # su -s /bin/sh apache
>> sh-4.1$ /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>> 	linux-vdso.so.1 =>  (0x00007fff047a7000)
>> 	libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0x00007f659f56c000)
>> 	libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x00007f659ccda000)
>> 	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f659cab3000)
>> 	libc.so.6 => /lib64/libc.so.6 (0x00007f659c720000)
>> 	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f659c419000)
>> 	libm.so.6 => /lib64/libm.so.6 (0x00007f659c195000)
>> 	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f659bf7f000)
>> 	libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007f659bbb2000)
>> 	libdl.so.2 => /lib64/libdl.so.2 (0x00007f659b9ae000)
>> 	libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f659b795000)
>> 	libaio.so.1 => /lib64/libaio.so.1 (0x00007f659b593000)
>> 	/lib64/ld-linux-x86-64.so.2 (0x00007f659fa04000)
>> 
>> 
>> Nope.
>> 
>> And if it were an issue under apache, the script would break when run as a CGI program,
which it doesn't.
>> 
>> It only breaks under mod_perl.
>> 
>> 
>> -- 
>> Bruce Johnson
>> University of Arizona
>> College of Pharmacy
>> Information Technology Group
>> 
>> Institutions do not have opinions, merely customs
>> 
>> 
>> 
> 
> Tom Payerle
> IT-ETI-EUS 				payerle@umd.edu
> University of Maryland			(301) 405-6135
> College Park, MD 20742-4111

-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs



Mime
View raw message