首先普及一下关于libc.so.6的基本常识：
libc.so.6是glibc的软链接
ll /lib64/libc.so.6
lrwxrwxrwx 1 root root 11 Aug 27 2014 /lib64/libc.so.6 -> libc-2.5.so
glibc是gnu发布的libc库，即c运行库。glibc是linux系统中最底层的api，几乎其它任何运行库都会依赖于glibc，所以说绝大部分操作命令都缺少不了它
如何误删了/lib64/libc.so.6，大部分系统命令将无法执行，ssh登录系统也不成功，只会无休止的提示以下错误:
error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
这种情况下，大部分命令已经不能执行了，只能执行例如cd,echo等小部分命令，而实用的cp,mv则不可用
经过各种百度，得到解决方法（而此种方法的前提是ssh还没断开，如果ssh已断开则无法重新连接上，得使用另外的方法用光盘重启进入急救模式）：
在同版本系统上查看/lib64/libc.so.6得知是属于libc-2.5.so的软链接，因此，libc-2.5.so文件肯定还是存在的，误删的只是软链接而已，但此时想用ln命令重新建立软链接是失败的，但是可以这样强制设置变量就能执行成功
LD_PRELOAD=/lib64/libc-2.5.so ln -s /lib64/libc-2.5.so /lib64/libc.so.6
注意的是，这整条命令要在同一行执行，不能分两行，否则就无效了
glibc是一个非常底层的库，bash也依赖她，所以，如果把这个库干掉了，基本上啥事都干不了了，但是为啥前面设置一下LD_PRELOAD变量 就可以了呢？是这样的，LD_PRELOAD可以影响程序的运行时的链接（Runtime linker）， 它允许你定义在程序运行前优先加载的动态链接库，之前把libc.so.6这个软连接给干掉了，所以系统找不到这个库了，但是通过LD_PRELOAD设置一下glibc这个库的真实地址就可以解决这个问题了
通过前面设置一下LD_PRELOAD变量，后面也是可以执行其它例如cp,mv等命令的
例如我一开始不是误删，只是把libc.so.6改名了，从而也导致了上面的错误，于是就可以按照下面方法恢复libc.so.6
LD_PRELOAD=/lib64/libc-2.5.so mv /lib64/libc.so.6.bak /lib64/libc.so.6