How to Resolve SRVCTL Error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory

  • by

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.

Leave a Reply

Your email address will not be published. Required fields are marked *