一场库文件的远程修复
 系统环境RHEL 4.7
 一、原因:
 发现每天早上7点1分备份的数据库文件时间不对,登录上去后date下发现时间是正确。
 二、尝试解决:
 1)setup->Timezone configuration->  Asia/Shanghai保存后,发现由原来时间的CST时间变成了UTC时间,乱套了clock w调整下硬件时间跟软件时间一致,无效
 2)tzselect命令调整后亦无效。
 3)查看/etc/localtime发现里面内容为空,于是删除掉,重新链接一个localtime文件过去ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
之后再查看该文件亦为空,调整时间失败。
 4)于是从其它线上正常的RHEL 4系统的localtime文件拷贝一份上传至该机器,date查看时间正常,于是设置crond查看下定时备份是否正常,由于当时未重启定时任务,这个导致自认为不正常。
于是开始尝试危险方法解决,重新安装glibc-2.3.4-2.41软件,当时曾想用高版本替换,考虑系统在线提供服务,需要使用相关so文件于是不尝试,也未尝试使用rpm -Vf修复,于是尝试过程中打开了一个tftp传送窗口,在后续的解决中起到了关键作用。
 三、罪恶的发生
 #rpm -e glibc-2.3.4-2.41 -nodeps删除包
 #rpm -Uvh glibc-2.3.4-2.41.i386.rpm 尝试安装包,提示下面错误
-bash: /bin/rpm: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
更严重的是ls vi chmod mount 之类的常规命令都无法使用,打开另一个shell登录窗口随即关闭。
由于机器做了远程登录限制,尝试vi去掉限制发现该命令无法使用,于是从另一相同系统中去拉/lib/ld-linux.so.2文件,发现此文件为软件链接,此文件链接至ld-2.3.4.so文件,找到此文件真的文件上传后使用chmod命令无法使用,开始郁闷了,于是想在linux传送的时候不会改变文件权限,于是想尝试用linux系统登录后传(其实这考虑是白搭的,一我不知道root密码,二那机器已无法登录了),尝试在看tftp有没有修改文件权限的功能。想当然后先点了最后一个属性发现没有更改项,失望了。正在绝望的时候在那xftp窗口再点下右键发现有一项是Change Permissions修改权限的,于是点开后把execute可执行权限给加上去了。加上使用ln -s命令发现此命令也无法使用,于是把ld-2.3.4.so本地的重命令为ld-linux.so.2上传后修改权限使用rpm -ivh glibc-2.3.4-2.41.i386.rpm 重装该包根据其提示把相关的so文件继续上传直至该命令可以装包了。
 四、装完glibc-2.3.4之后缓了一口气,幸好开着一个命令窗口跟一个文件传输窗口,还有就是没有影响机器应用软件的正常运行,于是又开始整时间了,date查看下当前时间为UTC的使用setup重设时区后恢复CST时间,此时生效,于是设置一个crond查看备份文件时间,间隔一分钟后发现文件没有按正常crond指定的执行。于是尝试重启了crond。至此问题解决。
在解决glibc跟rpm这些关键命令的时候需要警惕,最好是在上线应用前把这般问题解决。
 
glibc介绍请看 http://baike.baidu.com/view/1323132.htm