Overview

When running the command:  openssl version -d ​, you get the error:

openssl: error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory ​ 

This problem occurs when there is a discrepancy between two versions of OpenSSL on your system. 

Solution

Diagnosis

Environment: Linux running SenSage AP Version 5.0.1

To confirm what is causing the problem, run the following commands in the terminal:

1. for i in $(rpm --queryformat "%{name}-%{version}.%{arch}\n" -qa | sort |grep openssl); do rpm -ql $i |grep openssl|grep bin ; done
2. which openssl
3. uname -a && cat /etc/issue
4. echo $PATH

The first command locates all the different versions of OpenSSL found on the system.

The second command locates the executable file presently associated with the openssl command by searching it in the path environment variable.

The third command displays the Kernel version and other system information.

The last command outputs the directories your shell is set to check for executable files. 

An example output, in the order of commands listed above, may look like:

1. /opt/sensage/latest/bin/openssl
/usr/bin/openssl
2. /opt/sensage/latest/bin/openssl
3. Linux iptip2s03 2.6.32-754.10.1.el6.x86_64 #1 SMP Tue Jan 15 10:31:16 PST 2019 x86_64 x86_64 x86_64 GNU/Linux
Oracle Linux Server release 6.10
Kernel \r on an \m
4. /usr/lib64/qt-3.3/bin:/opt/sensage/latest/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin: 

The message "error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory" usually occurs when there are two versions of a package with different dependencies installed on the same system.

Judging by the troubleshooting information we obtained in the output above, there do seem to be 2 different versions of OpenSSL on the node in question, a system/OS one installed via RPM installer and another one bundled with the Sensage AP Install.

SenSage AP's OpenSSL is linked to an old version of libssl which you are not going to find in the library in your (newer) OS version. The reason that you're getting the error message is that the folder that contains the Sensage OpenSSL binary is first in your path and is not matching the linked OpenSSL libraries from the OS version.

Solution

*Note: Overwriting the Sensage AP OpenSSL binary with the system OpenSSL binary is not recommended. Follow the solution given below instead.* 

The OpenSSL binary which is first in your path is internally linked to the Sensage deployment, so calling it won't link the OpenSSL libraries linked by the OS package of OpenSSL which is a different version. 

There are two ways you can resolve this:

1. To use the OS' OpenSSL, go with the absolute path /usr/bin/openssl and it will work fine. 
2. You are not expected to directly call the Sensage OpenSSL bundled with the deployment as it's custom-built. You can modify your PATH variable so that /usr/bin precedes  /opt/sensage/latest/bin.This should resolve the issue and this will not break anything in the Sensage AP P2 application.
   • • You may use the command export PATH=/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/opt/sensage/latest/binto change the order of the system PATH variable (the above is based on the Diagnosis example)

Testing

Test with the echo $PATHcommand again. /usr/bin should now precede  /opt/sensage/latest/bin. Please ensure that the latest path reflects in the current shell before testing.

You should not get the error again either.

Back to top