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

上一篇:1.搭建maven,eclipse创建maven项目


下一篇:eclipse 创建maven 项目 动态web工程报错