3. SysVinit串行启动机制
SysVinit 是 Linux 系统中最经典的初始化系统，其核心设计哲学是 确定性 与 顺序性。本章深入剖析 SysVinit 的串行启动机制，揭示 rc 脚本如何按严格顺序执行，以及这种设计在嵌入式系统中带来的性能瓶颈。
3.1 SysVinit 启动架构概览
SysVinit 的启动流程遵循一个清晰的层次结构：内核启动 init 进程后，init 根据 /etc/inittab 配置文件，依次执行一系列 rc 脚本，这些脚本按运行级别（Runlevel）组织，形成一条串行执行链。
3.2 rc 脚本顺序执行原理
SysVinit 的串行执行机制建立在 运行级别 和 脚本命名约定 之上。每个运行级别对应一个目录，目录中的脚本按文件名中的数字顺序依次执行。
3.2.1 运行级别与脚本目录
| 运行级别 | 对应目录 | 典型用途 | 嵌入式常见配置 |
|---|---|---|---|
| 0 | /etc/rc0.d | 关机 (Halt) | 关闭文件系统、停止服务 |
| 1 | /etc/rc1.d | 单用户模式 | 维护模式、文件系统修复 |
| 2 | /etc/rc2.d | 多用户模式 (无网络) | 基础系统服务 |
| 3 | /etc/rc3.d | 多用户模式 (有网络) | 网络服务、应用启动 |
| 4 | /etc/rc4.d | 用户自定义 | 特定应用场景 |
| 5 | /etc/rc5.d | 多用户模式 (图形界面) | 嵌入式 GUI 系统 |
| 6 | /etc/rc6.d | 重启 (Reboot) | 重启流程 |
| S | /etc/rcS.d | 系统初始化 (单用户) | 内核模块加载、文件系统挂载 |
3.2.2 脚本命名与执行顺序
每个 rc 目录中的脚本遵循严格的命名规则：
# 脚本命名格式
S<数字><服务名称> # 启动脚本 (Start)
K<数字><服务名称> # 停止脚本 (Kill)
# 实际示例
/etc/rc3.d/S01syslogd # 启动 syslogd，优先级 01
/etc/rc3.d/S10network # 启动网络，优先级 10
/etc/rc3.d/S20sshd # 启动 SSH 服务，优先级 20
/etc/rc3.d/K90network # 停止网络，优先级 90执行顺序由数字决定：
- 数字越小，执行优先级越高，越先执行
- S 脚本 按数字升序执行（S01 → S02 → ... → S99）
- K 脚本 按数字升序执行（K01 → K02 → ... → K99）
- 在同一目录中，所有 S 脚本执行完毕后，再执行 K 脚本
关键机制： 脚本实际上是指向 /etc/init.d/ 目录中实际脚本的符号链接。rc 脚本通过 start 或 stop 参数调用这些链接，实现服务的启动与停止。
3.3 启动依赖与串行执行模型
SysVinit 通过 数字编号 隐式表达依赖关系。开发者需要手动确保依赖服务的编号小于依赖它的服务编号。
3.3.1 依赖关系表达方式
3.3.2 依赖管理的问题
- 隐式依赖： 依赖关系仅通过数字编号表达，没有显式的依赖声明机制
- 人工维护： 开发者必须手动确保编号顺序正确，容易出错
- 循环依赖： 无法检测循环依赖，可能导致死锁或启动失败
- 缺乏并行性： 即使两个服务完全独立，也必须串行等待
嵌入式系统风险： 在资源受限的嵌入式系统中，依赖关系管理不当会导致启动失败。例如，如果文件系统服务 (S05mountfs) 的编号大于依赖它的应用服务 (S03app)，应用将在文件系统就绪前启动，导致崩溃。
3.4 串行瓶颈深度分析
SysVinit 的串行执行机制在嵌入式系统中引入了一系列性能瓶颈，直接影响系统启动时间。
3.4.1 主要瓶颈点
| 瓶颈类型 | 描述 | 典型耗时 | 影响程度 |
|---|---|---|---|
| I/O 等待 | 每个脚本等待磁盘 I/O 完成，无法重叠 | 50-500ms/脚本 | 高 |
| 设备探测 | 串行等待设备初始化完成 | 100-2000ms/设备 | 极高 |
| 网络协商 | 等待 DHCP 或链路协商完成 | 1-5s | 极高 |
| 文件系统检查 | fsck 串行执行，无法并行 | 1-10s | 极高 |
| 脚本启动时间 | 每个脚本的 fork/exec 开销 | 5-20ms/脚本 | 中 |
| 依赖等待 | 即使无依赖也必须等待前序脚本 | 累积效应 | 高 |
3.4.2 串行启动时间模型
SysVinit 的总启动时间可以用以下公式表示：
T_total = Σ(T_script_i) (i = 1 to N)
其中：
- T_total = 总启动时间
- T_script_i = 第 i 个脚本的执行时间
- N = 需要执行的脚本总数
由于串行执行，总时间等于所有脚本执行时间的累加和。3.4.3 实际案例分析
以一个典型的嵌入式 Linux 系统为例，分析串行启动的瓶颈：
3.4.4 串行瓶颈的量化分析
以下是一个 30 个脚本的嵌入式系统启动时间分解：
| 脚本类型 | 数量 | 平均耗时 | 总耗时 | 占比 |
|---|---|---|---|---|
| 文件系统相关 | 3 | 800ms | 2.4s | 30% |
| 网络相关 | 2 | 1500ms | 3.0s | 37.5% |
| 设备驱动 | 5 | 200ms | 1.0s | 12.5% |
| 系统服务 | 10 | 100ms | 1.0s | 12.5% |
| 应用服务 | 10 | 60ms | 0.6s | 7.5% |
| 总计 | 30 | - | 8.0s | 100% |
关键发现： 网络和文件系统相关的脚本虽然数量少（5/30），但占总启动时间的 67.5%。这些 I/O 密集型操作在串行模式下无法重叠，成为启动性能的主要瓶颈。
3.5 串行启动的局限性总结
SysVinit 的串行启动机制在嵌入式系统中面临以下核心挑战：
- CPU 利用率低： 在 I/O 等待期间，CPU 处于空闲状态，无法执行其他任务
- 启动时间线性增长： 每增加一个服务，启动时间线性增加
- 依赖管理脆弱： 依赖关系通过人工维护的数字编号表达，容易出错
- 缺乏动态调整： 无法根据硬件状态或系统负载动态调整启动顺序
- 调试困难： 启动失败时，难以定位是哪个脚本或依赖导致的问题
优化方向： 理解 SysVinit 的串行瓶颈是启动优化的第一步。后续章节将介绍如何通过并行启动、依赖分析、延迟启动等技术，将嵌入式系统的启动时间从 8s 缩短到 2s 以内。
3.6 本章小结
SysVinit 的串行启动机制通过严格的脚本顺序执行确保了系统的确定性，但代价是启动性能的线性增长。在嵌入式系统中，I/O 密集型操作（如网络协商、文件系统检查）成为主要瓶颈，导致启动时间无法满足实时性要求。理解这些串行瓶颈，是迈向并行启动优化的基础。