Chinaunix首页 | 论坛 | 博客
  • 博客访问: 54523
  • 博文数量: 13
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 30
  • 用 户 组: 普通用户
  • 注册时间: 2014-01-04 14:48
个人简介

为者常成,行者常至

文章分类
文章存档

2014年(13)

我的朋友

分类:

2014-02-12 15:32:59

ssh: /lib/i686/libc.so.6: version `GLIBC_2.3′ not found (required by ssh)

2008年3月27日

今天一個客戶提到他的主機中ssh相關指令突然無法操作,會出現:

ssh: /lib/i686/libc.so.6: version `GLIBC_2.3′ not found (required by ssh) 這樣的錯誤訊息。

由於我的客戶都會自行編譯程式或是修改函數庫的路徑等,因此原先認為應該是修改LD_LIBRARY_PATH錯誤造成的問題,但看了一下PATH 的設定又找不出頭緒,其它執行指令又正常的情況下,想說試試著重新安裝與更新新版的open-ssh試試看,這一更新後發現到:

  • [root@linux i386]# rpm -Uvh openssh-*
    Preparing… ########################################### [100%]
    1:openssh ########################################### [ 20%]
    2:openssh-askpass ########################################### [ 40%]
    3:openssh-askpass-gnome ########################################### [ 60%]
    4:openssh-clients error: unpacking of archive failed on file /usr/bin/ssh: cpio: rename failed – Operation not permitted
    4:openssh-server ########################################### [ 80%]

嘿嘿~看到 /usr/bin/ssh: cpio: rename failed – Operation not permitted 大概就知道問題所在拉,這檔案應該被動過手腳,果真,請出lsattr大神來看一下,馬上現形:

  • [root@linux i386]# lsattr /usr/bin/ssh
    s–ia———
    /usr/bin/ssh

將將 !! 被人設上了s、i、a三個屬性,這三個屬性有甚麼通天本領讓整個指令在執行時失效呢?

  • s:當隱藏屬性s功能被啟動後,該檔案將會被完全的移除出這個磁碟空間。
  • i:這個旗標i可說是超級大功能,它可以讓一個檔案不能被刪除、更名與設定連結當然也無法寫入新的資料。
  • a:當隱藏旗標被開啟 a 的功能時,這個檔案只可以增加資料,但是不能被刪除,只有超級使用者root才能設定這個屬性。
  • 解決方式:透過chattr -sia 將三個隱藏旗標通通移除,這樣就可以恢復正常了 ~^^~
-----------------------------------------------------------------

/lib/tls/libc.so.6 出错,引起一个恶梦

由于安装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

阅读(2310) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~