背景
发生时间: 2022年11月28日08:55:20
偷了个懒，在安装tmux的时候直接从别的服务器上copy二进制文件，而且是跨OS 版本的。缺少一些lib库文件，直接从安装好的机器上copy过来。然后系统就崩了。惨痛的教训.
为了在线上安装环境依赖，给glibc库升级，由于线上环境libc.so版本低，不支持安装，所以手贱把动态库中的libc.so.6给移走了，直接导致Linux系统崩溃，系统瘫痪，所有用户均被强制退出。
意识到缺少对libc.so的认识，以为跟普通的lib包类似，直接把新版的so软连过去就可以满足安装和升级，现在哦豁… 软链不软链已经不重要了，反正腿是软趴趴的。
问题
执行tmux 命令发现缺少相关库依赖文件. 于是一波S操作。
目标机器
~]$tmux new -s etl01 tmux: error while loading shared libraries: libevent-2.0.so.5: cannot open shared object file: No such file or directory ~]$tmux new -s etl01 tmux: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by tmux) tmux: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib64/libevent-2.0.so.5) tmux: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by /usr/lib64/libevent-2.0.so.5) tmux: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by /usr/lib64/libevent-2.0.so.5)
tmux安装成功的机器
⚡ root@master1 /tmp scp -p /usr/lib64/libevent-2.0.so.5 10.50.10.43:/usr/lib64/ root@10.50.10.43's password: libevent-2.0.so.5 100% 291KB 107.7MB/s 00:00 ⚡ root@master1 /tmp ⚡ root@master1 /tmp ⚡ root@master1 /tmp scp -p /lib64/libc.so.6 10.50.10.43:/lib64/ root@10.50.10.43's password: libc.so.6 0% 0 0.0KB/s --:-- ETApacket_write_wait: Connection to 10.50.10.43 port 22: Broken pipe lost connection ✘ ⚡ root@master1 /tmp scp -p /lib64/libc.so.6 10.50.10.43:/lib64 ssh: connect to host 10.50.10.43 port 22: Connection refused lost connection ✘ ⚡ root@master1 /tmp scp -p /lib64/libc.so.6 10.50.10.43:/lib64 ssh: connect to host 10.50.10.43 port 22: Connection refused lost connection
22端口down了，我就知道系统崩了。因为之前测试环境搞过一次，而这次是正式环境。
原因
libc.so.6 是很基础的库(glibc)，是软连接到在Linux系统中基本的命令，有很多可执行文件都会依赖这个共享库。当不小心把这个库改名字或者移走了，都会导致不同程度的异常，可以借助LD_PRELOAD变量和"ldconfig"命令来恢复这个共享库。前提是终端没有断开的情况下操作。
libc.so.6是一个类似于WINDOWS下的一个快捷指向型的文件，而 linux有两种库，分别为：glibc、libc
解决
解决分为两种情况
1、当前session未断开
如果发现问题的当下没有关闭当前terminal就比较好恢复。 一旦关闭窗口将无法重新连接(可以自己新建窗口试下)，重启机器后也将无法进入系统 。必须使用第二种方式修复
LD_PRELOAD允许你定义在程序运行前优先加载的动态链接库,因此在使用ln前就加载了lib库，而不是等到使用ln时加载，这样就能临时使用命令了
LD_PRELOAD=/lib64/libc-2.12.so ln -s /lib64/libc-2.12.so /lib64/libc.so.6
2、OS崩溃重启，所有ssh session断开
对于OS 直接崩溃的，比较难搞。我的属于这种，OS 直接重启了。而且起不来的那种。
当时登入ILO单用户模式，OS 在重启，一大堆trace，看着就好不了的那种。
1、急救模式Rescue mode
2、rescue模式选则挂载sysinages 这个FS
3、在这个挂载点把之前的libc.so.6恢复
详细操作见参考【2】
惨痛教训
1、对于上产环境的内核依赖库文件不能随意覆盖、删除。
例如
① 内核级的 /lib64
② 系统级的 /usr/lib64
③ Root用户级别的/usr/local/lib64
2、 scp 文件覆盖问题
scp 命令默认会覆盖源文件，没有交互模式询问你是否覆盖。对于敏感文件scp 之前先确认目标服务器上是否存在，如果存在应先备份再进行后续操作.
总结
此次事件是因对系统层认知不足, 根本原因就是我使用了高版本 2.17 的libc.so.6,覆盖了系统的2.12版本导致的问题。
对于这个错误操作我做出深刻检讨, 对事件负全责。望今后自己和同事能引以为戒，避免再次发生此类事件.
参考
【2】救援模式恢复
