今天早上看到阿里云云盾中心报了一堆的系统安全漏洞，心血来潮就在每台机器上 yum update，十几台服务器上，重启的时候偏偏一台机器出问题，更要命的是，这台机器是至关重要的发布机器，没有这东西，程序员那帮哥们根本发不了版本。

症状发作过程如下：

早上yum update 完成后，因为担心有人发版本，也没有重启服务器，但不到10分钟，一个开发人员报告说系统出问题了，发不了版本，我也没有多想，感觉应该是升级系统原因，重启下就好了，谁知重启了半天也连接不上系统，就通过控制台，远程连接进来检查了下，发现系统初始化的时候包kernel panic了。对linux系统熟悉的人都知道，出现这个就是操作系统癌症啊。一般情况下重装了事，单这个系统资料都没有备份，重装了系统，肯定玩玩了。这里也给自己提了个醒，重要服务器做任何有风险操作之前至少给系统来个快照，虽然阿里云会抢钱，但为了防患于未然，掏钱买保险也是值得的。

报错界面如下图：

这种情况自己也就无能为力了，只好提交了工单求助于阿里云的售后人员，他们通过修改引导顺序，进入了升级前的内核。也算是顺利进入系统了

上面，默认 default=0 会报 kernel panic,修改 default=1 进入第二个内核启动项，可以启动系统。

单进入系统后，敲入发布命令又傻眼了，什么都是 segment fault

一开始也怀疑到了是glibc 库更新导致，但比较了正常系统和这个出问题系统的glibc版本都是一样的。一直折腾了晚上12点多。中间也把脚本copy到了另外一台服务器上，把脚本环境搭建了起来。做好这些后，我搜索引擎中，说如“系统升级程序 segment fault”,一篇文章启发了我，作者也是因为升级系统导致很多程序段错误，结果他查到时因为glibc升级造成，主要是定位到了，glibc升级 c库文件 libc.so.6 软链到了升级后的 libc,  导致了程序错误。

上图中 libc.so.6 连接到了 升级后的 libc-2.15.so  而不是 libc-2.12.so ,几台正常的服务器，glibc没有升级。只有出问题的这台glibc升级了。

然后，满怀希望的，进入 /lib64目录 执行 ulink libc.so.6 ,结果跳出狼窝，又掉入虎穴。

执行除了cd 几个命令外，都报 上面错误，提示找不到共享库文件，因为libc是系统最底层的库文件，几乎所有动态库文件都依赖它，结果常用命令都失效了，如果能控制物理机，还能通过系统盘进入，但这个阿里云的虚拟机。。。。。。几乎快绝望的时候 又看到一个有用的冷僻救命的命令

sln  （static ln）静态编译的 ln命令，不要依赖libc 库，我觉得这个命令唯一用处技术，lib.so.6 出问题的时候救火用的，

所有，赶紧 /sbin/sln  /lib64/libc-2.12.so /lib64/libc.so.6     执行完后，世界又重归美好，然后在系统上敲入之前报段错误的 svn，mvn命令，激动人心的事情出现了，启动mysql ，nginx

salt-master 一路顺风顺水。发布系统又活了回来了。今天真正体会到了“山重水复疑无路，柳暗花明又一村”。几个错误猛一看都是无药可救的，但好在，自己坚持，并且也真没有比的选择，一直到问题解决，收获也是满满滴!!!!!!

总结：

1，系统重要变更前一定要备份（快照），真的会少走弯路

2，yum update 有时候也不靠谱，特别时候升级glibc库的时候千万当心

3，如果做很多自装程序出现 “segment fault” ，第一个应该怀疑libc 出现的版本问题。