Libc.so.6:cannot open Shared object file error handling

First, the phenomenon of failure

The current network of a REDHAT6 host since the business staff upgrade compiled a package, SSH can not log on normally, landing error for Libc.so.6:cannot open shared object file, LDd view confirmation, the use of libc.so.6 files located in/ The lib64 directory.

[Root@361way ~]# ldd/usr/sbin/sshd |grep libc.so
Libc.so.6 =>/lib64/libc.so.6 (0x00007fa2017ed000)

Found by viewing the file is a soft link file:

[Root@361way ~]# ll/lib64/libc.so.6
lrwxrwxrwx 1 root 21:50/lib64/libc.so.6-> libc-2.14.so

Second, the failure to solve

By comparing the same version of the normal host another REDHAT6 host, found that the use of libc.s0.6 soft link is libc-2.12.so file, so you can confirm that the package was compiled by the source of the business staff when the upgrade. According to previous experience, the current soft chain before the backup and then deleted, and then relink libc-2.12.so file can solve the problem. However, after the execution of Rm-rf/lib64/libc.so.6, then execute the LS, MV, LN, CP, and so on any one of the commands, the type of error will appear as follows:

/bin/ls:error while loading shared libraries:libc.so.6:cannot open Shared object file:no such file or directory

After finding the error on the Internet, the discovery can be resolved by using Ld_preload, as follows:

Delete the connection first:
# cd/lib64
# Ld_preload=/lib64/libc-2.3.6.so.bak RM libc.so.6--> I can delete normal, this step omitted, can not be deleted, the first execution of this step
To establish a new connection:
# Ld_preload=/lib64/libc-2.3.6.so.bak Ln-s/lib64/libc-2.3.6.so.bak libc.so.6

Note: Since REDHAT7 has no x86 bit system, the old x86 bit system Lib file is located in the/lib directory. In addition to note that the Ld_preload and the following command RM, LN, and so must be in the same line, can not execute the ld_preload before the execution of Ln-s, this will still be an error.

Three, principle analysis

Ld_preload solve the principle is: Linux call so library files, the search path is the current path, and then the system Lib directory. However, a ld_preload system variable is provided to change this order. When the ld_preload is set, the order in which the libraries are loaded is changed to:

The search path is: ld_preload, current path, and then system Lib directory
Of course, this is not the solution, you can also use the online recommendation of another method BusyBox method, the Redhat6 version of the BusyBox does not rely on any Lib library files, as follows:

[Root@361way ~]# Whereis BusyBox
BusyBox:/sbin/busybox/usr/share/man/man1/busybox.1.gz
[Root@361way ~]# Ldd/sbin/busybox
Not a dynamic executable

Note that this is not absolute, and some distributions will rely on BusyBox such as libc.so.6 library files.

Perform the desired action through BusyBox Ln or busybox rm.

Summary: The error here is only a small problem, if the shell can not be implemented, you need to repair the mode or disc guide to solve, if the corresponding package file is missing, but also in the repair check mode, install the appropriate package