init进程是所有守护进程的总管，负责启动、监控、重启和清理；它作为PID 1进程孵化守护进程，回收僵尸进程，并支持从SysV init到systemd的演进及socket激活等机制。
守护进程（Daemon）和 init 进程不是并列关系，而是管理与被管理的关系：init 进程是所有守护进程的“总管”，负责它们的启动、监控、重启和清理。没有 init，守护进程就无法被系统统一调度和持久化运行。
init 是守护进程的“出生证明”和“监护人”
Linux 内核启动后，第一个用户空间进程就是 init（PID 1）。它一运行，就开始孵化其他进程——包括所有系统级守护进程（如 sshd、rsyslog、cron、nginx 等）。这些守护进程要么由 init 直接 fork 启动，要么通过 init 调用的脚本间接启动。更重要的是，当某个守护进程意外退出，init 会收养它的子进程、回收其资源，防止僵尸进程堆积；若配置了自动重启（如 systemd 的 Restart=always），init 还会主动拉起它。
从 SysV init 到 systemd：服务启动方式的三次跃迁
-
SysV init（串行脚本时代）：依赖
/etc/init.d/下的 shell 脚本，按运行级别（runlevel）和数字编号（如 S20network）顺序执行。服务之间靠人工约定启动顺序，无显式依赖声明，容易因顺序错乱导致失败。 - Upstart（事件驱动过渡）：Ubuntu 曾采用。不再严格按顺序，而是监听内核或用户空间事件（如“网络就绪”“磁盘挂载完成”）来触发服务启动，支持部分并行，但配置复杂、生态碎片化。
-
systemd（声明式依赖时代）：现代主流方案。每个服务定义为一个 unit 文件（如
sshd.service），明确声明After=network.target、Wants=sshd.socket等依赖关系。systemd 并行启动所有就绪服务，并自动解决拓扑依赖，启动更快、更可靠。
守护进程本身也在进化：从独立常驻到按需激活
早期守护进程基本都是“开机即驻留内存”，比如传统 httpd 或 vsftpd，一启动就长期监听端口。而 systemd 引入了 socket 激活机制：先启动一个轻量级 socket unit（如 sshd.socket），仅监听端口；真正有连接进来时，才动态拉起 sshd.service。这种方式节省资源，也提升了响应灵活性。类似机制还用于 D-Bus、udev 等场景。
兼容性与共存：旧脚本没被淘汰，只是被新引擎接管
即使在 systemd 系统中，/etc/init.d/ 下的传统脚本依然有效。systemd 提供了 systemd-sysv-generator 工具，在启动时自动将这些脚本转换为等效的 service unit。命令如 sudo systemctl start apache2 实际可能调用的就是 /etc/init.d/apache2，只是由 systemd 统一调度、日志归集、状态追踪。这种设计让升级平滑，避免生态断裂。
