由于安装nagios3.0.3需要GLIBC2.4,而/lib/tls/libc.so.6 是一个软连接
ll -h libc.so.6
libc.so.6 -> libc-2.3.4.so
#ldd /usr/local/nagios/bin/nagios
/usr/local/nagios/bin/nagios: /lib/tls/libc.so.6: version `GLIBC_2.4′ not found (required by /usr/local/nagios/bin/nagios)
而系统中 /lib/tls/libc.so.6 最高只支持2.3.4
strings /lib/tls/libc.so.6 | grep GLIBC
GLIBC_2.0
GLIBC_2.1
GLIBC_2.1.1
GLIBC_2.1.2
GLIBC_2.1.3
GLIBC_2.2
GLIBC_2.2.1
GLIBC_2.2.2
GLIBC_2.2.3
GLIBC_2.2.4
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_PRIVATE
没有想什么，找了一个库
strings /lib/libc-2.7.so |grep GLIBC
GLIBC_2.0
GLIBC_2.1
GLIBC_2.1.1
GLIBC_2.1.2
GLIBC_2.1.3
GLIBC_2.2
GLIBC_2.2.1
GLIBC_2.2.2
GLIBC_2.2.3
GLIBC_2.2.4
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_PRIVATE
把它连过去后，
ln -sf /lib/libc-2.7.so /lib/tls/libc.so.6
使用ldconfig加载，一个恶梦就开始了
什么命令也用不了，vi也无法，而这是一生产的运营机器，放在广州的IDC 啊，心里想着如何处理这件事情，想着重连也不行，怎么也不行 啊
一下就掉到冰水了，还好远程的ssh会话还在，部门命令还可以用，服务还在正常跑，还好。
根同事说了一声，做好了准备去IDC的打算，唉
还是不心甘，试来试去，花了近半小，晚上1点半了
那个文件用rm -f也搞不掉 用ln -sf等，都不行
想着怎么把这个文件清掉，vi也没法开，
后来终于想到了这个救命的echo
echo test
test
echo加载在RAM中，history也是跑在 RAM里面
用了
echo /dev/null > /lib/libc-2.7.so
再ldconfig
再打入ls 一切OK
啊，是万能的echo 救了我，是对系统库的不清楚进行的无知操作搞死这个OS
