systemd-analyze固件、引导器、内核、用户态各花了多久,一行看全。
约 1235 字大约 4 分钟
2026-05-14
按下电源到看到登录提示,中间发生了一长串接力:固件 → 引导器 → 内核 → systemd → 各个服务。平时不需要关心细节,但当一台机器“开不了机”或“开机特别慢”时,知道它卡在哪一棒,才知道该去查什么。
理解从固件、引导器、内核到 systemd 的启动接力,知道每一棒负责什么,开机异常时能定位到阶段。
systemd-analyze固件、引导器、内核、用户态各花了多久,一行看全。
systemd-analyze blame按耗时排序列出每个 unit,开机慢直接看榜首。
systemctl --failed列出没起来的 unit,开机后服务缺失先看这个。
journalctl -b-b 限定本次开机,从头复盘启动过程。
| 阶段 | 谁在跑 | 干什么 | 交接给 |
|---|---|---|---|
| ① 固件 | BIOS / UEFI | 自检硬件,找到启动盘 | 引导器 |
| ② 引导器 | GRUB | 显示启动菜单,加载内核到内存 | 内核 |
| ③ 内核 | Linux kernel | 初始化硬件驱动,挂载根文件系统 | systemd |
| ④ 用户态 | systemd(PID 1) | 按依赖启动所有服务,直到目标 target | 登录提示 |
每一棒只负责把系统带到一个状态,然后交给下一棒。排查“开不了机”,第一步就是判断卡在哪一棒:
日常运维里,①②③ 出问题的概率低(多半是硬件、误删内核、改坏 GRUB)。绝大多数“开机相关”的问题都在第 ④ 棒——systemd 启动服务这一段。两个高频场景:
开机变慢。用 systemd-analyze 看总耗时,再 systemd-analyze blame 看是哪个 unit 拖的。常见元凶是某个服务在等网络、等一个挂不上的网络存储(见 挂载与 fstab)。
服务没自启。开机后发现某服务没跑,先 systemctl --failed 看它是不是启动失败了,再 systemctl is-enabled 服务名 确认它到底有没有设开机自启——很多时候是根本没 enable(见 服务生命周期)。
/etc/fstab 里一个挂载项写错(UUID 错了、设备不存在又没加 nofail),systemd 在启动时会苦等这个挂载,最后把系统带进紧急模式(emergency mode),停在一个要求输入 root 密码的黑底界面。这不是“开不了机”,是 systemd 主动停下来等你处理。进去后 journalctl -b 往回翻,能看到是哪个挂载失败的。
改 GRUB、fstab、内核相关配置务必能回滚
启动链上的配置(/etc/fstab、/etc/default/grub、内核参数)一旦改错,代价是“下次开机进不去”,而且没法在系统里慢慢修。原则:① 改之前一定 cp 备份;② fstab 改完用 mount -a 验证(见 挂载与 fstab);③ 知道怎么从 GRUB 进救援模式、或用 Live USB 挂载根分区修复。别在唯一一台、不能停的机器上拿启动配置做实验。
| 误区 | 更稳妥的做法 |
|---|---|
| 一说“开机问题”就重装系统 | 先判断卡在四棒中的哪一棒,大多数是 systemd 阶段,可修 |
| 开机慢没头绪,凭感觉关服务 | systemd-analyze blame 按耗时排序,对着榜首查 |
| 服务没自启以为是 bug | 先 is-enabled 确认有没有 enable,再 --failed 看是否启动失败 |
| 改 fstab/GRUB 不留退路 | 改前备份、改后验证,并准备好救援模式的修复办法 |
版权归属:Shuo Liu