Re: Oracle problem on Red Hat Linux 6.1

[posted and mailed]

<ddf_dba_at_my-deja.com> wrote in message news:8ivs1h$1rf$1_at_nnrp1.deja.com...
> ***** Is there anyone who can shed some light on this? I cannot believe
> that no one else has experienced this before. *****

Ah - I thought I'd seen this before.

Because the $ORACLE_HOME/oracle binary is setuid oracle, for security the LD_LIBRARY_PATH that's set in the environment before it is run is ignored by a "normal" user other than Oracle - this happens on solaris, I'm presuming Linux behaves similarly. Otherwise it would be trivial to persuade the system to execute arbitrary code as the oracle user. Ie, the path to the libskgxp8.so (and other) libraries linked into the oracle executable is used in preference to any value you set in LD_LIBRARY_PATH at runtime.

So, if you've renamed the /oracle/product/8.1.6 (or whatever) directory since you first installed and linked the software, or Something Strange happened during linking, then the load of the libraries by the shadow process will fail. If you were to run a truss -f of sqlplus doodah/whatnot, and you should see the forked-off shadow process trying and failing to open the libskgxp8.so file.

To confirm this do:

ldd ORACLE_HOME/bin/oracle

and I expect you will see something like

        libskgxp8.so =>  (file not found)
        libwtc8.so =>    /oracle/product/8.1.6/lib/libwtc8.so
        libjox8.so =>    /oracle/product/8.1.6/lib/libjox8.so

Ie, the system is following the linked-in search path (which can be show using "ldd -s" on solaris - ldd on RH6.1 doesn't appeared to have this option).

I believe you don't encounter the same problem with remote connections via the listener because the listener is already running as oracle, so the system trusts the LD_LIBRARY_PATH variable. Not sure whether this rationale is correct or not, but it has the right flavour.

The solution when I had I this problem was to relink the executable with your new ORACLE_HOME. That's something like:

make -f $ORACLE_HOME/rdbms/lib/ins_rdbms.mk default

We often just pick the rdbms software up between our Solaris boxes and, if we transfer the software to a different /oracle/product directory on the destination machine, things can get very confusing...

HTH, -michael E Received on Mon Jun 26 2000 - 00:00:00 CDT