误删关键系统文件后应立即冻结终端并用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 登录 —— 必须进单用户模式修复。
- 重启时在 GRUB 菜单按
e，找到以linux开头的行，在末尾加systemd.unit=emergency.target，Ctrl+X 启动 - 输入 root 密码后，先运行
mount -o remount,rw /把根分区重新挂为可写（默认 emergency 模式下是只读） - 用
blkid核对设备 UUID，用lsblk确认挂载点是否存在，再用vi /etc/fstab注释掉问题行（别删！加#即可） - 修复后必须执行
systemctl daemon-reload，否则下次启动仍读旧缓存
误改 sudoers 权限或语法错误引发权限锁死
visudo 虽能语法检查，但若手动用 vi /etc/sudoers 修改后保存，一个多余的 % 或缩进错误就会让所有 sudo 命令报 parse Error in /etc/sudoers near line X，且无法再用 visudo 打开。
- 不要试图用普通用户执行
pkexec visudo—— 多数服务器禁用 polkit，且该命令依赖 sudo 本身 - 唯一可靠方式是进 recovery mode：GRUB 中选 “Advanced options → Recovery mode → root shell”，然后
mount -o remount,rw / - 用
cp /etc/sudoers.d/README /etc/sudoers快速恢复最小可用配置（该文件通常保留基本语法结构），再逐行补回必要规则 - 验证：退出 recovery 模式前，先执行
sudo -n true测试免密执行是否成功，避免重启后再次锁死
最常被忽略的是：所有恢复操作完成后，必须确认 /etc/sudoers 权限为 440、所有 /etc/sudoers.d/* 文件权限为 440 且属主 root —— 权限不对照样拒绝加载。