事故背景：

有一台机器装不上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/sysp_w_picpath/tmp，所以我就进入/mnt/sysp_w_picpath/tmp，发现lib64目录还在，然后我就mv /mnt/sysp_w_picpath/tmp/lib64 /mnt/sysp_w_picpath/，重启系统，正常进入。开森。

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

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

慌乱之中采取了网管的措施，重启，重启之后问题依旧，此时是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/sysp_w_picpath下 如果要到root环境下，运行 chroot /mnt/sysp_w_picpath 命令

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

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

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

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

命令后提示符为sh-4.1#

ls    显示为根目录的文件；

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

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