码迷,mamicode.com
首页 > 其他好文 > 详细

生产事故:误删/lib64,移走/lib64目录

时间:2016-12-06 23:32:15      阅读:937      评论:0      收藏:0      [点我收藏+]

标签:误删/lib64 移动/lib64 /boot分区 linux修复模式

事故背景:

有一台机器装不上nagios监控,yum install openssl报一个关于“libkrb5.so.3”冲突的错误。

解决过程:

1./lib64事故

关于“libkrb5.so.3”冲突的错误,查了一些文章没有解决,就想着把libkrb5卸掉,rpm -e libkrb5.rpm,卸载有关联冲突,然后就rpm -e libkrb5.rpm --nodeps(事实证明,如果不清楚软件的依赖,最好不要“--nodeps”),一卸载就发现问题了,发现yum命令用不了了,提示缺少“libkrb5.so.3”,然后我就从别的机器上拷贝了一个libkrb5.so.3到这台机器上,然后yum继续提示少别的文件,经验告诉我,这可能还缺少别的很多库文件,由于是生产的机器,我不想花太多时间整,所以就想着从别的机器上拷贝/lib64到这台机器,想着想着,手就不由自主的敲了个“mv /lib64 /tmp”,敲完我就后悔了,赶紧“ls”,发现用不了了,然后发现只有cd命令能用,其他的都用不了,这个时间点大概是15:00,说实话,有点慌,因为生产上没有遇到过这种事,在虚拟机上试过“rm -rf /”能删,但是也没恢复过。

2.模拟并处理/lib64事故

想了一分钟,决定在虚拟机上模拟这个事故,打开虚拟机,然后mv /lib64 /tmp,重启,进不去系统,一直卡在开机界面。然后就开始搜索“误删/lib64”的相关文章,几乎没找到有用的,可能是因为这个事故确实比较少,生产中没人会这么做,实验的话可能也不会做这个。没搜到“误删/lib64”的文章,但是有个文章的“linux修复模式”提醒了我,心想:我可以先进了系统,然后把/tmp目录下的lib64拷贝回/根目录,这样不就解决问题了吗。

然后我就在虚拟机上试验,进入linux修复模式下后,发现/tmp目录下的文件被删了,然后就想到/tmp目录下的文件是不是重启后自动删除了,然后我就把光盘镜像系统里的/lib64拷贝到崩溃的系统根目录下,重启系统,依旧不行,这可能是依旧缺少什么库文件导致的系统起不来。

很着急很着急,因为现在我误认为/tmp/lib64这个目录在重启系统后就被删除了,而且镜像里的/lib64拷贝到崩溃系统里也是不起作用的,没办法了,我只能想着把系统里的东西导出来,这是一台发布机器,深圳那边的同事专门用来发布代码的,恰巧当天晚上就要用。

大概17:00左右,我联系深圳那边同事:勇哥,那台发布机器被我搞崩了,想问问你重要的文件是不是集中存放在哪,我试试能不能拷贝出来。联系之后,我基本已经做好了将文件拷贝出来的准备。

17:30,脑子里突然想到,进入了linux修复模式后,奔溃系统的tmp目录不是/tmp,而是/mnt/sysimage/tmp,所以我就进入/mnt/sysimage/tmp,发现lib64目录还在,然后我就mv /mnt/sysimage/tmp/lib64 /mnt/sysimage/,重启系统,正常进入。开森。

3.处理生产上的/lib64事故

然后我就在vCenter的存储上上传了一个iso镜像(存储上没有镜像,我们新装机是走cobbler),可恶,上传镜像花了半小时。。这时候已经18:30了,我是有多紧张,20:00就要用这个机器,这个事经理还不知道。。。然后就设置BIOS开机光盘启动,选择存储,前两次因为选错了存储导致没光盘启动,后来选对了存储也还进不去,试了三四次都进不去,我慌了,这是什么问题呢,难道镜像有问题?没理由啊,拷贝没报错。我就查,查查查,么查到,后来有个人一句话点醒我了:光盘启动的话,如果你没有勾选“开机启动”的话,那就别往下看了。。突然想到,我选了镜像但是没有勾选“开机自动挂载”,可不就进不去嘛,真是忙中出错。一切都处理好了,进入了系统,然后mv /mnt/sysimage/tmp/lib64 /mnt/sysimage/,重启,正常进入系统了,但是又有新问题了:密码明明是正确的,但是提示密码不正确。

慌乱之中采取了网管的措施,重启,重启之后问题依旧,此时是19:00,经理走了,大多数同事都走了,没人知道我正在处理一个线上事故。。。说实话,这时候我心里怕了,我怕一步一个错,但是我分析着既然系统都进去了,单用户模式应该没问题,改改密码吧,然后就把系统密码改成123456,重启后,正常进入系统了,发现一切都正常,没问题了吧。。。然后我远程连接这台机器,提示超时,回到vmware上,发现系统的sshd服务没起,查看了这个服务是开机启动的,然后我就手动起,提示少“libkrb5.so.3”,等于这个libkrb5.so.3库文件不仅影响了yum,还影响了ssh服务,然后我就又进入linux的修复模式,将镜像里的libkrb5.so.3拷贝到系统,进入系统后启动sshd服务正常,远程连接也行了,但是又有新问题了,只能用root用户,切普通用户就卡死,这又是什么问题呢?难道是堡垒机后遗症(公司用着堡垒机呢,出事故后我就把这台机器从堡垒机上下了)?然后我就把sshd.config里的关于堡垒机的配置都清空了,还是不行。如果只能连接不能切用户,深圳那边的用户发布代码还是有问题的,所以这个问题必须解决,但是没有思路啊。

4.彻底恢复

不能没有思路就不干啊,最起码把能干的先干了。把这台机器加到堡垒机吧,然后再说,不得不说付费的东西就是好用,也不知道什么原理,把这台机器加到堡垒机后,就能正常切用户了,这时候已经是20:00多了(代码因为一些原因延迟发布了),然后我赶紧联系深圳用户,让他看看正常吗,他回复正常,可算松了一口气。。。


类似事件:

这个事故出现后不久,又有一台数据库因为更换磁盘导致系统起不来了,做的raid10,更换了一块磁盘,然后系统就崩了(事后分析是raid卡故障导致)。挂载镜像,进入linux修复模式,系统有五六个分区,不知道问题出在哪个分区,就挨个挂载,发现/boot分区不能挂载,进入/boot分区,发现是空的,也就是说/boot分区文件丢失,查了查资料,说是重装kernel可以解决,然后就重装kernel,事实发现不行,然后就从别的机器上拷贝/boot分区内容到崩溃的机器,重启机器后,不像之前直接进入grub界面了,但是读完系统进度条后就卡死了,可见还是有问题。这台数据库上部署的3M高可用应用,为了快速解决这个问题,选择了重装系统并重新部署3M应用。


在此提醒:

1、生产上操作虽然需要手速,但是回车别急着敲。

2、尽量别用rm命令,用mv替代。

3、不确定能处理好的事故,在处理了一段时候后最好上报,不然会特别特别尴尬,不上报吧可能处理不好,上报吧又觉得这么晚才报有点2逼。


linux进入修复模式:

救援模式有什么作用

◆可以更改root密码;

◆恢复硬盘、文件系统操作;

◆系统启动不来的时候,只能通过救援模式来启动;

救援模式启动的步骤如下:

1、首先开机进入BIOS设置(每台电脑进入bios的方法不同根据自己的电脑进入),BOOT启动顺序为光盘优先启动 CD-ROM Drive 使用小键盘的+ -号调整上下顺序;设置好后保存并退出。

如果是vmware workstation,可以“虚拟机→电源→开机进入固件”进行设置BIOS;

如果是物理机,直接F1 F2 F12什么的进入BIOS,各有不同,看提示;

如果是exsi,右键虚拟机,点编辑,先挂载了镜像,然后修改开机启动到BIOS界面即可。

技术分享

2、重启系统后进入安装启动菜单,上下键移动到Rescue install system 救援安装系统;

技术分享

3、选择语言,保持默认English

技术分享

4、选择键盘类型,保持默认us

技术分享

5、是否启动网络,需要根据你实际情况进行选择,如果需要通过联网拷贝数据,选择YES,在这里我们选择NO;

技术分享

6、进入到Rescue界面,选择Continue

技术分享

7、本地系统挂载在/mnt/sysimage下 如果要到root环境下,运行 chroot /mnt/sysimage 命令

技术分享

8、三种选项:shell 进入命令行模式;fakd是诊断模式;reboot重启电脑;我们这里选择shell

技术分享

9、进入shell命令行,提示符为bash-4.1#

ls /mnt/sysimage/ 显示挂载的目录为根目录的文件

执行chroot /mnt/sysimage/ 将/mnt/sysimage/目录下的文件移动到根目录;

命令后提示符为sh-4.1#

ls    显示为根目录的文件;

技术分享

事实上,缺少系统文件会导致“chroot /mnt/sysimage”出错,查也查不出来什么,因为不管缺什么都是统一的错误提示“/bin/bash。。。。”,像我上面缺少/lib64目录、缺少/boot下的文件,在“chroot /mnt/sysimage”时都会报错,而且报错一样。。。可以不理会这个命令,你干啥干啥,该修改文件修改文件,该拷贝目录拷贝目录,不影响。

10、在sh-4.1#模式下需要先exit退出,回到bash-4.1#才可以reboot重启系统;

技术分享



生产事故:误删/lib64,移走/lib64目录

标签:误删/lib64 移动/lib64 /boot分区 linux修复模式

原文地址:http://10546390.blog.51cto.com/10536390/1880013

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!