Linux 初始化系统（init system）

Linux 初始化系统综述

初始化系统（init system）是 Linux 启动流程中由内核加载的首个用户空间进程，进程 ID 固定为 1。该进程承担文件系统挂载、守护进程启动、服务依赖调度、系统运行级别与目标状态管理等基础系统初始化工作。

systemd 不是单一独立二进制文件，而是一组由多个可执行程序、共享库、单元配置文件构成的软件套件。/usr/lib/systemd/systemd 是套件内的主二进制程序，系统启动完成后该进程占据 PID 1，承担初始化系统的运行主体。套件其余功能由配套二进制程序分别实现，包含 systemctl、journalctl、systemd‑networkd、systemd‑resolved、systemd‑logind、systemd‑udevd。这些文件均为独立可执行二进制，各自完成对应任务，共享同一套底层库与单元定义规范。

编译后的安装产物包含大量 ELF 二进制文件，同时附带 .service、.target 等文本格式单元配置文件。单元文件用于描述服务启动规则、依赖关系与运行参数，不属于二进制程序。PID 1 的 systemd 主进程会按需派生其他子进程，子进程可调用套件内其他二进制程序执行对应操作。整套软件在发行版打包时通常合并为一个软件包，用户层面常将整套套件统称为 systemd。

与之对比，SysVinit、runit、OpenRC、s6 这类初始化方案同样由多个独立二进制与脚本文件组成，不存在仅依靠单个二进制文件完成全套系统初始化与服务管理的主流实现。

Linux 初始化系统无官方固定分类清单，依据项目维护状态、应用场景与可用性，可划分为四大类别。

主要初始化系统对比

非 Linux 平台方案（参考）

非 systemd 部署的技术依据

设计架构层面

• 组件集成模式：systemd 整合 journald、logind、networkd、resolved、udevd、timesyncd 等三十余项系统组件，采用一体化单体架构，弱化了 Unix 体系模块化、可替换的设计范式。
• 进程职责边界：PID 1 进程承载大量系统管控职责，代码体量庞大，单点故障影响范围与攻击面覆盖更广。
• 项目运维主体：systemd 长期由 Red Hat 企业团队主导开发迭代，社区自治属性较弱，存在基础设施治理结构争议。

运维与技术适配层面

• 日志存储格式：journald 默认采用二进制日志存储，无法直接通过 grep 等文本工具解析，需依赖专属 journalctl 工具，与传统运维审计方式存在差异。
• 生态依赖锁定：GNOME、Flatpak、Snap、cloud‑init、LXD 等主流组件默认适配 systemd 架构，非 systemd 发行版需维护专属兼容层，产生持续运维成本。
• 资源开销特性：systemd 组件体系完整，后台常驻服务数量多，在老旧硬件、极简容器与嵌入式场景中资源占用更高。
• 系统透明度：相较于 SysVinit、runit、s6 等脚本与进程监督架构，systemd 抽象层级更高，系统运行逻辑与故障定位直观性更低。
• 版本迭代变更：2026 年 systemd 新增可选 birthDate 字段；v259 版本将 systemd‑sysv‑generator、systemd‑sysv‑install 标记为遗留组件，停止支持 SysV 脚本；v260 版本完全移除 SysV 脚本适配能力，同步提升基础运行依赖，最低要求为 Linux 内核 5.10、glibc 2.34、OpenSSL 3.0、Python 3.9。

systemd 技术特性与生态优势

systemd 成为 Linux 生态主流初始化系统，基于多项标准化技术特性与生态适配能力。

• 启动调度机制：支持服务并行启动与精细化依赖校验，启动效率相较于 SysVinit 串行模式提升 70%–80%。
• 统一运维接口：通过 systemctl 工具实现全量服务的标准化管理，操作逻辑统一。
• 资源隔离能力：原生集成 cgroup 机制，支持服务资源配额管控、容器化部署与进程隔离。
• 扩展功能完备：原生支持 socket 激活、定时任务、日志聚合、设备热插拔管理等通用系统能力。
• 软件生态适配：上游开源项目优先提供 systemd unit 配置文件，生态兼容覆盖度为所有初始化系统最高。

版本迭代关键更新：systemd v259（2026 年 6 月发布）实现 journald 日志默认持久化、移除 TPM 1.2 适配、网络组件全面迁移至 nftables、cgroup v2 支持 HugeTLB 记账、扩展 Varlink IPC 接口能力；v260 版本完成 SysV 脚本适配彻底移除与基础依赖升级。

SysV init 诞生于 1980 年代，串行启动、依赖关系依靠手动编写脚本，启动效率低下，无法适配现代系统需求。Linux 社区发起初始化系统革新，多个项目尝试取代 SysVinit，后续也与 systemd 展开竞争。其中 Upstart、OpenRC、runit、s6 四个项目获得发行版与社区关注，后续仅留存于小众生态。

Upstart

2006 年，Canonical 开发 Upstart，为事件驱动型初始化系统。其运行逻辑脱离固定顺序脚本执行，服务监听系统事件，事件触发后启动对应服务。

• “硬盘挂载完成”事件触发数据库启动
• “网卡上线”事件触发 Nginx 启动
• “USB 设备接入”事件加载对应驱动

事件驱动的异步启动机制，将 Ubuntu 6.10~14.10 的开机速度提升 30%–50%。

# /etc/init/myservice.conf 示例
start on filesystem or net-device-up IFACE=eth0
stop on runlevel [06]
exec /usr/bin/myapp

Ubuntu 在该时期桌面端用户规模较大，将 Upstart 推向主流。Red Hat、Debian 社区评估其标准化潜力，Lennart Poettering 也曾评价该项目具备创意。2010–2013 年大量 Ubuntu 服务器部署 Upstart，Google、Facebook 内部集群有小规模落地。

项目停止普及的因素：

Upstart 2014 年后停止迭代，Canonical 终止项目维护，仅存量老旧系统保留部署。

OpenRC

OpenRC 基于 SysVinit 改造，保留 /etc/init.d/ Shell 脚本体系，新增依赖声明、并行启动、服务自动重启（respawn）能力。OpenRC 本身不作为 PID 1 运行，依托 SysVinit 或 BusyBox init 执行。

Gentoo 自 2007 年起默认使用 OpenRC，Alpine Linux 容器与嵌入式环境也采用该方案。

#!/sbin/openrc-run
# /etc/init.d/nginx OpenRC 服务脚本示例
depend() {
need net # 运行前置网络就绪
use logger # 可选依赖日志组件
}

start() {
ebegin "Starting nginx"
start‑stop‑daemon –start –exec /usr/sbin/nginx
eend $?
}

OpenRC 遵循组件边界约束，仅负责服务启动与监督，日志、设备、网络、cgroup 交由独立工具实现。一体化的 systemd 可以一次性提供全部能力，Ubuntu、Fedora、Debian 等通用发行版选择 systemd。OpenRC 持续维护，主要应用于 Gentoo 与 Alpine 生态。

runit

runit 采用三段式极简架构：

每个服务对应独立目录，包含 run、finish、check 可执行脚本，无复杂配置解析器与 DSL，依靠 Shell 脚本与目录结构完成定义。

Void Linux 默认使用 runit，系统安装后体积控制在 200 MB 以内，启动耗时短。

/etc/sv/my‑app/run
#!/bin/sh
# runit 服务启动脚本示例
exec /usr/bin/my‑app

依赖关系通过脚本内检测逻辑实现。

#!/bin/sh
# runit 依赖检测示例
sv check postgresql || exit 1
exec /usr/bin/my‑app

日志处理脚本 /etc/sv/my‑app/log/run

#!/bin/sh
exec svlogd -tt /var/log/my‑app

runit 仅提供基础进程监督，日志需要搭配 svlogd，服务依赖由脚本顺序控制，cgroup 能力需要外部组件实现。模块化设计适配高级用户，对应运维操作步骤更多，通用发行版采用规模有限；在 Docker、嵌入式、路由器场景持续使用。

s6

s6 可视为 runit 的扩展方案，将进程监督构建在形式化状态机体系上，具备确定执行行为、精细化故障处理，s6‑rc 组件实现链式依赖管理。

项目开发将运行正确性作为开发准则，代码结构严谨。命令体系与配置存在学习门槛。systemd 的 [Unit]、[Service]、[Install] 三段式配置学习曲线更低。s6 多用于嵌入式、定制容器编排、高可靠服务器场景，如 Artix Linux 可选 s6 部署。

发行版选型转向 systemd 的影响因素

• 软件包默认带 .service 单元文件
• 文档、社区问答资源围绕 systemctl 积累
• Docker、Kubernetes、Prometheus 等组件原生集成 systemd

非 systemd 环境必须维护大量兼容层，运维成本出现上升。

systemd 架构相关讨论

systemd 的集成模式带来相关讨论，讨论内容指向其组件整合方式，与“单一程序完成单一任务”的传统 Unix 设计思路存在差异。systemd 将 journald、networkd、udevd、logind 等组件整合，代码体量较大，攻击面范围更广。

该架构提供多项可用能力：瞬时 oneshot 服务、服务自动重启与限流、原生 cgroup v2 支持，SSD 环境下实现秒级启动。Devuan、Artix 等发行版维持不搭载 systemd 的构建方案，对应用户群体规模有限。

各方案技术参数说明

runit

为 antiX 26 默认初始化方案，社区适配成熟。架构极简，后台常驻进程数量少，硬件资源占用低。三段式启动流程简化调度逻辑，在机械硬盘、低配置硬件中启动延迟更低。配置规则简洁，运维成本低于 s6 系列与 dinit 方案，为该发行版验证稳定的方案。

SysVinit

采用串行启动机制，启动速度低于并行架构方案。全量服务脚本集中于 /etc/init.d 目录，运行逻辑可完全追溯，故障排查链路清晰。适配无高速启动需求、侧重长期稳定运行的老旧设备场景。

dinit / s6‑rc / s6‑66

dinit 命令交互逻辑适配 systemd 使用习惯，现代化特性完善，但对老旧硬件无性能优化增益。s6‑rc 模块化拆分精细，支持高精度系统管控，但配置规则复杂，学习成本与运维成本较高。s6‑66 简化原生 s6 配置逻辑，仍高于 runit 运维复杂度，适用于系统定制开发场景，不适合基础轻量化部署。

硬件适配结论

内存 ≤ 512 MB、机械硬盘存储、轻度办公与挂机场景，runit 适配效果更好；超老旧硬件且沿用传统运维体系，可采用 SysVinit；系统架构研究与高阶定制场景，可选用 dinit、s6‑rc、s6‑66。

Linux 初始化系统生态现状与演进历程

截至 2026 年，全球活跃维护的 Linux 发行版中，有 15 个发行版默认未搭载 systemd，其余超 90% 的 Linux 部署环境采用 systemd 架构。Linux 初始化系统迭代为 SysVinit 到现代化架构的技术升级。

SysVinit 架构局限性

SysVinit 为传统 Unix 初始化架构，逻辑为读取 /etc/inittab 配置、串行执行启动脚本。该架构适配 1980 年代静态服务器场景，在现代计算环境中存在多项局限：多服务场景启动耗时可达数分钟；服务依赖通过文件名序号手动管控，无自动解析机制；硬件热插拔适配能力缺失，外设接入易导致系统状态异常；无法适配容器、云动态资源调度场景。2010 年后，该架构已无法满足现代 Linux 系统运行需求，行业形成统一迭代共识。

systemd 迭代与组件集成历程

systemd 由 Lennart Poettering 与 Kay Sievers 于 2010 年发布，2011 年起逐步被主流发行版适配：Fedora（2011）、Arch（2012）、RHEL/SUSE（2014）、Debian/Ubuntu（2015）。该架构通过并行启动、Socket 激活、自动依赖调度、服务异常重启机制，将系统启动耗时降低 70%–80%。

迭代过程中，systemd 逐步整合多类系统组件，形成一体化架构：

• journald：系统日志采集与存储组件
• resolved：域名解析服务管控组件
• networkd：网络配置管理组件
• logind：用户会话状态管控组件
• udevd：硬件设备检测与管理组件
• timesyncd：系统时间同步组件
• homed：便携式用户家目录管理组件

该集成模式区别于传统 Unix 单一组件单一功能的模块化架构，形成一体化系统管控体系。

主流非 systemd 架构部署形态

未采用 systemd 的发行版均采用轻量化模块化初始化架构。

• OpenRC：Gentoo、Alpine、Artix 默认架构，基于 Shell 脚本实现依赖调度，不替换系统原生基础组件，适配范围更广的非 systemd 方案，广泛应用于容器基础镜像场景。
• runit：Void Linux 默认架构，采用三段式极简架构，无复杂配置格式，通过软链接实现服务启停管理，侧重进程监督能力。
• dinit：Chimera Linux 默认架构，轻量化现代化架构，平衡极简设计与完整服务管理能力。
• s6：高精度进程监督套件，多用于嵌入式、定制容器场景，极少作为发行版默认初始化系统。

systemd 生态主导的成因

• 企业技术支撑：Red Hat 主导 systemd 开发迭代，依托企业级技术支持体系，推动 Fedora、RHEL 系列发行版优先适配，引领企业 Linux 生态迭代方向。
• 生态网络效应：主流发行版适配后，上游开源项目默认提供 systemd unit 配置文件，软件生态形成标准化适配体系，非 systemd 架构出现兼容适配壁垒。
• 桌面环境依赖：GNOME 桌面环境原生依赖 logind 会话管理组件，非 systemd 发行版需独立维护 elogind 分支，产生持续适配成本。

上述因素形成闭环生态，推动 systemd 成为 Linux 桌面与服务器场景的标准化架构。

非 systemd 架构的兼容适配成本

2026 年非 systemd 发行版需通过专属兼容层适配主流软件生态，产生固定运维成本：

• 会话管理适配：通过 elogind 分支组件适配 GNOME、KDE Plasma 桌面会话能力，需持续移植上游代码更新。
• 设备管理适配：早期通过 eudev 分支替代 systemd 整合的 udev 组件，Gentoo 等发行版于 2022 年停止维护 eudev，切换至 systemd‑utils。

非 systemd 架构简化初始化逻辑，但整体系统因兼容适配需求，整体复杂度并未降低。

架构场景适配边界

• 容器与嵌入式场景：OpenRC 适配的 Alpine 为通用容器基础镜像，runit 适配资源极致受限的嵌入式设备，轻量化架构优势显著。
• 自主可控服务器场景：无桌面依赖的自主运维服务器，可通过非 systemd 架构实现轻量化稳定运行。
• 企业生产服务器场景：systemd 依托标准化运维工具、生态兼容能力、厂商技术支持，作为企业生产环境通用选择。
• 技术学习场景：非 systemd 架构可直观展现系统启动与服务调度底层逻辑，用于系统原理学习与研究。

生态最终格局

systemd 完成 Linux 通用场景的生态普及，占据超 90% 部署份额，该市场结构将长期稳定。初始化系统的架构讨论围绕一体化集成架构与模块化拆分架构的设计范式差异展开，无统一行业定论。15 个活跃非 systemd 发行版为主动技术选型结果，通过持续投入兼容适配成本，维持模块化架构的部署形态。

systemd 体量与场景适配

是否采用 systemd，取决于部署场景、可用组件与对系统架构的取舍。Linux 内核本身不强制绑定任意用户空间初始化实现，系统可以在完全移除 systemd 全套组件的条件下完成启动与业务运行。

桌面运行需要席位管理、图形会话、电源事件处理、网络、日志、后台服务等能力，这些能力并不专属于 systemd。席位管理可以由 seatd、elogind 承担；网络管理可以选用 networkmanager、dhcpcd、iwd；电源事件处理可使用 acpid；日志可部署各类 syslog 实现；后台服务交由 OpenRC、runit、dinit、s6‑rc 管理；用户服务可通过修改 PAM 配置实现对应执行链路。ChromeOS 为商业级发行版，未采用 systemd，完成面向终端用户的完整交付。静态嵌入式系统、Buildroot 定制系统可以直接使用极简脚本作为 PID 1，不引入完整初始化套件。

桌面软件生态出现对 systemd 组件的绑定现象。GNOME 对 logind、userdb、systemd 用户实例存在依赖，已经移除 ConsoleKit 与 elogind 的适配路径。运行 GNOME 的非 systemd 发行版需要维护补丁或者修改后的组件分支。KDE 不存在强制依赖，同时可运行于 BSD 平台；其衍生登录管理器 PLM 增加 systemd 绑定，SDDM 本体保持独立实现。其余小众桌面项目对外部初始化组件依赖保持克制。

服务器集群规模扩大，单台主机运行业务数量下降，对本机一体化初始化套件的需求随之改变。大规模集群业务调度交由 Nomad、Kubernetes、Temporal 等上层编排系统，初始化系统仅承担基础主机环境搭建。容器环境内部，完整 systemd 套件的多数功能不会被调用，runit 这类轻量实现更加契合容器约束。

不同初始化系统配置表达形式存在区别。

# systemd .service 单元示例
[Unit]
Description=My Network Service
After=network.target

[Service]
ExecStartPre=/usr/local/bin/setup.sh ;# 启动前置准备脚本
ExecStart=/usr/bin/my‑app –config /etc/my‑app.conf ;# 主应用进程
ExecStopPost=/usr/local/bin/cleanup.sh ;# 停止后清理脚本
Restart=on‑failure ;# 异常重启策略
#!/sbin/openrc-run
# OpenRC 服务脚本示例
depend() {
need net
after firewall
}
description="这是一个示例守护进程"
command="/usr/bin/my‑daemon"
command_args="–port 8080 –log /var/log/my.log"
pidfile="/run/${RC_SVCNAME}.pid"

start_pre() {
checkpath –directory –owner myuser:mygroup /run/my‑daemon
}

stop_post() {
einfo "服务已停止，正在清理临时文件…"
rm -f /tmp/my‑daemon.lock
}

runit 使用目录加可执行脚本完成服务定义。

#!/bin/sh
# /etc/sv/my‑app/run runit 服务主脚本
exec /usr/bin/my‑app

依赖通过运行时检测实现。

#!/bin/sh
sv check postgresql || exit 1
exec /usr/bin/my‑app

日志接收处理脚本。

#!/bin/sh
# /etc/sv/my‑app/log/run
exec svlogd -tt /var/log/my‑app

systemd 的代码规模、内存占用存在不同统计口径。完整代码库行数约 60 余万行；在通用发行版默认部署，journald、logind、udevd、dbus 等组件合计内存占用可控制在 100 MB 以内，部分组件可手动关闭。Fedora 并不默认启用全部 systemd 子组件，提供组件选装机制。

一体化架构与模块化架构各自存在取舍。一体化方案减少发行版胶水脚本开发工作量，配置格式统一，上游软件可直接交付单元文件；同时组件之间耦合度提升，不同子模块行为会互相干涉，例如休眠逻辑同时由 systemd 和 acpid 接管时，事件分发与钩子执行会出现行为不确定。模块化方案将能力拆分至多个独立项目，各组件迭代周期、接口规范互相独立；但需要发行版完成组件之间的适配与粘合，维护脚本与兼容层，整体维护工作量发生转移，并不会直接消失。

传统 Unix “Do One Thing Well” 的设计范式，在多组件协同实现现代桌面、热插拔设备、会话管理、电源管理的场景，需要大量粘合脚本串联各个小程序，产生复杂度转移。systemd 使用一体化框架处理整套问题，以内部耦合替换外部脚本耦合。两种工程路线都可以完成业务目标。

社区对 systemd 的讨论覆盖设计范式、项目开发风格、组件耦合、生态绑定等维度。部分观点认为，即便不使用 systemd，现代操作系统依然需要一组等价的系统服务组件，不会完全消除对应开发工作量，仅改变组件的组织形态。抛开具体部署场景讨论是否需要该套件，属于伪命题。

延伸阅读

专业书籍

systemd 专项书籍

• 《Linux Service Management Made Easy with systemd》（Packt, 2022），Donald A. Tevault 著。覆盖 unit 配置、cgroups 管理、journald 运维、系统安全加固等内容，适配 Linux 运维与认证学习场景。
• 《How Linux Works: What Every Superuser Should Know》（No Starch Press, 第 3 版），Brian Ward 著。解析 Linux 启动全链路、初始化系统迭代历程、设备管理底层原理。

系统管理综合书籍

• 《UNIX and Linux System Administration Handbook》（第 5 版），Evi Nemeth 等著。包含 SysVinit 与 systemd 架构对比、生产环境运维实践。
• 《鸟哥的 Linux 私房菜：基础学习篇》（第 4 版）。讲解 SysV init 脚本、运行级别配置、systemd target 机制，为中文入门参考资料。
• 《Linux Essentials》（Sybex, 2012），Roderick W. Smith 著。记录 SysV init 向 systemd 过渡阶段的技术特征与演进逻辑。

官方文档

系统架构启动流程学习分级阅读

优先阅读《How Linux Works》启动流程章节、Gentoo 初始化系统对比矩阵、生态现状综述文献，建立全局认知。

systemd 深度学习

优先阅读官方创始人博客、专项技术书籍、systemd.io 官方规范文档。

• Lennart Poettering 官方博客：https://0pointer.de/blog/，收录 systemd 设计原理、迭代规划、架构设计原始文档。
• freedesktop.org 官方文档：https://freedesktop.org/wiki/Software/systemd/，阐述 systemd 官方设计目标与技术解决方案。

非 systemd 方案实战学习

优先阅读多方案对比博文、各组件官方文档、Artix Linux 实战配置文档。

架构设计范式研究

结合 systemd 官方设计文档、s6 架构规范、Unix 系统运维手册，对比一体化架构与模块化架构的设计差异。

Reference

• 十年仍争论不休！嫌它背离 Unix 哲学，又得用它搞定 90%的 Linux 机器_Dinit_服务_系统 https://www.sohu.com/a/1003282458_411876

• Dinit 构建、部署与使用指南 – 技术栈 https://jishuzhan.net/article/2083345841326014466

• Linux init 系统：dinit, openrc, runit, s6 的区别 – petercao – 博客园 https://www.cnblogs.com/bluestorm/p/19473457

• 为什么有那么多的人都不喜欢 Linux 中的 systemd 软件呢？ – 知乎 https://www.zhihu.com/question/652421219

• Linux 究竟需不需要 systemd 这么庞大的东西？ – 知乎 https://www.zhihu.com/question/664897021

• One Program Controls How 90% of Linux Machines Boot https://canartuc.medium.com/one-program-controls-how-90-of-linux-machines-boot-3f1504fc7f1d

• The Complete Map of Linux Init Systems in 2026: systemd, OpenRC, runit, s6, dinit https://gnutoday.com/linux-init-systems-complete-map-2026

• Boot Process with Systemd in Linux – GeeksforGeeks https://www.geeksforgeeks.org/linux-unix/boot-process-with-systemd-in-linux/

• Systemd Targets Boot Modes Linux Explained: Complete Guide 2026 https://www.linuxteck.com/systemd-targets-boot-modes-linux-explained/

• 系统初始化 – Hello-Embedded-Linux https://heygoda.github.io/Hello-Embedded-Linux/系统初始化.html

• 15 Systemd-Free Linux Distributions https://itsfoss.com/systemd-free-distros/
• The Best Linux Distributions Without systemd – TheFastCode https://www.thefastcode.com/en-usd/article/the-best-linux-distributions-without-systemd
• Best Linux Distros Without systemd in 2026 https://linuxstans.com/best-linux-distros-without-systemd/
• No systemd – Resources against systemd and alternatives https://nosystemd.org/
• Linux distributions without systemd – Without Systemd https://without-systemd.org/wiki/index_php/Linux_distributions_without_systemd/