记录一下误删除libc.so.6的经历

起因： 在配置环境时，出现’GLIBCXX_3.4.29 not found’的错误，在解决这个问题的过程中，需要删除sudo rm /usr/lib/x86_64-linux-gnu/libstdc++.so.6软连接，但是一不小心sudo rm /lib/x86_64-linux-gpu/libc.so.6，可恶的tab键。

科普： libc.so.6是c运行时库glibc的软链接，而系统几乎所有程序都依赖C运行时库。程序启动和运行时，是根据libc.so.6软链接找到glibc库。删除libc.so.6将导致系统的几乎所有程序不能工作。如果程序编译的时候链接的libc库版本不在程序运行环境下的glibc库支持的libc版本之内，也会报错。于是，系统的所有命令 IS,cp,cd等等都无法使用了。

删除完libc.so.6之后，与服务器的ssh也登不上了，只有原先已连接的ssh还能继续存在。所以一旦断开远程连接，就只能去机房了。

尝试的解决措施：

1. 从相同的软件系统中，看看libc.so.6这个软连接所指向的文件，指向同目录下的libc-2.31.so动态库文件。
   
   如果你正好是root账户，就可以LD_PRELOAD=/lib/x86_64-linux-gnu/libc-2.31.so ln -s /lib/x86_64-linux-gnu/libc-2.31.so /lib/x86_64-linux-gnu/libc.so.6，重新创建软连接即可。

但好死不死，我是在自己的用户下，LD_PRELOAD=/lib/x86_64-linux-gnu/libc-2.31.so后，大部分命令都能够恢复，但是sudo命令并没有恢复，所以重新创建软连接时，权限不够。即使LD_PRELOAD和后面的ln -s在同一行时，亦不行。

这时，就进入了一个死循环，需要sudo命令拥有root权限才能创建libc.so.6的软连接，但是由于libc.so.6这个软连接的缺失，sudo命令无法使用。

科普：LD_PRELOAD的解决原理是，linux调用so库文件时，先搜索当前路径，然后是系统库目录，提供LD_PRELOAD系统变量可以改变这个顺序，改变后的搜索顺序为 LD_PRELOAD, 当前路径, 系统库目录。

2. 联系运维的同事，进入resume模型进行救援，失败告终。
3. 通过服务器的管理后台可以进入系统，执行如下操作，重新创建软连接，reboot重启，问题解决。