记某同事的两次误操作导致Linux瘫痪
我有一个同事, 有两次在项目组服务器上误操作, 差点导致整个Linux服务器报废
第一次问题:
问题复现:
-
在/data/hadoop 下有一个usr的目录, 为垃圾目录(rpm包解压后产生的)
-
同事想 删除 ./usr, 但是还好没用 rm -rf, 而是用的 mv /usr /tmp/trash
注意, ./usr 被打成了 /usr, 导致核心目录 /usr 移到了 /tmp/usr
-
再使用 ls、vim、cat 都发现命令用不了了， 只有原生的 cd、pwd、export 这些命令才能用
但是按 Table 键还是可以补全的来 代替 ls
-
你肯定想着，用上 绝对路径 是不是就ok了？
不，不行，会报
/lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory的错误
-
那 export /tmp/usr/bin 到 PATH 环境变量呢?
照样不行, 这样会和用 绝对路径 的方法 报同样错误
-
更恐怖的, 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 -r /opt/sqoop,
却不小心多打了一个空格 打成了 rm -r /opt /sqoop,
结果导致整个/opt目录全被删了
经验总结:
在删除文件时, 千万别用 rm, 那样一旦误操作就完了; 但如果是 mv 误操作的话, 或许还可以抢救一下
可以建立一个 /tmp/trash, 以后用 mv 1.txt /tmp/trash 代替 rm -rf 1.txt
等到很久后 /tmp/trash 很大了, 再仔细用 rm 清理下 /tmp/trash
其他:
> 也要慎用, > 是覆盖某个文件, 一旦误操作了 那么旧文件内容就没法恢复了