误删/lib64/libc.so.6后系统“失语”，须在SSH连接存活的黄金窗口期内修复：先用TAB补全确认真实glibc库文件（如libc-2.17.so），再用sln命令重建libc.so.6及ld-linux-x86-64.so.2、libm.so.6三个软链接，最后验证which ls && ls --version。
当你在银河麒麟系统中误删或损坏/lib64/libc.so.6软连接时，ls、cp、rm等几乎所有命令立即失效，SSH会话虽未断开但无法执行新指令，系统进入“失语”状态——此时必须在当前连接存活的黄金窗口期内完成修复。
确认当前glibc可用版本
执行 ldd --version 查看glibc主版本号，例如输出为 ldd (GNU libc) 2.17；若该命令报错，则改用 echo $LD_PRELOAD 检查是否已有临时加载路径。
进入 /lib64 目录后，连续按两次 TAB 键触发bash自动补全，观察列出的文件中是否存在类似 libc-2.17.so 或 libc-2.28.so 的真实库文件——【这个真实存在的 .so 文件名就是你唯一能用的恢复依据】。
注意：不要依赖 ls 命令输出，它此时已不可信；TAB补全是当前环境下最可靠的文件枚举方式。
用sln命令重建libc.so.6软链接
方法一：直接使用系统自带的 sln 工具（不依赖libc.so.6）
执行：sln /lib64/libc-2.17.so /lib64/libc.so.6（将其中 2.17 替换为你上一步确认的真实版本号）
这一步成功后，ls、pwd 等基础命令应立刻恢复正常。若仍报错，请检查是否输错了真实库文件名，或该文件权限被意外修改为不可读。
同步修复其他关键软链接
仅恢复 libc.so.6 不足以让全部命令稳定运行，还需重建以下两个关联软链接：
第一步：sln /lib64/ld-2.17.so /lib64/ld-linux-x86-64.so.2
第二步：sln /lib64/libm-2.17.so /lib64/libm.so.6
这两步顺序不能颠倒，因为 ld-linux-x86-64.so.2 是动态链接器入口，缺失会导致部分命令即使有libc也无法启动；libm.so.6 缺失则数学运算相关程序（如 bc、某些脚本）仍会失败。
执行完这三步后，运行 which ls && ls --version 验证是否完全恢复。
