libsdeora11gsrvr93.so error with SDE 9.3.1

596
5
09-29-2010 01:23 PM
Highlighted
by Anonymous User
Not applicable
Original User: peasland

I am running Oracle 11g on Linux 64-bit. I installed SDE 9.3.1 with no problems. SDE starts just fine. When I attempt to connect to SDE with ArcCatalog, I get the following error in my sde.log file:

/u01/app/sde/sdeexe93/bin/gsrvr: error while loading shared libraries: libsdeora11gsrvr93.so: cannot open shared object file: No such file or directory

I have verified that the lib file is readable. It is owned by sde after all. The sde user has oinstall as its primary group. LD_LIBRARY_PATH is set correctly in my environment and in my dbinit.sde file.

Any other suggestions?

Cheers,
Brian
0 Kudos
5 Replies
Highlighted
by Anonymous User
Not applicable
Original User: vangelo

What are the contents of the PATH, LD_LIBRARY_PATH, SDEHOME, and ORACLE_HOME
environment variables?

What does "file $SDEHOME/bin/sdelayer $ORACLE_HOME/bin/sqlplus" return?

What does "ldd  `which gsrvr`" return?

What shell are you using?

- V
0 Kudos
Highlighted
by Anonymous User
Not applicable
Original User: peasland

What are the contents of the PATH, LD_LIBRARY_PATH, SDEHOME, and ORACLE_HOME
environment variables?

What does "file $SDEHOME/bin/sdelayer $ORACLE_HOME/bin/sqlplus" return?

What does "ldd  `which gsrvr`" return?

What shell are you using?

- V


LD_LIBRARY_PATH = /u01/app/sde/sdeexe93/lib:/usr/lib:/lib:/u01/app/oracle/product/db/11.1.0/lib
SDEHOME = /u01/app/sde/sdeexe93
ORACLE_HOME = /u01/app/oracle/product/db/11.1.0
PATH = /u01/app/sde/sdeexe93/bin:/u01/app/oracle/product/db/11.1.0/bin:.:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/NX/bin:/home/sde/bin

[prompt]$ file $SDEHOME/bin/sdelay/u01/app/sde/sdeexe93/bin/sdelayer: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), for GNU/Linux 2.4.0, stripped
[prompt]$ file $ORACLE_HOME/bin/sqlplus
/u01/app/oracle/product/db/11.1.0/bin/sqlplus: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped


[prompt]$ ldd `which gsrvr`
        libsdeora11gsrvr93.so => /u01/app/sde/sdeexe93/lib/libsdeora11gsrvr93.so (0x00002b513e109000)
        libsde.so => /u01/app/sde/sdeexe93/lib/libsde.so (0x00002b513f27a000)
        libsg.so => /u01/app/sde/sdeexe93/lib/libsg.so (0x00002b513f72f000)
        libpe.so => /u01/app/sde/sdeexe93/lib/libpe.so (0x00002b513f880000)
        libicuuc.so.22 => /u01/app/sde/sdeexe93/lib/libicuuc.so.22 (0x00002b513fb5e000)
        libxerces-c.so.27 => /u01/app/sde/sdeexe93/lib/libxerces-c.so.27 (0x00002b513fd18000)
        libclntsh.so.11.1 => /u01/app/oracle/product/db/11.1.0/lib/libclntsh.so.11.1 (0x00002b5140225000)
        libXm.so.3 => /usr/lib64/libXm.so.3 (0x00002b514291a000)
        libXmu.so.6 => /usr/lib64/libXmu.so.6 (0x0000003014e00000)
        libXp.so.6 => /usr/lib64/libXp.so.6 (0x00002b5142dbb000)
        libXt.so.6 => /usr/lib64/libXt.so.6 (0x0000003028000000)
        libSM.so.6 => /usr/lib64/libSM.so.6 (0x000000301f000000)
        libICE.so.6 => /usr/lib64/libICE.so.6 (0x000000301dc00000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000003017600000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003016a00000)
        libg2c.so.0 => /usr/lib64/libg2c.so.0 (0x00002b5142fc5000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b51431e6000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003014a00000)
        libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x00002b5143401000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003014600000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003014200000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003021c00000)
        libicudata.so.22 => /u01/app/sde/sdeexe93/lib/libicudata.so.22 (0x00002b51436dd000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003023800000)
        libnnz11.so => /u01/app/oracle/product/db/11.1.0/lib/libnnz11.so (0x00002b5143d32000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003018200000)
        libaio.so.1 => /usr/lib64/libaio.so.1 (0x00002b5144184000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000003016200000)
        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x0000003016e00000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003013e00000)

I am using the BASH shell.

You didn't ask for it, but here is the contents of my dbinit.sde file:

# dbinit.sde
#

set SDEHOME=/u01/app/sde/sdeexe93
set ORACLE_HOME=/u01/app/oracle/product/db/11.1.0
set LD_LIBRARY_PATH=$SDEHOME/lib:/usr/lib:/lib:$ORACLE_HOME/lib
set ORACLE_SID=fgodev3


I think that is everything you asked for.

Thanks!
Brian
0 Kudos
Highlighted
Esri Esteemed Contributor
Does the giomgr process user's .profile, .bash_profile or .bashrc clear the contents of
PATH or LD_LIBRARY_PATH?

By the time the dbinit.sde is consulted, it's too late to set the SDEHOME or LD_LIBRARY_PATH.
My ArcSDE boot script executes $SDEHOME/etc/.profile to establish database-specific
environment variables before executing 'sdemon -o start'. This way I only need to put the
ORACLE_SID or TWO_TASK (and possibly NLS_LANG) in the dbinit.sde (and can use the
same profile for all Oracle instances, regardless of ArcSDE release).

My complete multi-instance Linux boot script framework is buried in the se_toolkit release
tree (in all release bundles, under samples/boot/redhat_etc).

- V

### $SDEHOME/etc/.profile ###
ORACLE_HOME=/opt/oracle/product/10.2.0/db32
LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
NLS_LANG=AMERICAN_AMERICA.AL32UTF8
export ORACLE_HOME NLS_LANG LD_LIBRARY_PATH

### $SDEHOME/etc/dbinit.sde ###
set ORACLE_SID=xxxx10g2
unset TWO_TASK

### /etc/init.d/arcsde ###

Start_SDE()
{
...
# .. Set environment variables
#
SDEHOME=$2
PATH=$SDEHOME/bin:$origPATH
LD_LIBRARY_PATH=$SDEHOME/lib:$origLD
SDEVERBOSE=$3
export SDEHOME PATH LD_LIBRARY_PATH SDEVERBOSE

# .. Retrieve password
#
if [ -f $SDEHOME/etc/.passwd ]; then
sdepass=`cat $SDEHOME/etc/.passwd`
else
report_error ERROR &&
printf "\t--> $SDEHOME/etc/.passwd not found\n"
return 1
fi

# .. Execute etc/.profile (if present)
#
if [ -f $SDEHOME/etc/.profile -a ! -x $SDEHOME/etc/.profile ]; then
report_error ERROR &&
printf "\t--> $SDEHOME/etc/.profile not executable\n"
return 1
fi
test -x $SDEHOME/etc/.profile && . $SDEHOME/etc/.profile

# .. Execute command
#
sdemon -o start -i $1 -p $sdepass >> $logFile 2>&1
...
}
0 Kudos
Highlighted
by Anonymous User
Not applicable
Original User: peasland

Does the giomgr process user's .profile, .bash_profile or .bashrc clear the contents of
PATH or LD_LIBRARY_PATH?

}


Those files do not clear the env vars. I do not have a .profile file. Here is the contents of my .bashrc file:

# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi


Here is my .bash_profile file:


# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs

PATH=.:$PATH:$HOME/bin

export PATH

export SDEHOME=/u01/app/sde/sdeexe93
export ORACLE_HOME=/u01/app/oracle/product/db/11.1.0
export ORACLE_SID=fgodev3

export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$SDEHOME/lib

export PATH=$SDEHOME/bin:$ORACLE_HOME/bin:$PATH


To start SDE, I just entered:

sdemon -o start -p password


So I'm not doing anything fancy here. Just set the env vars and startup SDE.

Thanks,
Brian
0 Kudos
Highlighted
Esri Esteemed Contributor
What user starts the 'sdemon' application?

One way to find out what's wrong with the environment is to replace 'gsrvr'
with a shell script that dumps the environment (and possibly a ldd of the
superceeded gsrvr).

It's just about time to contact Tech Support on this issue.  The only time
I've seen something similar was on a client's HP/UX host where the 64-bit
install binaries had been corrupted by a silent disk failure.

- V
0 Kudos