首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 开发语言 > Ruby Rails >

遭遇“ error while loading shared libraries: libc.so.6: cannot .”有关问题

2012-07-27 
遭遇“ error while loading shared libraries: libc.so.6: cannot ...”问题遭遇“ error while loading sha

遭遇“ error while loading shared libraries: libc.so.6: cannot ...”问题

遭遇“ error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory”问题

?


今天中午,在Redhat AS5 上解决一个数据库连接问题,在应用的日志中发现如下报错信息:
[error] [client 145.24.216.86] /lib/libc.so.6(__libc_start_main+0xdc)[0x4138cdec],


在系统中搜索了一下,发现三个位置有libc.so.6:

/home/ora10g/product/10.2.0/db_1/lib/stubs/libc.so.6
/lib/i686/nosegneg/libc.so.6
/lib/libc.so.6

看到Oracle也带有libc.so.6, 于是怀疑会不会是Oracle 10g与系统自己的libc.so.6版本不兼容而导致错误呢?

?

一时兴起,想出一个方案:
1、把系统自己的libc.so.6改名为: libc.so.6.bak
2、通过
ln -s /home/ora10g/product/10.2.0/db_1/lib/stubs/libc.so.6 /lib/libc.so.6
用Oracle的libc.so.6来代替系统自带的libc.so.6

?

我为自己想出这么高明的办法暗自高兴一下,说干就干,动手。

?

第一步,先把/lib/libc.so.6改名为libc.so.6.bak。
执行:

[root@145 lib]#? cd /lib
[root@145 lib]#? mv libc.so.6 libc.so.6.bak

?

第二步,把Oracle的动态库连接到/lib/libc.so.6
执行:
[root@145 lib]# ln -s /home/ora10g/product/10.2.0/db_1/lib/stubs/libc.so.6 libc.so.6

一回车,系统提示:
ln: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

我也没太在意这个错,以为仅是意外的出错而已,于是重新执行一下命令,没想到还是报同样的错!有点傻眼了……
我想既然不成功,那还是恢复原来状态吧,只要把改过的文件重新改回原来的名字即可。
再次执行:
[root@145 lib]# mv libc.so.6.bak? libc.so.6
系统还是报错:
mv: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

这下可真傻眼!!汗!!!

于是开始一个个尝试命令: cp、 mv、rm 等等,发现都报这个错,我这才明白闯大祸了,把服务器整死了。
经过不断尝试,发现多数的shell命令已经不能执行了,最主要的是可以恢复原文件的cp、mv、ln命令全都失效了。发现只有象pwd、cd 等小部分命令还可以使用,而这些命令于事无补。

用SecureCRT尝试ssh登录这个服务器,已经无法连接到服务器,而原来连接在上面的两个进程却没被中断,服务器只是拒绝新连接而已。

?

看来只有到机房里,用安装盘进入急救模式,再把那个文件名改回来,才可能就能把机器救活了。

以前安装的光盘已经失踪了,但还好在一台机器上找到了同版本的一个ISO文件,于是赶紧刻盘,然后去机房。

?

到了机房,把光盘放入光驱,重启机器,进启动到 LILO: 界面时,输入
linux rescue
然后根据提示进入到急救模式,进入/lib目录下一看,libc.so.6文件还在啊,怎么回事?再想起在启动过程中,有句提示说原系统的目录mount在/mnt/sysimage目录下,于是进入到/mnt/sysimage,看到了与原服务器一致目录结构在那儿静静地躺着。再进入 /mnt/sysimage/lib,看到了lib.so.6.bak,看来刚才操作的时候,文件改名是成功了。现在当务之急是把文件名改回来。执行:
?mv libc.so.6.bak libc.so.6

再次确认文件已改名成功,关掉机器,退出光盘,再重启机器,系统一路欢歌,进到登录界面。终于大功告成了。

?

?

事后再总结一下这次事故的出错原因:
libc.so.6是bash这个shell依赖的重要动态库之一,当我把这个动态库(链接)改名之后,shell找不到这个库了,所以就报找不到libc.so.6,并拒绝执行多数shell指令,也中断了ssh连接请求,而在整个过程,操作系统的kernel却还是活的,所以我原先连接的两个ssh进程还有反应(对回车、pwd等小数指令有响应),但却不能新建ssh连接。

?

这次事故也给我一个教训:
不要随便改Linux/Unix的系统动态库!


更不要在生产机上随便改!!


最不应该是还是在白天改!!!

?

?

?

?

?

热点排行