error while loading shared libraries
After installing Oracle 10g RAC, we checked the configuration of the cluster database like this:
[oracle@primary01 ~]$ srvctl config database -d compdb
/u01/app/oracle/product/10.2.0/db_1/jdk/jre/bin/java: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory
It failed with an error related to loading shared libraries, specifically complained about libpthread.so.0. I remember I fixed such error during CRS installation and now I see it again. What happen?
Let's inspect the file.
[oracle@primary01 ~]$ which srvctl
/u01/app/oracle/product/10.2.0/db_1/bin/srvctl
Did you see that? This SRVCTL is from ORACLE, not from CRS. That is to say, we have two SRVCTL.
[oracle@primary01 ~]$ ll $ORA_CRS_HOME/bin/srvctl
-rwxr-xr-x 1 oracle oinstall 5587 Aug 18 2011 /u01/app/oracle/product/10.2.0/crs_1/bin/srvctl
Solutions
The first solution is to use the formerly fixed SRVCTL from CRS like this.
[oracle@primary01 ~]$ /u01/app/oracle/product/10.2.0/crs_1/bin/srvctl config database -d compdb
primary01 compdb1 /u01/app/oracle/product/10.2.0/db_1
primary02 compdb2 /u01/app/oracle/product/10.2.0/db_1
[oracle@primary01 ~]$ /u01/app/oracle/product/10.2.0/crs_1/bin/srvctl status database -d compdb
Instance compdb1 is running on node primary01
Instance compdb2 is running on node primary02
The second solution is to fix ORACLE's SRVCTL, to unset an environment variable called LD_ASSUME_KERNEL just like we did to CRS's SRVCTL.
Let's look for the environment variable, it's around line# 167.
[oracle@primary01 ~]$ vi /u01/app/oracle/product/10.2.0/db_1/bin/srvctl -c "se nu"
...
166 LD_ASSUME_KERNEL=2.4.19
167 export LD_ASSUME_KERNEL
168 unset LD_ASSUME_KERNEL
...
Or you can comment out the export line.
167 #export LD_ASSUME_KERNEL
Then we check the result.
[oracle@primary01 ~]$ srvctl config database -d compdb
primary01 compdb1 /u01/app/oracle/product/10.2.0/db_1
primary02 compdb2 /u01/app/oracle/product/10.2.0/db_1
[oracle@primary01 ~]$ srvctl status database -d compdb
Instance compdb1 is running on node primary01
Instance compdb2 is running on node primary02
The problem is solved.