记一次误操作-修改centos系统下/lib64/libc.so.6文件名

遭遇“ error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory”问题

安装PLIP需要glibc2.14，但是centos6最高支持2.12（查看方法 strings /lib64/libc.so.6 |grep GLIBC_），所以我在本地安装了2.14。问题是，PLIP调用的还是根目录下的/lib64/libc.so.6。我想出一个方案：

1、把系统根目录的libc.so.6改名为： libc.so.6.bak
2、然后通过
ln -s ~/.software/gli-2.14/lib/libc.so.6 /lib64/libc.so.6      #用自己安装的libc.so.6来代替系统自带的libc.so.6。

我为自己想出这么高明的办法暗自高兴一下，说干就干，动手。

当我刚执行第一步，我还没有察觉到问题，然后当我执行第二步，一回车，系统提示：

ln: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

我也没太在意这个错，以为仅是意外的出错而已，于是重新执行一下命令，没想到还是报同样的错！有点傻眼了……
我想既然不成功，那还是恢复原来状态吧，只要把改过的文件重新改回原来的名字即可。

再次执行：mv libc.so.6.bak  libc.so.6

结果：mv: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

我直接人傻了。。。

于是开始一个个尝试命令： cp、 mv、rm 等等，发现都报这个错，我这才明白闯大祸了，把服务器整死了。
经过不断尝试，发现多数的shell命令已经不能执行了，最主要的是可以恢复原文件的cp、mv、ln命令全都失效了。发现只有象pwd、cd 等小部分命令还可以使用，而这些命令于事无补。

看来只有到机房里，用安装盘进入急救模式，再把那个文件名改回来，才可能就能把机器救活了。

到了机房，试着重启机器，果然直接无法启动。然后我想先试一下从单用户模式中修改文件名，发现单用户模式也进不去，没办法，只能靠U盘进急救模式了。 我把U盘插入，重启机器，进入装系统界面，进入后不选择装系统，而选择troubleshooting(或者急救模式)，进入/lib目录下一看，libc.so.6文件还在啊，怎么回事？再想起在启动过程中，有句提示说原系统的目录mount在/mnt/sysimage目录下，于是进入到/mnt/sysimage，看到了与原服务器一致目录结构在那儿静静地躺着。再进入 /mnt/sysimage/lib，看到了lib.so.6.bak，看来刚才操作的时候，文件改名是成功了。现在当务之急是把文件名改回来。执行：
 mv libc.so.6.bak libc.so.6

然后关掉机器，拔掉U盘，再重启机器。

本想着系统可以一路欢歌进到登录界面，然而，这次竟然到启动进度条（centos6有进度条）的时候卡死了，没办法只能重启。

这次重启，到刚开始显示启动进度条的时候，我按“F5”键，这样可以查看启动过程中哪个地方出错了，结果显示是SElinux在为系统每个文件打标签。。。速度取决于文件的大小与数量。想了想我们服务器好几百T的数据，怎么可能短时间运行完！于是重新进入急救模式（此时单用户应该也行），将“/etc/selinux/config”中的配置信息“SELINUX=enforcing”修改为“SELINUX=disabled”。

再次重新启动，直接进入系统了，大功告成！

事后再总结一下这次事故的出错原因：
libc.so.6是bash这个shell依赖的重要动态库之一，当我把这个动态库（链接）改名之后，shell找不到这个库了，所以就报找不到libc.so.6，并拒绝执行多数shell指令，也中断了ssh连接请求，而在整个过程，操作系统的kernel却还是活的，所以我原先连接的两个ssh进程还有反应（对回车、pwd等小数指令有响应），但却不能新建ssh连接。

这次事故也给我一个教训：
不要随便改Linux/Unix的系统动态库！

参考：https://blog.csdn.net/benwdm/article/details/83564386