近日突然发现，系统访问很卡，于是查看系统进程，发现有一个es用户占用了大量cpu
1、使用top 查看cpu 使用情况
使用top 查看cpu 使用情况，发现了大量的es 用户，但是这个并非我执行的，感觉有些奇怪了
2、删除关联的bash
使用ls -l 查看PID启动文件的路径
# ls -l /proc/$PID/exe
发现都是在usr/bin/bash 中，于是想都没想就把bash 删除了，然后kill 所有进程，再然后就是reboot 重启系统，心想这次该没问题了。
哪知，输入用户密码登录，又出现了登录界面，一直进入不了系统，这才恍然大悟，刚才删除了用户信息，现在是无法进行登录了！
心中突然一紧，这可怎么是好，安装了那么多应用在系统里面了；如今无法进入系统，该咋办？不可能重装了后再重新安装一次吧！这也太费事了呀，于是想到了进行系统修复
3、进入Rescue模式
选择Troubleshooting 进入
再进入Rescue a CentOS system
显然系统在检测时，提示了 /bin/sh No such file or directory
在界面我直接选择了3 进入shell 模式
使用 ls 查看当前目录
大家都知道我们在使用U盘引导进入Rescue模式下时这个目录并不是真实系统根目录，这个只是U盘里的一个用来进行引导安装的母系统罢了
那我们如何才能进入电脑中真正的系统呢！
在ls 后发现有个 mnt 目录， 而据说这个目录下的sysimage就是挂载电脑安装后的真实系统
4、使用chroot 切换系统更目录
使用chroot /mnt/sysimage/ 就能切换到真实系统的根目录下
chroot /mnt/sysimage/
然而并不顺利，直接提示了chroot: failed to run command '/bin/bash' : No such file or directory
这个看来不行呀！
突然想到，真实系统不是缺少了bash 吗？ 而目前的这个母系统有bash呀，直接拷贝进去不就得了
于是果断拷贝文件到mnt/sysimage中，拷贝完后再次使用chroot 进行目录切换，但是还是提示了同样的错误，WHAT?
5、使用ldd 查看so依赖文件
于是百度资料发现有可能是bash 所依赖的库文件丢失所致；于是使用ldd 命令查看相关的依赖文件
发现真还有不少，于是使用cp 将其一一考入
cp -rp /lib64/libtinfo.so.5 /mnt/sysimage/lib64
cp -rp /lib64/libdl.so.2 /mnt/sysimage/lib64
cp -rp /lib64/libc.so.6 /mnt/sysimage/lib64
cp -rp /lib64/ld-linux-x86-64.so.2 /mnt/sysimage/lib64
cp /bin/bash /mnt/syst=image/bin/
拷贝完毕后再执行chroot 切换终于成功了（心跳加速厉害）
6、恢复bash
我当初在删除前把bash 改名bash_wakuang并压缩保存到了opt，现在目前就是把他直接恢复到/usr/bin目录下即可，恢复完成后 输入exit 退出 Rescue 模式，系统重启，再次进入登录界面
再次输入用户和密码进行登录，终于进入到了系统，悬着的心终于可以放下了，特此记录警示自己linux 目录不可轻易删除，否则后果很严重