答案是libc.so.6软链接被误删导致动态链接失效。系统仍在运行，但ls、cp等依赖glibc的命令因找不到libc.so.6而报“no such file or directory”；此时可用cd、echo等shell内置命令，通过ld_preload指定真实libc库（如/lib64/libc-2.17.so）强制执行ln重建软链接。
能恢复，但必须在 SSH 会话未断开前操作；一旦断连或重启，只能进救援模式。
为什么 ls、cp 等命令突然报 “No such file or directory”
这不是文件真丢了，而是所有动态链接的二进制程序（包括 ls）启动时找不到 libc.so.6 这个入口软链接，无法加载真正的 glibc 实现（比如 libc-2.17.so）。系统还在运行，只是“嘴被堵住了”。cd、echo、export 这类 shell 内置命令还能用，因为它们不依赖外部库。
-
libc.so.6本身只是个软链接，真实库文件（如libc-2.17.so）通常还在/lib64/或/lib/目录下 - 用
ls /lib64/libc*+ Tab 补全，就能看到现存的真实库名 - 别试
ln -s直接重建——它自己也依赖 libc，会失败
用 LD_PRELOAD 强制加载真实库再重建链接
这是黄金抢救期最可靠的单步方案：绕过缺失的软链接，手动指定一个可用的 libc 实现，让 ln 命令跑起来。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 先确认真实库路径：
ls /lib64/libc-*.so（常见如libc-2.17.so、libc-2.28.so） - 执行完整命令（注意路径和库名要匹配）：
LD_PRELOAD=/lib64/libc-2.17.so ln -sf /lib64/libc-2.17.so /lib64/libc.so.6 - 如果提示
cannot open shared object file，说明选的库版本不兼容，换另一个试试（比如libc-2.28.so） - 成功后立刻测试：
ls、ps应该恢复正常
如果 SSH 已断开或系统无法启动怎么办
这时只能靠外部介质进救援环境，因为所有标准命令都失效了，busybox 也不一定存在或可用。
- 用同版本系统 ISO 制作启动 U 盘（如 CentOS 7 ISO），开机从 U 盘启动
- 选择 “Troubleshooting” → “Rescue a CentOS system”（Ubuntu/Debian 类似，选 “Rescue mode”）
- 等待挂载完成，原系统根目录通常在
/mnt/sysimage - 执行：
chroot /mnt/sysimage，然后ln -sf /lib64/libc-2.17.so /lib64/libc.so.6 - 退出、重启，系统即可恢复
最容易被忽略的一点：不同发行版路径差异很大——CentOS/RHEL 用 /lib64/，Debian/Ubuntu 可能在 /lib/x86_64-linux-gnu/；误删后别凭记忆硬写路径，一定要先用 ls /lib* + Tab 确认真实位置。
