直接用 systemd-analyze time 可查看 kernel、initrd、userspace 三阶段耗时，精准定位瓶颈；需配合 blame --all --no-pager 查 activating/failed 的 .mount 单元，再用 critical-chain 分析真实依赖路径。
直接用 systemd-analyze 系列命令就能完成引导日志分析和启动耗时诊断，无需安装额外工具，所有 systemd 系统（Ubuntu 16.04+、CentOS 7+、Debian 9+ 等）都自带。
看总耗时和瓶颈在哪一阶段
运行：
systemd-analyze time
输出类似：
Startup finished in 718ms (kernel) + 1.713s (initrd) + 17.079s (userspace) = 19.511s
- kernel：从内核第一条指令到 systemd 进程（PID 1）创建完成；超 1s 要查 BIOS Fast Boot、NVMe 驱动是否内置、Secure Boot 是否引发验证延迟
-
initrd：仅启用 initramfs 时存在，含加密卷解锁、LVM 扫描等；高耗时常见于
/etc/crypttab配置了交互式密码，或内核参数误加rd.md=0导致 RAID 初始化失败 -
userspace：systemd 加载所有 unit 的总耗时；若占比超 80%，说明问题在服务层，下一步必须进
blame
注意：该命令不包含 BIOS/UEFI 自检、GRUB 菜单停留、内核解压等前置时间，只反映 systemd 接管后的可测部分。
找真正拖慢启动的服务和挂载单元
默认的 systemd-analyze blame 只显示已成功激活（active）的 service 和 mount 单元，但卡住启动的往往是那些状态为 activating 或 failed 的单元。
务必使用：
systemd-analyze blame --no-pager --all
-
--all：强制列出所有已加载 unit，包括 failed、activating、inactive 状态 -
--no-pager：防止终端截断长名（尤其 UUID 命名的设备，如dev-disk-by\x2duuid-1234567890abcdef.mount） - 重点关注耗时 ≥ 500ms 的条目，特别是：
NetworkManager-wait-online.service（常因 DHCP 或 IPv6 RA 等待卡住）、docker.service（镜像扫描阻塞）、各类.mount单元（检查/etc/fstab是否漏写nofail或x-systemd.timeout=5）
查真实依赖路径，识别“被拖累”的环节
systemd-analyze critical-chain 展示的是从启动起点到 default.target（或 graphical.target）的最长依赖路径，每一步的时间是该 unit 自身启动耗时，不包含上游等待时间。
例如输出：
● default.target
└─multi-user.target
└─sshd.service
└─network-online.target
└─NetworkManager-wait-online.service
- 如果链条末端显示
+12.3s，但systemd-analyze blame显示该服务只花了 0.2s，说明它自己很快，只是上游依赖（比如网络未就绪）让它干等了 12 秒 - 此时应配合日志确认：运行
journalctl -u NetworkManager-wait-online.service -b，查找Timed out waiting for connectivity类提示
结合日志定位具体错误原因
关键命令组合：
-
journalctl -b：查看本次启动的完整 systemd 日志 -
journalctl -b -1：查看上一次启动日志（用于对比异常前后） -
dmesg -t | head -20：看内核日志起始时间戳，对比systemd-analyze time中的 firmware/loader 阶段 -
journalctl -u xxx.service -b：针对某服务查详细启动过程（如journalctl -u docker.service -b | grep -i "start\|timeout"）
常见线索：
-
/etc/fstab中有带_netdev却没加nofail的 NFS 条目 → 启动卡在挂载 - 主机名解析失败（
hostname输出名不在/etc/hosts中）→ SSH、Postfix 等服务 DNS 超时卡住 - 出现
dev-disk-by\x2duuid-xxx.device在 blame 列表中 → 瓶颈在内核或 initramfs 阶段，需检查 initramfs 大小、磁盘 UUID 是否一致
