公布一下我的处理方法：
系统：CentOS release 5.4 x86_64
1、 LD_PRELOAD=/lib64/libc-2.5.so ls /lib64/libc.so.6 #如果存在
2、 LD_PRELOAD=/lib64/libc-2.5.so mv /lib64/libc.so.6 /lib64/libc.so.6.bak #其实也可以删除
3、 LD_PRELOAD=/lib64/libc-2.5.so ln -s /lib64/libc-2.5.so /lib64/libc.so.6 #增加软连
大家可以根据自己的版本修改成自己的libc-2.5.so版本文件
最近遇到机房的一台虚拟机（测试机器）的libc库的软链libc.so.6被删除了，实际文件libc.2.4.so还在。
机器现状：
还有shell远程连入，但是各种命令都不能再使用：
/bin/ls: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
网上搜索了一番，找到这个解决方案：
# LD_PRELOAD=<real libc> ln ......
相当于直接调用 ln命令，
所以，
先删除连接 ：
# cd /lib
# LD_PRELOAD=/lib/libc-2.3.6.so.bak rm libc.so.6
再建立新连接 ：
# LD_PRELOAD=/lib/libc-2.3.6.so.bak ln -s /lib/libc-2.3.6.so.bak libc.so.6
==》
分析： 由于shell仍然连入，因此此种方案可行。
原理就是：
linux调用so的库文件时，搜素路径为当前路径，再是系统lib目录。
但是提供了一个LD_PRELOAD系统变量来改变这个顺序。设置LD_PRELOAD了后，库加载的顺序就改为：
搜素路径为： LD_PRELOAD ，当前路径，再是系统lib目录。
（LD_PRELOAD还有其他妙用，可以参见之前的博文：linux下实现inject&hook）
因此，本次问题解决就很简单了： LD_PRELOAD=/lib64/libc.2.4.so ln -s libc.2.4.so libc.so.6
搞定。。。
针对这个问题，网上还有种方法是说使用busybox，但是至少在腾讯tlinux机器上，出现此种问题，busybox不能使用的。
原因是这个机器版本的busybox依赖libc。
============
现在抛出另一个问题：没有shell连接了怎么办？或者是libc.so彻底被删除了咋办？
=》解决也比较简单了（对于机器在机房的童鞋来说，你就认了吧，好好请运维吃饭，让他跑跑腿。。。）：
1.实体机：
直接拆下硬盘，在相同版本的linux机器上挂载，人工copy过去。
2.虚拟机：
关闭出问题的虚拟机，当前虚拟机同一个母机的其他虚拟机，增加虚拟硬盘，选择出问题的虚拟机硬盘文件，搞定后，和实体机处理的方式就一样了。
比如virtualbox的：
