简介

libc.so 是 Linux 系统上的一个实现了 C 语言标准库的操作系统底层动态链接库，通常其内还包含操作系统系统调用的封装。在大多数 Linux 操作系统上使用的是 glibc(GNU C Library) 标准库实现。

在 /lib64 目录下还会经常看见 libc.so.6（常常以软链接的形式存在，指向具体的 libc.so），其对应着一个具体的 libc 动态库版本。

总之，libc.so 相关链接和动态库是整个 Linux 操作系统的基石，几乎所有命令都依赖这个基础库（极极极极极极少数被作为应急处理的命令不依赖这个基础库）。所以，任何需要升级或者改动和这个基础库相关的行为都是极其不推荐的，不到万不得已不要对这个库做出任何改动。

相关事故

在互联网上可以检索到很多因为各种原因删除、移动、修改了 libc.so 相关链接和动态库的悲惨故事。因为，几乎所有命令和程序都依赖这个动态库(如下随便截图了几个命令)，任何改动都会使得这些命令或程序找不到依赖而失效报错（甚至于无法进行 ssh 远程连接和开机等基础操作）。

接下来我将通过删除 libc.so.6 软链接来复现这个问题并尝试恢复操作系统。

高危操作，请勿随意尝试！！！

注意要点：

• 若是直接把动态库本身删除了，那可以不必在浪费时间寻找恢复的解决方案了，直接进入重装系统环节。

• 若是远程 ssh 连接对服务器进行了此等操作，千万不能关闭 ssh 客户端，否则会因为 libc.so.6 的缺失而无法新建 ssh 连接，也就再也上不去了，直接进入重装系统环节。

• 修改操作必须以 root 用户进行，否则后续恢复过程中对 /lib64 目录的任何修改都将因为无权限无法进行，且也正如上图所示，此时 sudo 命令也因为 libc.so.6 的缺失而无法运行。

高危操作命令：

此时，几乎所有命令都会因为找不到 libc.so.6 而报错。但是，恢复原理也很简单，就是重建 libc.so.6 这个软链接就可以了，但是注意 ln 命令也依赖这个动态库，其运行时也会报这个错。解决方案有两个：

1. 通过 LD_PRELOAD 环境变量告诉 ln 命令真正的动态库在哪（也就是 libc.so.6 原本指向的那个动态库）

2. 找到一个不依赖 libc.so.6 的重建软链接的命令，那就是 sln 命令。

注意：若操作时的用户不是 root，将没有权限操作此目录，且 LD_PRELOAD 不会对 sudo 命令生效，此时就需要直接进入重装系统环节

总结

修改 libc.so 相关链接和动态库的操作一般出现在基础库升级时，而基础库升级往往是因为需要使用的其他程序依赖更高版本的基础库。所以，一般我们不升级 libc.so 基础库，当其他程序需要依赖时，也采用单独为其拷贝一份更高版本的基础库到其指定的使用目录下，而非直接升级整个操作系统基础库。