误删关键系统文件后应立即冻结终端并用lsof+L1找回被删但仍在内存中的文件；修复fstab错误需进emergency模式重挂根分区为可写；sudoers损坏须进recovery模式恢复权限为440的最小配置。
误删关键系统文件后如何紧急止血
发现 rm -rf /usr/bin 或 rm -f /etc/passwd 这类操作刚执行完，第一反应不是重装，而是立即冻结当前终端、避免子进程继续破坏。Linux 内核仍保有已删除但未关闭的文件句柄，只要进程没退出，文件内容还在内存里。
- 立刻用另一个终端（或 SSH 会话）执行
lsof +L1查看被删除但仍被进程占用的文件，重点关注init、bash、sshd等核心进程的txt或mem类型句柄 - 若
/bin/bash被删但当前 shell 还能运行，可直接用cp /proc/$(pidof bash)/exe /tmp/bash-recover复制回原路径（需 root 权限） - 不要尝试
touch /etc/passwd后 chmod，空文件会导致login: Permission denied—— 正确做法是先从/usr/share/doc/adduser/examples/adduser.conf或其他机器同步基础用户配置，再用getent passwd检查是否可读
systemctl disable 导致服务无法启动的修复路径
systemctl disable nginx 本身不删文件，但若后续又手动删了 /etc/systemd/system/nginx.service 或改了 WantedBy= 目标单元，服务就会彻底失联。重点不是“启用”，而是确认 unit 文件是否存在且语法合法。
- 检查 unit 文件是否残留：
systemctl list-unit-files | grep nginx，若显示disabled但无文件路径，说明已被删 - 从包管理器重建：
rpm -ql nginx | grep service（CentOS/RHEL）或dpkg -L nginx-core | grep systemd（Debian/Ubuntu），然后systemctl daemon-reload - 若原 unit 文件已丢失且无包源，可用
systemctl cat nginx查看是否缓存了旧定义；没有则需按官方文档手写最小化 unit，注意Type=forking和PIDFile=必须匹配实际 Nginx 配置
fstab 错误导致 reboot 后卡在 emergency mode
编辑 /etc/fstab 时多写了一个空格、挂载点路径不存在、或 UUID 写错，都会让 systemd 在启动阶段 fallback 到 emergency shell。此时不能靠 SSH 登录 —— 必须进单用户模式修复。
