What should I do if the error message "error while loading shared libraries" is displayed

Problem Phenomenon

When an ECS instance of the Linux system starts the SSH service, an error message similar to the following is displayed.

error while loading shared libraries: libcrypto.so.10: cannot open shared object file: No such file or directory.

Execute cat /var/log/secure to view the secure log, and an error message similar to the following appears.

PAM unable to dlopen(/usr/lib64/security/pam_tally.so): /usr/lib64/security/pam_tally.so: cannot open shared object file: No such file or directory.

Problem Causes

The operation of the SSH service depends on the relevant system library files. When the relevant library files are abnormal (such as the relevant library files are missing or the permission configuration is abnormal), the SSH service will start abnormally.

Solution

You can fix this problem by repairing the libcrypto.so.10 library file or rolling back the cloud disk.

Solution 1: Repair libcrypto.so.10 library file

You can repair the abnormal instance (B instance) by checking the library file information in other normal instances (A instance).

1. Log in to the normal instance (A instance) and execute the following command to view the information about the libcrypto.so.10 library file.

ll /usr/lib64/libcrypto.so.10

The system displays something similar to the following. The libcrypto.so.10 library file is a soft link to the libcrypto.so.1.0.1e library file.

lrwxrwxrwx.1 root root 19 Jan 8 12:40 /usr/lib64/libcrypto.so.10 -> libcrypto.so.1.0.1e

2. Execute the following command to view the information about the libcrypto.so.1.0.1e library file.

ll /usr/lib64/libcrypto.so.1.0.1e

The system displays something like the following.

-rwxr-xr-x.1 root root 1965856 Jan 8 03:22 /usr/lib64/libcrypto.so.1.0.1e

Record the path, authority, and group information of normal library files.

3. Remotely connect to the abnormal ECS instance (B instance) via VNC.

4. Execute the following command to find the libcrypto.so.1.0.1e library file.

find / -name libcrypto.so.1.0.1e

Depending on whether the libcrypto.so.1.0.1e library file exists in the ECS instance, there are the following two solutions.

• The libcrypto.so.1.0.1e library file exists.

Execute the following command to copy the found files to the normal directory.

cp [$File] /usr/lib64/libcrypto.so.1.0.1e
Note [$File] is the absolute path of the libcrypto.so.1.0.1e library file found in the previous step.

• The libcrypto.so.1.0.1e library file does not exist.

Upload the libcrypto.so.1.0.1e library file on other normal instances to the /usr/lib64 directory of the target instance through FTP software.

5. Execute the following commands in sequence to modify the file permissions, owner, and group.

chmod 755 /usr/lib64/libcrypto.so.1.0.1e
chown root:root /usr/lib64/libcrypto.so.1.0.1e

6. Execute the following command to create a soft link.

ln -s /usr/lib64/libcrypto.so.1.0.1e /usr/lib64/libcrypto.so.10

7. Run the following command to start the SSH service.

systemctl start sshd.service

Solution 2: Restoring by rolling back the cloud disk

If it is not repaired through Solution 1: Repairing the libcrypto.so.10 library file, if you have created a snapshot for the system disk, you can restore it by rolling back the historical snapshot of the system disk.

important

Snapshot rollback will cause data loss after rollback, please confirm before proceeding.

It is recommended to try to roll back the snapshots one by one in order of time from recent to far until the SSH service can run normally. If the SSH service still cannot run normally after the rollback, it means that the system at the corresponding time point has been abnormal.