这条路径解决什么
当系统启动到一半卡住，或服务大面积异常、多用户模式下无法正常操作时，可以切到 rescue.target（对应传统 runlevel 1 的单用户模式）做最小化维护：它只挂载本地文件系统、只拉起基础单元，不进入多用户业务。emergency.target 更极端，基本不挂载根以外的文件系统、也不启动服务，直接给一个 root 救援 shell，用于根分区或 fstab 严重损坏的场景。
基本信息
| 适用平台 | Linux（systemd） |
|---|---|
| 进入方式 | 运行中 systemctl rescue；启动阶段在内核参数加 systemd.unit=rescue.target；或在引导菜单里选救援条目 |
| 退出方式 | systemctl isolate multi-user.target 或直接 reboot |
| 前置条件 | 需要 root 口令（救援 shell 会要求认证） |
| 常用动作 | systemctl --failed、journalctl -xb、文件系统检查与修复 |
典型使用场景
- fstab 写错导致启动卡住：进 rescue 后修正，再用 findmnt --verify 自检
- 根分区元数据异常：进 rescue 卸载后做文件系统检查
- 服务互相拖死：只拉起基础单元，逐个手工启动定位元凶
- 误改关键配置：用救援模式改回，避免正常模式下被其他服务干扰
- 忘记 root 口令：借助内核参数或引导条目进入维护 shell 重置
进入与退出
进入与退出
systemctl rescue # 运行中切换，会要求 root 口令
systemctl get-default # 确认默认目标仍是多用户模式
systemctl isolate multi-user.target # 修复完成后先切回多用户验证
reboot # 重启做最终的完整验证救援模式常用动作
救援模式常用动作
systemctl --failed # 列出失败单元
journalctl -xb -p err | tail -n 50 # 本次启动的错误日志
findmnt --verify -F /etc/fstab # 校验 fstab 是否可解析
fsck -f /dev/sdb1 # 数据盘检查：确认该盘已卸载
mount | grep '/data' # 确认没有残留挂载再动手两种救援目标对比
| 维度 | rescue.target | emergency.target |
|---|---|---|
| 挂载情况 | 挂载 fstab 里的本地文件系统 | 基本只挂载根，其余不挂载 |
| 启动的服务 | 拉起基础与必要单元 | 几乎不启动任何服务 |
| 适用场景 | 单用户维护、服务排障 | 根分区或 fstab 严重损坏 |
| 进入方式 | systemctl rescue 或内核参数 systemd.unit=rescue.target | systemctl emergency 或内核参数 systemd.unit=emergency.target |
远程 isolate rescue 会断开 SSH 会话：必须提前确认带外通道（IPMI、云控制台、虚拟机控制台）可用。另外 rescue shell 要求输入 root 口令，如果 root 被锁定或口令丢失，需要改用内核参数 init=/bin/bash 或 rd.break 之类的方案，而那是另一套更危险的操作。
救援模式下不要急着启动全部服务：先用 systemctl --failed 与 journalctl -xb 看清失败原因，修好一处再验证一处。做完后 isolate 回 multi-user.target 或重启完整验证，只有重启都没问题才算真正修好。
如果系统已经起不来，日志要在别处看：能进救援模式就用 journalctl -xb 看本次启动，起不来时用 journalctl --list-boots 列出历史启动并回看上一次的记录，或用另一台机器挂载这块盘取证。动手前把信息留全，避免反复重启把现场冲掉。