libc.so.6被误删除后的急救

最近遇到机房的一台虚拟机（测试机器）的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的：

末了，啰嗦一下：

linux 命里操作需谨慎啊，特别是rm命令！！！

对于重要的机器做好主备备份，定时rsync同步。

要不然出问题时，后悔无穷啊～～～