为什么 UNIX 使用 init 进程启动其他进程？

在 UNIX 系统中，当系统启动时，内核完成初始化后会启动第一个用户空间进程，通常是init进程。init进程负责启动和管理其他用户空间进程，而内核本身并不直接处理这些任务。为什么 UNIX 采用这样的设计，而不是让内核直接负责启动所有进程？本文将从多个角度分析这种设计的背后逻辑与优点。

0. UNIX 是否真的使用 init 进程？

RTFS，通过观察 Linux 内核源代码（这里），可以发现这段代码：

if (!try_to_run_init_process("/sbin/init") ||    !try_to_run_init_process("/etc/init") ||    !try_to_run_init_process("/bin/init") ||    !try_to_run_init_process("/bin/sh"))        return 0;
panic("No working init found.  Try passing init= option to kernel. "      "See Linux Documentation/admin-guide/init.rst for guidance.");

这说明 Linux 真的会尝试启动一个 init 进程，甚至如果启动失败就“罢工”了。

同时观察pstree的输出：

VM: ~ > pstreesystemd─┬─ModemManager───2*[{ModemManager}]        ├─acpid        ├─2*[agetty]        ├─dbus-daemon        ├─mysqld───48*[{mysqld}]        ├─nginx───2*[nginx]        ├─sshd───sshd───sshd───bash───pstree        ├─systemd-journal        ├─systemd-logind        ...

的确可以发现所有的进程都是由 systemd“生长分化”（fork）出来的。

1. 为什么内核不直接启动所有进程？

尽管内核拥有启动进程的能力，但让内核直接启动所有进程并不符合 UNIX 的设计哲学。

1. 职责分离进程的生命周期管理（如创建、调度）由内核负责，而决定哪些进程需要启动及其配置由用户空间的 init 进程管理。这样可以让内核保持简洁，减少复杂性。

2. 灵活性通过init或其他替代方案，用户可以动态调整系统初始化逻辑，例如定义不同运行级别或自定义服务启动顺序（systemctl）。而将这些逻辑交给内核则会限制这种灵活性。

3. 避免内核代码膨胀如果内核直接负责启动所有用户进程，它将不得不处理大量复杂的逻辑，例如服务依赖、配置文件解析等。这会导致内核代码变得庞大且难以维护。

2. 职责分离与模块化设计

UNIX 操作系统遵循职责分离的设计哲学，将不同的功能模块化处理：

• init负责： 高层逻辑，比如系统初始化和服务管理, 决定哪些服务或进程需要启动以及启动的顺序。

• 内核负责： 提供底层机制（如fork、exec）来实现进程创建和调度。

通过将进程管理的高层逻辑交由用户空间中的init进程负责，内核可以保持专注于底层资源管理，简化了自身的设计和实现。

3. 灵活性和可配置性

init进程是用户空间的程序，可以被系统管理员配置或替换为其他初始化系统（如systemd或upstart）。这种灵活性使得不同的 UNIX 系统可以根据需求自定义其初始化逻辑，而无需更改内核。

> ls /sbin/init -llrwxrwxrwx 1 root root 20 Dec 17 04:23 /sbin/init -> /lib/systemd/systemd

• 内核的任务： 启动第一个用户空间进程（PID 为 1 的init）。

• init的任务： 配置系统、启动服务、管理运行级别。

这种设计避免了将系统初始化的逻辑写入内核，使得系统更易于维护和扩展。

4. 总结

UNIX 选择通过init进程启动和管理其他进程，而不是由内核直接完成，这是为了实现职责分离、增强灵活性、简化内核设计并提高系统的可维护性。

这种设计不仅遵循了 UNIX 的模块化哲学，还为系统的扩展性和灵活性提供了基础，体现了 UNIX 设计的简洁与优雅。

文章转载自：hk416hasu

原文链接：https://www.cnblogs.com/hk416hasu/p/18689248

体验地址：http://www.jnpfsoft.com/?from=001YH