Linux启动卡在某服务说明已进入systemd用户空间阶段,需定位卡点、分析原因并修复;可切TTY登录后用systemd-analyze blame/critical-chain排查耗时服务,禁用NetworkManager-wait-online等高频卡点服务,或通过GRUB添加systemd.unit=multi-user.target等参数跳过问题服务。

Linux 启动卡在某个服务,说明系统已进入 systemd 用户空间阶段,但该服务启动失败或长时间无响应。关键不是“进不了系统”,而是“卡在哪、为什么卡、怎么绕过或修复”。
确认是否真卡住,还是只是慢
有些服务(如网络等待、远程挂载、LUKS 解密)本身耗时较长,屏幕没刷新不代表死机。可尝试:
- 按 Ctrl + Alt + F2~F6 切换到 TTY 终端,看能否登录;能登录说明 systemd 已就绪,只是默认目标被阻塞
- 登录后运行 systemd-analyze blame,查看各服务启动耗时(单位 ms),重点关注超过 5000ms 的条目
- 用 systemd-analyze critical-chain 查看从 default.target 到卡点的完整依赖链,定位瓶颈路径
常见卡点服务及快速处理
以下服务在实际环境中高频导致卡顿,禁用或屏蔽后常能立即恢复启动:
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI,零 GUI 开销。
-
NetworkManager-wait-online.service:默认等待网络连通 90 秒。网线未插、DHCP 延迟或 DNS 不可达都会卡住。临时解决:
sudo systemctl disable NetworkManager-wait-online.service -
bluetooth.service:老旧蓝牙芯片或驱动异常易 hang。建议屏蔽:
sudo systemctl mask bluetooth.service(比 disable 更彻底) -
lvm2-monitor.service / mdmonitor.service:LVM/RAID 监控服务在磁盘响应慢或离线时卡住。先检查物理磁盘:
sudo smartctl -a /dev/sdX,再决定是否禁用 -
remote-fs.target 相关服务(如 nfs-client.target、cifs-mount@xxx.service):远程挂载失败时会重试多次。检查
/etc/fstab对应行,临时注释并运行sudo mount -a测试是否报错
不改配置也能先进系统
重启时在 GRUB 菜单按 e 编辑启动项,在 linux 行末尾添加参数:
-
systemd.unit=multi-user.target:跳过图形界面,直接进入命令行环境 -
systemd.unit=rescue.target:进入最小化救援模式(需 root 密码) -
systemd.mask=xxx.service:强制屏蔽指定服务(如systemd.mask=NetworkManager-wait-online.service)
进系统后,用 journalctl -u xxx.service -b 查看该服务本次启动日志,重点搜索 failed、timeout、Connection refused 等关键词。
检查底层依赖是否异常
服务卡住往往因上游依赖未就绪,而非服务本身问题:
- DNS 失效:检查
/etc/resolv.conf是否指向可用 DNS(如nameserver 114.114.114.114) - 网络设备未识别:运行
ip link和nmcli dev status确认网卡状态 - 加密卷未解锁:若使用 LUKS,确认 keyfile 或密码输入环节是否被跳过或超时
- fstab 中设备 UUID 错误或设备不存在:用
lsblk -f和blkid核对分区标识

















