记一次linux服务器问题处理过程

本周二的时候，涛哥找我，说明了一件事，在安装ganglia的时候，发生的一个问题。

在一台suse 10 sp1的服务器上，安装ganglia的一个依赖包，libconfuse.rpm,安装完成之后，

执行任何命令都会出现段错误的提示，而且无法再次ssh登录，也无法直接console登录。

ssh登录，提示握手的时候错误，console登录提示init失败，请等等五分钟。

根据所有这些提示找到的解决方案都不适用于我们的情况。

其实在这个时候，涛哥给我讲了一件事，说前两天也发生过类似的事情，说是库连接指向的问题，当时我没有对这个事情引起足够重视，最后发现问题和以前的原因是一样的。

当时涛哥在安装软件的时候，有提示说libc.2.4太旧，所以他就下载了一个新的suse libc.2.11.1.so上传上来，删除了旧的链接，删除之后就发现有问题了，直接断开，之后他用

系统盘进入救援模式，然后进去后fdisk -l找到系统盘，把系统盘加载到/mnt,然后进去/lib64,把libc重新链接回2.4，重启问题解决。

但事情并没有结束，他没有把自己上传的libc.2.11.1.so删除，还是留在那个地方了。

而这次他安装libconfuse.rpm之后，问题再现了 。

warning: libconfuse-2.6-10.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 4f38b5aa

Preparing... ########################################### [100%]

1:libconfuse ########################################### [100%]

Updating dynamic linker cache...

/sbin/ldconfig: /usr/local/lib/libncursesw.so.6 is not a symbolic link

/sbin/ldconfig: /usr/local/lib/libncursesw.so.5 is not a symbolic link

/sbin/ldconfig: /usr/local/lib/libncurses.so.6 is not a symbolic link

/sbin/ldconfig: /usr/local/lib/libncurses.so.5 is not a symbolic link

/sbin/ldconfig: /usr/local/lib/l

rpm -qp --scripts libconfuse-2.6-10.1.x86_64.rpm

postinstall script (through /bin/sh):

echo Updating dynamic linker cache...

/sbin/ldconfig

postuninstall script (through /bin/sh):

echo Updating dynamic linker cache...

/sbin/ldconfig

核心就是在这一步ldconfig命令起的作用，我查询了ldconfig，它就是起一个创建共享库的缓存文件的作用，加速以后对共享库的调用，类似的还有一个prelink的命令，可以事先对命令和共享库进行连接，提高执行速度。

但是没想到的是，ldconfig居然改变了软链的指向，如果他发现了更新的so文件，居然直接把指向改成了最新的so,这个时候，如果你新的so文件有问题，譬如我们的后来发现是suse11适配的so，不适于suse10sp1。你的系统就会崩溃了。

libc是一个很重要的库文件，很多命令都直接调用它，你想一下，linux命令是基于c开发的，libc又是最基本的c函数库，它出问题了，很多命令就会报segment fault的错误。

在没有找到根本原因，不能有十足的把握解决这个问题之前，我们不敢重启服务器，因为重启了就可能无法启动，就会影响上面执行的业务。这也给了我很大的启迪，不要以为重启就能解决问题，千万千万不能贸然重启机器，因为有时候重启之后业务根本就启不来了，甚至系统都启不来，必须找到事情发生的根本原因，最好是能够自己重现。

抱着重现的想法，我们下载了suse 10的介质，自己在虚拟机上安装系统，然后再次安装了libconfuse.rpm,没有发现任何问题，我们也rpm-ql libconf查看安装的文件，没有什么，就在lib64/下面一个so文件，一个软链而已，不应该造成那样的影响，可能就是ldconfig执行的时候，原来隐藏的问题被激活了。

我们根据报的错误搜索谷歌，但没有发现有用的解决方案，这给我们的启迪是，虽然他们遇到的问题也是这样，有了自己的解决方案，但是我们搜索的关键词是问题反映的表象，极有可能每一个人的环境不一样，上下文件不一样，但是最后发生问题的表象是一样的，可能引起这种表象的根本原因是数种，我们直接照搬，不考虑上下文件 和背景，那不仅不起作用，而且是不负责任的。必须要结合自己的背景上下文件情况，找到问题发生的根本原因，然后重现，再去搜索关键词，才能解决问题。

幸运的是当时这台机器上运行的ftp服务进程还可以用，我们ftp上去，对lib下面的文件进行排查，发现正常的机器和不正常的机器的一些区别，就是上面我们说的，出问题的机器上，libc.so.6.居然又指向了libc.2.11.1，而不是正常的2.4.so.

我们在虚拟机上重现了这个问题，症状一模一样，我们找到了根本原因。

还有一个启迪是，当时我有一个想法，就是我对linux的认识不到位，不能很好地定位问题，身边也没有很熟悉linux的专家，如果我们能有这种的专家来帮我们定位问题，解决问题就好了，其实这种想法也有问题。我在看《宝莲灯前传》的时候，有句台词打动了我，如来收到了一个礼物，金菠萝花，如来拈花，迦叶一笑，如来说迦叶悟出了其中真谛，而金婵子不明所以，和迦叶争吵，玉帝说为何不直接讲明呢，菩萨说佛家道理重在一个悟字，只可意会不可言传。其实我们人类很多成长的过程就是只可意会不可言传，只有你自己经历了，你才能拥有真的本领，而不单单是接受别人灌输的二手知识。根据问题，思考探索的过程才能真正培养你的思维和能力，而不是直接接受别人的经验。而且人人都不愿意受这份探索的苦，就会变成人云亦云，不利于整个社会的和谐发展。