“Ubuntu Linux”系统的深入洞察——我们看到了吗？
正如我们所知，LINUX 是一个内核而不是操作系统，附带多个发行版，例如：Debian、Fedora、UbuntuMark Shuttleworth 开发的 Ubuntu 操作系统广为人知并被许多人广泛使用。此外，由于是免费和开源的，它的新版本每年都会发布，这是由成千上万为其开发做出贡献的开发人员做出的贡献。但是，它是如何运作的呢？哪些流程、事件列表使其发挥作用？这些流程的意义是什么？
本文将带您深入了解 Ubuntu 操作系统 的内部结构，这非常有趣，并且可以帮助新手完全了解其功能。
系统的布置
Linux的运行有一个进程，每一个系统服务包括电源管理、启动、系统崩溃处理都是一个进程，在“/etc/init”中有一个配置文件，描述了该进程的事件。它将执行并停止执行相应的事件，同时它还在系统的“/etc/”目录中维护描述其运行时行为的其他配置文件，从而使系统事件驱动的。
如果生成了事件，那么应该有人去捕获它们并执行它们？显然，控制器是我们的主进程，它是进程 id 1（即 init）的所有进程的父进程。这是随着系统启动而开始的过程，并且永远不会停止。这个进程只有在系统断电后才会终止，因为没有进程是 init 的父进程。
6.10 之前的 Ubuntu 早期版本包含旧样式 sysvinit，用于运行“/etc/rcx.d ” 系统每次启动和关闭时的目录。但是，之后upstart系统取代了旧式sysvinit系统，但仍然提供向后兼容性。
最新的 Ubuntu 版本都有这个新贵系统，但自从它从 Ubuntu 6.10 演变以来，它已经进行了多次修订，截至 2014 年 9 月 4 日，当前版本为 1.13.2。最新的新贵系统有 2 个 init 进程，一个用于系统进程，另一个用于管理当前登录的用户会话，并且仅在用户登录之前存在，也称为 x-session init 。
整个系统被制定为分层系统，由贯穿系统上电到断电的祖先-子关系组成。
例如：两个init进程之间的一个小的层次关系是：system init(1) -> 显示管理器(内核空间) ->显示管理器（用户空间）-> 用户初始化（或 x-session 初始化）。
由系统 init 管理的进程的配置文件驻留在“/etc/init”中，由会话 init 管理的进程的配置文件驻留在“/usr/share/upstart”中（如根据当前的新贵版本 1.12），这些配置文件是本文所述的许多有关进程的秘密的关键。
更深入地了解层次结构
Ubuntu 识别两种类型的进程：
- 短暂的工作（或工作即死亡的工作）。
- 长期工作（或停留并工作的工作）。
系统上的层次结构是由于进程之间的依赖关系而产生的，我们可以通过查看它们的配置文件来了解它们。我们首先从使系统启动的进程之间的简单层次关系开始，了解每个进程的重要性。
引导层次结构
Init 是系统上电时第一个启动的进程，属于 work-and-stay 作业，因为它永远不会被杀死，只有当 init 被杀死时才会生效断电，即 init 只会死掉，而且每个会话也会死一次，而且是在断电时。上电时，init 会生成系统上的第一个事件，即启动事件。 “/etc/init”中的每个配置文件都有两行，定义导致进程启动和停止的事件。这些行如下图突出显示：
这是进程 failsafe-x 的配置文件，这些启动和停止条件描述了进程启动的事件。在 init 进程生成启动事件时，那些以启动作为启动条件的进程将并行执行，这仅定义了层次结构，并且在启动时执行的所有进程都是 init 的子进程。
启动时启动的进程如下所示，这些都是工作和死亡的工作：
1。 主机名 – 这是一个仅告诉系统 /etc/hostname 文件中定义的主机名的进程。
2。 kmod – 加载内核模块，即 /etc/modules 文件中的所有驱动程序。
3。 mountall – 此进程会生成大量事件，主要负责在启动时挂载所有文件系统，包括本地文件系统和远程文件系统。
/proc 文件也是由这个进程挂载的，在所有挂载工作之后，它生成的最后一个事件是文件系统事件，这进一步使层次结构进一步前进。
4。 plymouth – 此进程在启动 mountall 时执行，负责显示系统启动时看到的黑屏，如下所示：
5。 plymouth-ready – 表示 plymouth 已启动。
以下是主要流程，其他也在启动时执行的流程包括，如 udev-fallback-graphics 等。回到启动层次结构，简而言之，接下来的事件和流程按顺序排列：
1。 init 以及启动事件的生成。
2。 mountall 挂载文件系统，plymouth（以及启动 mountall）显示初始屏幕，以及 kmod 加载内核模块。
3。 mountall 生成的 local-filesystem 事件导致 dbus 运行。 （Dbus 是系统范围的消息总线，它创建一个套接字，让其他进程通过向该套接字发送消息来相互通信，并且接收者侦听该套接字上的消息并过滤其想要的消息）。
4。 本地文件系统以及启动的 dbus 和由也在本地文件系统事件上运行的进程网络引起的静态网络启动事件导致网络管理器运行。
5。 mountall 生成的 virtual-filesystem 事件导致 udev 运行。 （udev 是 Linux 的设备管理器，管理设备的热插拔，并负责在 /dev 目录中创建文件并管理它们。） udev 在 /dev 目录中为 ram、rom 等创建文件，mountall 已完成虚拟挂载-filesystems 并生成了表示安装 /dev 目录的事件 virtual-filesystem。
6。 udev 导致 upstart-udev-bridge 运行，这表明本地网络已启动。然后在 mountall 完成安装最后一个文件系统并生成文件系统事件后。
7。 filesystem 事件与 static-network-up 事件一起导致 rc-sysinit 作业运行。这里，旧的 sysvinit 和 upstart 之间的向后兼容性......
9。 rc-sysinit 运行告诉系统运行级别的 telinit 命令。
10。获取运行级别后，init 会执行以“S”或“K”开头的脚本（启动具有“S”的作业）并杀死 /etc/rcX.d 目录中名称开头带有“K”的文件（其中“X”是当前运行级别） 。
这一小组事件会导致系统在每次开机时启动。并且，流程的事件触发是唯一负责创建层次结构的事情。
现在，上面的另一个附加内容是事件的原因。哪个进程导致哪个事件也在该进程的同一配置文件中指定，如下所示：
以上是进程mountall的一段配置文件。这显示了它发出的事件。事件的名称是单词“事件”之后的名称。事件可以是上面配置文件中定义的事件，也可以是带有前缀“starting”、“started”、“stopping”或“stopped”的进程名称。
所以，这里我们定义两个术语：
- 事件生成器：在其配置文件中具有“emits xxx”行的事件生成器，其中 xxx 是它拥有或生成的事件的名称。
- 事件捕获器：其启动或停止条件为 xxx 或在事件生成器之一生成的事件上启动或停止的捕获器。
因此，层次结构如下，进程之间的依赖关系如下：
Event generator (parent) -> Event catcher (child)
增加层次结构的复杂性
到现在为止，您一定已经了解了如何通过简单的启动机制通过事件触发机制来奠定进程之间父子依赖的层次结构。
现在，这种层次结构从来都不是一种一对一的关系，只有一个父母对一个孩子。在这一层次结构中，我们可能有一个或多个子进程的父进程，或者一个进程是多个子进程的父进程。这是如何实现的？？答案就在于配置文件本身。
这些行取自进程 - 网络，这里的启动条件似乎有点太复杂，由许多事件组成，即 - local-filesystems、udevtrigger、container、运行级别、网络。
Local-filesystems 由 mountall 发出，udevtrigger 是作业名称，container 事件由 container-detect 发出，runlevel 事件由 rc-sysinit 发出，networking 又是一个作业。
因此，在层次结构中，进程网络是 mountall、udevtrigger 和容器检测的子级，因为它无法继续其功能（进程的功能是在进程配置文件中的 script 或 exec 部分下定义的所有行）直到上述进程生成它们的事件。
同样，如果一个进程生成的事件被多个进程缓存，我们可以让一个进程成为多个进程的父进程。
区分工作类型
正如前面所定义的，我们可以拥有短期（或工作后死亡）的工作或长期（或停留并工作）的工作，但如何区分他们？？
在其配置文件中指定了“开始”和“停止”条件并且在其配置文件中包含单词“任务”的作业配置文件是 work-and-die 作业，它们在生成的事件上启动，执行其脚本或 exec 部分（在执行时，它们会阻止导致它们的事件），然后在释放它们阻止的事件后死亡。
那些配置文件中没有“stop on”条件的作业是长期存在的或stay-and-work作业，它们永远不会消亡。现在，留职工作可以进一步分类为：
- 那些没有重生条件并且可以被root用户杀死的。
- 那些在其配置文件中具有重生条件的人，因此除非他们的工作已完成，否则他们会在被杀死后重新启动。
结论
因此，LINUX 中的每个进程都依赖于某些进程，并且有一些进程依赖于它，这种关系是多对多的，并且由新贵系统以及进程的其他细节指定。