用户进程。init 进程以守护进程(也就是服务)的方式存在，是所有其他进程的祖先。init 进程非常独特，能够完成其他进程无法完成的任务。init 系统能够定义、管理和控制 init 进程的行为。它负责组织和运行许多独立的或相关的初始化工作(因此被称为 init 系统)，从而让计算机系统进入某种用户预定义的运行模式，比如命令行模式或图形界面模式。

upstart -> systemd。虽然本文的目的是要介绍 systemd，但是笔者觉得如果能从历史发展的角度观察 init 系统的演进，将会帮助我们更好的理解、使用 systemd。

文件系统
文件

关闭系统，主要是在系统关闭是为了保证数据的一致性，需要小心地按照顺序进行任务的结束和清理工作。另外，sysvinit 还提供了很多管理和控制系统的命令，比如 halt、init、mesg、shutdown、reboot 等等。链接接到合适的目录就可以了。错误排查。

用户来说是不能接受的。

。是第一个被广泛应用的新一代 init 系统。

通知，发现该设备，这就是一个新的事件。在感知到该事件之后触发相应的等待任务，比如处理 /etc/fstab 中存在的挂载点。采用这种事件驱动的模式，upstart 完美地解决了即插即用设备带来的新问题。采用事件驱动机制也带来了一些其它有益的变化，比如加快了系统启动时间。sysvinit 运行时是同步阻塞的。一个脚本运行的时候，后续脚本必须等待。这意味着所有的初始化步骤都是串行执行的，而实际上很多服务彼此并不相关，完全可以并行启动，从而减小系统的启动时间。

的特点解决了之前提到的 sysvinit 的缺点。采用事件驱动模型的可以：

可以很好地应用在桌面或者便携式系统中，处理这些系统中的动态硬件插拔特性。

功能强大，使用方便，缺点是体系庞大，非常复杂，下图展示了 systemd 的架构(此图来自互联网)：

修改。这降低了系统向 systemd 迁移的成本，使得 systemd 替换现有初始化系统成为可能。

更激进的并行启动能力，采用了 socket / D-Bus activation 等技术启动服务。一个显而易见的结果就是：更快的启动速度。为了减少系统启动时间，systemd 的目标是：

也试图实现这两个目标。下图展示了相对于 sysvinit 在并发启动这个方面的改进(此图来自互联网)：

增加了系统启动的并行性，从而提高了系统启动速度。但是在中，有依赖关系的服务还是必须先后启动。比如任务 A,B,(C,D)因为存在依赖关系，所以在这个局部，还是串行执行。

认为存在相互依赖而必须串行的服务，比如 Avahi 和 D-Bus 也可以并发启动。从而实现如下图所示的并发启动过程(此图来自互联网)：

更进一步提高了并行启动能力，极大地加速了系统启动时间。

后台服务进程全部启动运行。并且系统必须等待所有的服务都启动就绪之后，才允许用户登录。这种做法有两个缺点：首先是启动时间过长，其次是系统资源浪费。

关闭它，等待下次需要时再次启动它。文章介绍如何把过去 inetd 管理的服务迁移到 systemd。

查询，systemd 可以确保找到所有的相关进程，从而干净地停止服务。已经出现了很久，它主要用来实现系统资源配额管理。提供了类似文件系统的接口，使用方便。当进程创建子进程时，子进程会继承父进程的。因此无论服务如何启动新的子进程，所有的这些相关进程都会属于同一个 ，systemd 只需要简单地遍历指定的即可正确地找到所有的相关进程，将它们一一停止即可。

自动挂载的管理

用户可以用 /etc/fstab 文件来维护固定的文件系统挂载点。这些挂载点在系统启动过程中被自动挂载，一旦启动过程结束，这些挂载点就会确保存在。这些挂载点都是对系统运行至关重要的文件系统，比如 HOME 目录。和 sysvinit 一样，Systemd 管理这些挂载点，以便能够在系统启动时自动挂载它们。systemd 还兼容 /etc/fstab 文件，您可以继续使用该文件管理挂载点。

用户还需要动态挂载点，比如打算访问 DVD 或者 NFS 共享的内容时，才临时执行挂载以便访问其中的内容，而不访问光盘时该挂载点被取消(umount)，以便节约资源。传统地，人们依赖 autofs 服务来实现这种功能。自动挂载服务，无需另外安装 autofs 服务，可以直接使用 systemd 提供的自动挂载管理能力来实现 autofs 的功能。

文件系统必须依赖网络能够正常工作。systemd 虽然能够最大限度地并发执行很多有依赖关系的工作，但是类似"挂载 NFS"和"启动网络"这样的工作还是存在天生的先后依赖关系，无法并发执行。对于这些任务，systemd 维护一个"事务一致性"的概念，保证所有相关的服务都可以正常启动而不会出现互相依赖，以至于死锁的情况。

自带日志服务 journald，该日志服务的设计初衷是克服现有的 syslog 服务的缺点。比如：

内容无法验证。每一个本地进程都可以声称自己是 Apache PID 4711，而 syslog 也就相信并保存到磁盘上。
自动化的日志分析器需要分析人类语言字符串来识别消息。一方面此类分析困难低效；此外日志格式的变化会导致分析代码需要更新甚至重写。

用户使用 journalctl 命令来查看日志信息。无需自己编写复杂脆弱的字符串分析处理程序。

systemd journal 的优点如下：简单性：代码少，依赖少，抽象开销最小。零维护：日志是除错和监控系统的核心功能，因此它自己不能再产生问题。举例说，自动管理磁盘空间，避免由于日志的不断产生而将磁盘空间耗尽。移植性：日志文件应该在所有类型的 Linux 系统上可用，无论它使用的何种 cpu 或者字节序。性能：添加和浏览日志非常快。最小资源占用：日志数据文件需要较小。统一化：各种不同的日志存储技术应该统一起来，将所有的可记录事件保存在同一个数据存储中。所以日志内容的全局上下文都会被保存并且可供日后查询。例如一条固件记录后通常会跟随一条内核记录，最终还会有一条用户态记录。重要的是当保存到硬盘上时这三者之间的关系不会丢失。syslog 将不同的信息保存到不同的文件中，分析的时候很难确定哪些条目是相关的。扩展性：日志的适用范围很广，从嵌入式设备到超级计算机集群都可以满足需求。安全性：日志文件是可以验证的，让无法检测的修改不再可能。

系统初始化需要做的事情非常多。需要启动后台服务，比如启动 ssh 服务；需要做配置工作，比如挂载文件系统。这个过程中的每一步都被 systemd 抽象为一个配置单元，即 unit。可以认为一个服务是一个配置单元，一个挂载点是一个配置单元，一个交换分区的配置是一个配置单元等等。systemd 将配置单元归纳为以下一些不同的类型。然而，systemd 正在快速发展，新功能不断增加。所以配置单元类型可能在不久的将来继续增加。下面是一些常见的 unit 类型：

service ：代表一个后台服务进程，比如 MysqLd。这是最常用的一类。socket ：此类配置单元封装系统和互联网中的一个套接字。当下，systemd 支持流式、数据报和连续包的 AF_INET、AF_INET6、AF_UNIX socket 。每一个套接字配置单元都有一个相应的服务配置单元。相应的服务在第一个"连接"进入套接字时就会启动(例如：nscd.socket 在有新连接后便启动 nscd.service)。device ：此类配置单元封装一个存在于 Linux 设备树中的设备。每一个使用 udev 规则标记的设备都将会在 systemd 中作为一个设备配置单元出现。mount ：此类配置单元封装文件系统结构层次中的一个挂载点。Systemd 将对这个挂载点进行监控和管理。比如可以在启动时自动将其挂载；可以在某些条件下自动卸载。Systemd 会将 /etc/fstab 中的条目都转换为挂载点，并在开机时处理。automount ：此类配置单元封装系统结构层次中的一个自挂载点。每一个自挂载配置单元对应一个挂载配置单元，当该自动挂载点被访问时，systemd 执行挂载点中定义的挂载行为。swap：和挂载配置单元类似，交换配置单元用来管理交换分区。用户可以用交换配置单元来定义系统中的交换分区，可以让这些交换分区在启动时被激活。target ：此类配置单元为其他配置单元进行逻辑分组。它们本身实际上并不做什么，只是引用其他配置单元而已。这样便可以对配置单元做一个统一的控制。这样就可以实现大家都已经非常熟悉的运行级别概念。比如想让系统进入图形化模式，需要运行许多服务和配置命令，这些操作都由一个个的配置单元表示，将所有这些配置单元组合为一个目标(target)，就表示需要将这些配置单元全部执行一遍以便进入目标所代表的系统运行状态。 (例如：multi-user.target 相当于在传统使用 SysV 的系统中运行级别 5)timer：定时器配置单元用来定时触发用户定义的操作，这类配置单元取代了 atd、crond 等传统的定时服务。snapshot ：与 target 配置单元相似，快照是一组配置单元。它保存了系统当前的运行状态。path：文件系统中的一个文件或目录。scope：用于 cgroups，表示从 systemd 外部创建的进程。slice：用于 cgroups，表示一组按层级排列的单位。slice 并不包含进程，但会组建一个层级，并将 scope 和 service 都放置其中。

配置文件，系统管理员的任务就是编写和维护这些不同的配置文件，比如一个 MysqL 服务对应一个 MysqL.service 文件。这种配置文件的语法非常简单，用户不需要再编写和维护复杂的系统脚本了。

"套接字激活"(socket activation)、D-Bus activation 和 autofs 三大方法来解除依赖。比如：挂载必须等待挂载点在文件系统中被创建；挂载也必须等待相应的物理设备就绪。为了解决这类依赖问题，systemd 的配置单元之间可以彼此定义依赖关系。Systemd 用配置单元定义文件中的关键字来描述配置单元之间的依赖关系。比如：unit A 依赖 unit B，可以在 unit B 的定义中用"require A"来表示。这样 systemd 就会保证先启动 A 再启动 B。

数据库中的有所不同，主要是为了保证多个依赖的配置单元之间没有环形引用。比如存在 unit A、B、C，假如它们的依赖关系如下(此图来自互联网)：