记某同事的两次误操作导致Linux瘫痪

我有一个同事, 有两次在项目组服务器上误操作, 差点导致整个Linux服务器报废

第一次问题:

问题复现:

1. 在/data/hadoop 下有一个usr的目录, 为垃圾目录(rpm包解压后产生的)

2. 同事想 删除 ./usr, 但是还好没用 rm -rf, 而是用的 mv /usr /tmp

   注意, ./usr 被打成了 /usr, 导致核心目录 /usr 移到了 /tmp/usr

3. 再使用 ls、vim、cat 都发现命令用不了了， 只有原生的 cd、pwd、export 这些命令才能用

   但是按 Table 键还是可以补全的来 代替 ls

   

4. 你肯定想着，用上 绝对路径 是不是就ok了？

   不，不行，会报 /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory 的错误

   

5. 那 export /tmp/usr/bin 到 PATH 环境变量呢?

   照样不行, 这样会和用 绝对路径 的方法 报同样错误

   

6. 更恐怖的, ssh命令也用不了, 意味着现在不能使用新的 XShell 重新连接到服务器了,

   

   一旦你现在已经连上的 Xshell 也断开连接了, 那就再也连不上 Linux 了,

   公司的 VPN 有最大连接时长限制, 况且当时同事是 先连公司wifi 再连公司VPN 再连访问谷歌的VPN, 这三者串联, 只要任一处断了, 那就再也连不上 Linux 了,

   就只能去某个山洞里的机房才能操控 Linux 物理机了

解决办法：

• 报错 /lib64/ld-linux-x86-64.so.2 找不到是因为 /lib64软链接指向了 /usr/lib64, 但现在 /usr都被移动了, 那么 lib64 肯定也被移动了, 则软链接失效

使用这个命令：

# ld-linux-x86-64.so.2的全路径
# --library-path 指定 lib64 库的位置
# mv的全路径
# 把 /tmp/usr 移动到 / 下
/tmp/usr/lib64/ld-linux-x86-64.so.2   --library-path   /tmp/usr/lib64   /tmp/usr/bin/mv   /tmp/usr   /

然后恢复之前的 PATH 变量, 一切均恢复正常

第二次问题:

同事想 rm -rf /opt/sqoop,

却不小心多打了一个空格 打成了 rm -rf /opt /sqoop,

结果导致整个/opt目录全被删了

经验总结:

在删除文件时, 千万别用 rm, 那样一旦误操作就完了; 但如果是 mv 误操作的话, 或许还可以抢救一下

可以建立一个 /tmp/trash, 以后用 mv 1.txt /tmp/trash 代替 rm -rf 1.txt

等到很久后 /tmp/trash 很大了, 再仔细用 rm 清理下 /tmp/trash

其他:

> 也要慎用, > 是覆盖某个文件, 一旦误操作了 那么旧文件内容就没法恢复了