遭遇“ 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的系统动态库！

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

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