Linux From Scratch（以下简称 LFS）项目自诞生以来，一直是 Linux 社区学习系统内部工作原理的标杆教材。该项目通过手工构建整个 Linux 系统的过程，帮助开发者深入理解操作系统各组件之间的协作机制。在 LFS 的发展历程中，初始化系统（init system）的选择始终是一个核心议题。从最初完全基于 SysVinit 的设计，到如今同时提供 SysV 和 systemd 双版本支持，LFS 的演进折射出整个 Linux 生态在 init 系统上的范式转变。本文将从技术决策的角度，分析这一迁移背后的逻辑，并提供启动脚本转换的具体工程实践方法。
LFS 项目的双轨支持格局与上游压力
LFS 项目长期维持着 SysV 版本与 systemd 版本并行发布的策略。以 LFS 12.4（2025 年 9 月发布）为例，项目同时提供了标准的 SysV 书籍和 LFS-systemd 版本。这种双轨设计最初源于 systemd 作为一个全新的初始化系统在 2010 年代初兴起时，LFS 社区希望为学习者提供两种选择。然而，随着 systemd 在主流发行版中的绝对主导地位确立，以及上游开发者对 SysV 兼容性的逐步放弃，这种双轨格局正面临前所未有的挑战。
2025 年 12 月发布的 systemd v259 正式宣布弃用对 System V 服务脚本的支持，并明确表示将在 v260 版本中移除相关组件。这意味着长期依赖的 systemd-rc-local-generator、systemd-sysv-generator 以及 systemd-sysv-install 等工具将在未来版本中消失。对于像 LFS 这样追求与上游生态同步的项目而言，继续维护独立的 SysV 分支将变得越来越困难。LFS 项目维护者需要在保持教育价值与顺应技术趋势之间做出权衡，而上游的这一决定显然为这一权衡提供了明确的方向。
传统 SysVinit 的设计哲学与局限性
理解 SysVinit 的设计，有助于我们把握迁移的必要性。SysVinit 采用基于运行级别（runlevel）的顺序启动模型，系统通过 /etc/rc.d 目录下的脚本按顺序启动各项服务。这种模型的优势在于其简洁性和可预测性：启动过程完全由 shell 脚本控制，开发者可以清晰地追踪每一个执行步骤。对于教学目的而言，SysVinit 的透明性使其成为理解 Linux 启动流程的理想起点。
然而，SysVinit 在现代计算环境中的局限性同样明显。首先，顺序启动机制无法充分利用多核处理器的并行处理能力，系统必须等待前一个服务完成才能启动下一个，这在服务数量增加时会导致显著的启动延迟。其次，SysVinit 缺乏内置的依赖管理机制，服务之间的启动顺序只能通过手工编排的序号来间接实现，这使得复杂服务的依赖关系难以维护。此外，SysVinit 的日志管理分散在各个脚本中，缺乏统一的日志收集和查询接口，给系统调试和监控带来不便。
systemd 的现代特性与架构革新
systemd 的出现正是为了解决上述局限性。它引入了基于单元（unit）的并行启动机制，配合显式的依赖声明，使得系统能够智能地并行启动相互独立的服务，同时保证有依赖关系的服务按正确顺序执行。systemd 的单元配置文件采用声明式语法，替代了 SysVinit 繁琐的过程式脚本，大大简化了服务配置的编写和维护工作。典型的 systemd 单元文件仅需几行配置即可完成以前数十行 shell 脚本才能实现的功能。
systemd 的另一个重要革新是集成了 journald 日志系统。所有服务的输出都会被 journald 统一收集，支持结构化日志、按时间范围过滤、服务关联查询等功能，极大地简化了系统日志管理。此外，systemd 还提供了 cgroup 资源控制、动态服务管理、按需启动等高级特性，这些在 SysVinit 环境下需要额外配置才能实现的功能，在 systemd 中得到了原生支持。
迁移工程：启动脚本转换的核心步骤
将传统 SysVinit 服务迁移到 systemd，首先需要理解两者的概念映射关系。SysVinit 中的运行级别对应 systemd 中的目标（target），/etc/init.d 中的服务脚本对应 systemd 的服务单元（service unit），而 rcS、runlevel 等机制则由 systemd 的特定单元和掩码（mask）机制替代。
转换过程中，最关键的是编写 systemd 单元文件。以一个简单的 SysVinit 服务脚本为例，其通常包含 start、stop、restart 等函数，并通过 case 语句处理命令行参数。转换为 systemd 单元文件后，这些逻辑被简化为对 ExecStart、ExecStop 等指令的声明。例如，一个原本需要如下 shell 脚本的守护进程：
#!/bin/bash
case "$1" in
start)
echo "Starting myservice"
/usr/bin/myservice --daemon
;;
stop)
echo "Stopping myservice"
pkill -x myservice
;;
esac
可以转换为如下 systemd 单元文件：
[Unit]
Description=My Custom Service
After=network.target
[Service]
Type=simple
ExecStart=/usr/bin/myservice --daemon
ExecStop=/usr/bin/myservice --shutdown
Restart=on-failure
[Install]
WantedBy=multi-user.target
这种转换不仅简化了配置，还带来了自动重启、日志集成、依赖声明等额外功能。
兼容层设计与回滚策略
在迁移过程中，为了保证业务连续性，设计合理的兼容层是必要的。systemd 提供了 systemd-sysv-generator 工具，能够将 SysVinit 脚本自动转换为临时单元文件，使现有脚本在 systemd 环境下无需修改即可运行。然而，这种自动转换是有限的，无法利用 systemd 的全部特性，且在 systemd v260 中将被移除。对于关键业务系统，建议采取渐进式迁移策略：首先在测试环境中完成单元文件编写和验证，确认功能正常后，在维护窗口期执行切换，并保留 SysVinit 脚本作为回滚方案。
回滚策略应包含以下几个要点：保留原有的 SysVinit 脚本和相关配置；在系统启动管理器（如 GRUB）中保留指向旧内核的选项；建立切换前后的服务健康检查机制；准备明确的回滚触发条件和操作步骤。通过这些措施，可以在迁移出现问题时快速恢复服务，将业务影响降至最低。
LFS 语境下的迁移考量与未来展望
对于 LFS 项目的维护者和使用者而言，向 systemd 迁移不仅是技术选择，更关乎项目定位。LFS 的核心价值在于教育，而 systemd 作为现代 Linux 系统的主流 init 系统，掌握其使用方法本身具有重要的教育意义。同时，systemd 单元文件的声明式语法相对于 SysVinit 的过程式脚本，更符合现代软件工程的最佳实践，有助于培养学习者的配置管理能力。
从工程实践的角度看，LFS 项目可以采取分阶段迁移策略：在维持双版本支持的同时，逐步增加 systemd 版本的优先级和文档完整性；鼓励社区贡献者使用 systemd 版本构建系统并反馈问题；最终在合适的时机（如 systemd v260 正式发布后）宣布 SysV 版本的维护状态。这种渐进式过渡既能照顾到老用户的习惯，又能引导新用户使用更现代的技术栈。
综上所述，LFS 项目在 init 系统上的演进反映了整个 Linux 生态的技术趋势。虽然 SysVinit 因其简洁性在教学场景中仍有价值，但上游系统的放弃使其难以作为生产环境的长期选择。通过理解两者的差异、掌握脚本转换方法、制定合理的迁移和回滚策略，开发者可以在保持系统稳定性的前提下，顺应技术发展的潮流。
资料来源：LFS News (https://linuxfromscratch.org/lfs/news.html)；Systemd v259 Release Notes (https://github.com/systemd/systemd/releases)。