systemd-analyze blame 输出最上方服务即最可能拖慢启动的罪魁，按毫秒级耗时从高到低列出已激活 .service 单元，仅统计自身 execstart 时间；常见高耗时服务包括 networkmanager-wait-online.service、docker.service 等，需结合 critical-chain 分析依赖链定位真实瓶颈。

直接看耗时最长的服务，就是 systemd-analyze blame 输出最上面那几项。

快速定位拖慢启动的罪魁服务

执行命令后，系统会按毫秒级耗时从高到低列出所有已激活的 .service 单元：

• 打开终端，运行 systemd-analyze blame
• 重点关注耗时超过 2 秒的服务，例如 5.234s NetworkManager-wait-online.service 或 3.890s docker.service
• 注意：该命令只统计服务自身 ExecStart 的执行时间，不包含依赖等待或并行延迟
• 确保系统已完成一次完整启动，否则未运行的服务不会出现在结果中

识别常见高耗时服务类型

以下几类服务在实际环境中频繁成为瓶颈：

Browser Setup (No-Root Linux)

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

• 网络就绪等待类：如 NetworkManager-wait-online.service，常因 DHCP 超时或无网络连接卡住
• 容器平台类：如 docker.service、containerd.service，启动时需加载镜像、初始化存储驱动
• 自动维护类：如 apt-daily.service、snapd.service，会在启动阶段检查更新或刷新快照
• 硬件支持类：如 ModemManager.service、bluetooth.service，可能因设备响应慢或固件加载失败而延迟

结合 critical-chain 理清依赖关系

单看 blame 只知道“谁慢”，但不知道“为什么慢”。这时要用 critical-chain 查关键路径：

• 运行 systemd-analyze critical-chain 查看从 multi-user.target 回溯的最长依赖链
• 若想聚焦某服务，比如 docker.service，可运行 systemd-analyze critical-chain docker.service
• 输出中顶部是最后启动但最耗时的环节，底部是最早启动的前置依赖，整条链不可并行化，任一环节延迟都会拉长总启动时间
• 注意：该命令仅显示 active 状态的单元；被跳过（如 ConditionPathExists 不满足）或 disabled 的服务不会出现

验证与后续操作建议

确认问题服务后，可针对性处理：

• 临时禁用非必要服务：sudo systemctl disable --now NetworkManager-wait-online.service
• 调整超时策略（如对 wait-online）：sudo systemctl edit NetworkManager-wait-online.service，加入 TimeoutStartSec=10
• 延迟启动容器服务：sudo systemctl edit docker.service，添加 WantedBy=multi-user.target 并设置 ExecStartPre=/bin/sleep 5
• 检查日志确认原因：journalctl -u servicename --since "1 hour ago"