最近看到知乎上，关于最让自己印象深刻的一次bug的经历，的讨论，不禁让我回想起了研一时，那一次libc依赖损坏的事故。
当时需要在断网服务器集群上部署一个caffe程序，负责部署的同学跟我说他的程序需要升级libc，我并未多想，给他的账号开通root权限后让他自行操作(我以为他会使用yum安装)。
许久之后，他突然找到我说，服务器崩溃了，ssh无法连接，我立刻新建了一个ssh测试了一下，果然出了错误，我的心一下子就揪了起来，因为此时我还无法确定ssh崩溃的原因是什么，如果只是配置文件的问题还好说，如果是系统问题那麻烦就大了。
当时我非常慌张，这台服务器上已经配置了许多服务，如果此时重装服务器，之前的努力将会前功尽弃，而且重装需要专人上门配置，如此一来工期就会大大拖延，我用最短的时间跟他确认了在崩溃之前进行的操作，在一大通对账之后，我惊讶的发现他自己编译出libc并直接使用make install安装到了系统里，由于一些现在已经不可考据的原因跟系统不兼容，大部分命令已经无法使用了。
当时的情况是原系统中/lib64/libc.so.6软链到/lib64/libc-2.12.so，被手动make install之后软链变成了指向/lib64/libc-2.23.so，之后大量的命令无法使用
报错类似于error while loading shared libraries: __vdso_time: invalid mode for dlopen(): Invalid argument
万幸的是手上当时还有一个ssh连接没有关闭，我冷静下来，使用LD_PRELOAD=/lib64/libc-2.12.so [cmd]进行尝试，发现还可以恢复这部分命令。最后在小心翼翼的恢复了软链之后，又从集群中的其他机器上复制了根目录下的文件进行替换，才彻底解决了这次事件，之后我第一时间下掉了他的root权限，并告知他以后他的libc依赖只能自己指定环境变量来加载。