On Oct 21, 2013, at 2:56 PM, Thomas M. Payerle <paye...@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 <jdg...@elvis.arl.psu.edu> >> wrote: >> >>> In message <48fe8314-f95b-478b-9f2b-4c83f62dd...@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 paye...@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
