为什么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: ~ > pstree

systemd─┬─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的设计哲学。

职责分离

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

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

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

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

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

init负责： 高层逻辑，比如系统初始化和服务管理, 决定哪些服务或进程需要启动以及启动的顺序。
内核负责： 提供底层机制（如fork、exec）来实现进程创建和调度。

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

3. 灵活性和可配置性

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

> ls /usr/sbin/init -l

lrwxrwxrwx 1 root root 20 Dec 17 04:23 /usr/sbin/init -> /lib/systemd/systemd

内核的任务： 启动第一个用户空间进程（PID为1的init）。
init的任务： 配置系统、启动服务、管理运行级别。

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

4. 总结

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

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