有办法：使用nohup命令（如nohup bash script.sh > log.out 2>&1 &）、screen工具（如screen -S name后执行命令，Ctrl+a+d分离，screen -r name恢复）或tmux工具实现SSH断开后程序继续运行并可重新连接查看。
还在SSH里？别关，立刻执行这三步
只要当前SSH连接没断，你就有机会抢救——这是唯一窗口期。此时ls、cp、vim全挂掉不是因为硬盘坏了，而是动态链接器找不到匹配的libc.so.6，所有命令都卡在加载阶段。
先确认你还“活着”：echo $? 应该能返回 0；再试试 pwd（部分 shell 内置命令可能仍可用）；如果连 pwd 都 segmentation fault，说明 libc 损坏极严重，得跳到下一节。
- 立刻执行：
cd /lib64（路径固定，不依赖 libc） - 查旧版库文件：
ls -l libc-*.so，找一个你原本系统的版本，比如libc-2.17.so - 用
sln（静态链接的 ln 替代品，不依赖 libc）重建软链：sln libc-2.17.so libc.so.6
sln 是救命工具，它编译时完全静态链接，不调任何 glibc 函数。CentOS/RHEL 系统自带，Debian/Ubuntu 需提前装 sysvinit-utils 包。
/lib64/libc.so.6 被删了或指向错误文件？直接替换
如果 ls -l /lib64/libc.so.6 显示 “No such file or directory”，或者指向一个根本不存在的路径（比如 libc-2.25.so），就说明软链接被破坏。这时候不能靠 ln -sf，因为 ln 本身已失效。
- 确认目标文件存在：
ls /usr/lib64/libc-2.17.so或/lib64/libc-2.17.so（路径因发行版而异） - 用
cp（如果还能用）或cat > /lib64/libc.so.6（配合dd更稳妥）写入正确版本 - 更可靠的做法：
dd if=/usr/lib64/libc-2.17.so of=/lib64/libc.so.6 bs=4096
注意：不要用 mv 或 rm，它们大概率已不可用；dd 是内核级操作，只要系统没 panic 就能跑。
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
SSH 登录后秒退？LD_PRELOAD 是临时拐杖
现象是输入密码后立即断开，journalctl -u sshd 看不到日志——说明 sshd 进程启动后，在调用 glibc 初始化函数时崩溃。这不是配置问题，是 libc 版本错配。
- 在 SSH 客户端连接时加环境变量：
ssh -o "SetEnv=LD_PRELOAD=/lib64/libc-2.17.so" user@host - 如果客户端不支持
SetEnv，改用：ssh user@host 'LD_PRELOAD=/lib64/libc-2.17.so bash' - 进系统后第一件事：
export LD_PRELOAD=/lib64/libc-2.17.so，再执行后续修复命令
LD_PRELOAD 会让动态链接器优先加载指定库，绕过损坏的 libc.so.6。但它只是临时方案，不能解决 chroot、systemd 启动等深层问题。
彻底修复必须 chroot，但得先挂对分区
软链接修好后，ls、rpm 可能恢复，但图形界面、systemd 服务仍起不来——因为 /usr/lib64/libpthread.so.0、/lib64/libdl.so.2 等其他库也指向了错误版本。这时必须进入真实根环境重装 glibc。
- 先确认根分区：
cat /proc/mounts | grep " / " | awk '{print $1}'（用awk因为grep可能失效） - 挂载：
mount /dev/sda2 /mnt（假设根在 sda2） - 关键三步挂载：
mount -t proc proc /mnt/proc、mount --rbind /dev /mnt/dev、mount --rbind /sys /mnt/sys - chroot：
chroot /mnt /bin/bash，然后yum reinstall glibc或rpm -Uvh --force --nodeps /mnt/Packages/glibc-*.rpm
最容易漏的是 --rbind 而非 -o bind：/dev 下的 pts、shm 等子目录必须递归挂载，否则 chroot 里 bash 启动失败。
