0b0000：起因
今天在服务器（Fedora28）上更新了一个程序，运行的时候跟我说公共库版本太低 /lib64/libc.so.6: version `GLIBC_2.18' not found
于是我就添加SCL源安装devtoolset，然后打算将本地的libc.so.6软链过去，接着习惯性地先将软链接删掉 rm -f /lib64/libc.so.6 （各位好孩子可千万别学我）
接下来，当我想使用ln创建软链接的时候，我发现有点不对劲了：
|
1 2 3 4 5 6 |
[root@localhost ~]# mkdir mkdir: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory [root@localhost ~]# ls ls: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory [root@localhost ~]# ln ln: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory |
0b0001：经过
其实如果到这里，你还没有断开ssh链接，那么是可以自救的，运行下面这条命令即可：
|
1 2 3 |
[root@localhost ~]# LD_PRELOAD=/lib64/libc-2.27.so ln -s /lib64/libc-2.27.so /lib64/libc.so.6 [root@localhost ~]# ls tokyo-hot.mp4 |
注意上面的libc-2.27是我当前系统的libc库版本，各个系统不一样，在CentOS 7 上面一般是2.17
BUT：由于我是非常手贱的人，顺手还把/lib64/libc-2.27.so也给一起删了，至此服务器已经被我搞得彻底用不了了，ssh也已经无法连接了
于是我赶紧地联系机房的人员协助处理，首先让他们直接使用光盘启动（当然如果你是使用的云服务商，也可以发工单或者直接在后台将iso加载进VPS，如下图）
接着使用光盘或者其他什么途径启动到光盘的安装欢迎界面：
在这里我们选择Troubleshooting，然后选择Rescue a Fedora system（CentOS显示的是 Rescue a CentOS system ），稍等片刻会进入到恢复界面
选择１然后继续，接下来会提示我们原有系统挂载点已经挂载到/mnt/sysimage，是否使用chroot来将其切换到根，由于原有系统本来就是无法使用的，所以就不挂载了，直接按Enter继续，进入命令行之后，可以再次使用 lsblk来确认一次挂载
确认无误后，执行下面2条语句：
|
1 2 3 |
#再次提醒要注意版本号，CentOS 7 默认的是libc-2.17 [sh-4.4] cp /lib64/libc-2.27.so /mnt/sysimage/lib64/ [sh-4.4] ln -s /lib64/libc-2.27.so /mnt/sysimage/lib64/libc.so.6 |
0b0010：结果
在经过一阵紧张地重启过程后，系统正常启动了，瞬间松了一口气，虽然看起来只需要几个步骤，但是从出问题到找到解决办法再到联系机房人员处理，中间还是花掉了很多时间，导致线上环境受到了一定的影响。幸好线上的架构是多机热备的，其中一个出了问题还有其他的顶着，要不然网站就得瘫痪了。
因此在这里写下这篇记录，就当给自己提个醒 ，希望以后不要再范同样的错误
- 凡事在动手之前一定要想想后果
- 线上服务器任何操作之前最好都先备份一下，养成习惯
- linux系统的rm是个超级大杀器，没有特殊情况的话最好不要加f，最好可以在bashrc里面加上
alias rm='rm -i'，双重保险 - 越着急的问题越不要去催机房的哥们，要不然多半会收到反效果，将心比心吧，冷静点才能最快处理好问题
2条评论. Leave new
学习了
厉害的Tk