一场库文件的远程修复
系统环境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这些关键命令的时候需要警惕，***是在上线应用前把这般问题解决。
本文转自 qwjhq 51CTO博客，原文链接:http://blog.51cto.com/bingdian/291903
