CentOS 7 之systemd管理

CentOS系统启动流程：

POST --> Boot Sequence --> Bootloader --> kernel + initramfs(initrd) --> rootfs --> /sbin/init

innit程序：

CentOS 5：SysV init

CetnOS 6:  Upstart

CentOS 7 : Systemd

Systemd新特性：

系统Sys V init和LSB init scripts兼容

系统引导时实现服务并行启动；采用socket / D-Bus activation等技术启动服务；为了减少系统启动时间，systemd的目标是：尽可能启动更少的进程；尽可能将更多的进程并行启动；

按需激活进程；Systemd可以提供按需启动的能力，只有在某个服务被真正请求的时候才启动它。当该服务结束，systemd可以关闭它，等待下次需要时再次启动它。

能够对系统进行快照和恢复；

启动挂载点和自动挂载点的管理：

Systemd自助管理系统上的挂载点，以便能够在系统启动时自动挂载它们。且兼容/etc/fstab文件；

实现事务依赖关系管理：

systemd 维护一个"事务一致性"的概念，保证所有相关的服务都可以正常启动而不会出现互相依赖，以至于死锁的情况。

基于内生依赖关系定义服务控制逻辑；

system利用Linux内核的特性即CGroup来完成进程跟踪的任务。当停止服务时，通过查询CGroup，systemd可以确保找到所有的相关进程，从而干净地停止服务；

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

System的基本概念

单元的概念：

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

•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 的系统中运行级别 3)

•timer：定时器配置单元用来定时触发用户定义的操作，这类配置单元取代了 atd、crond 等传统的定时服务。

•snapshot ：与 target 配置单元相似，快照是一组配置单元。它保存了系统当前的运行状态。

依赖关系：

虽然 systemd 将大量的启动工作解除了依赖，使得它们可以并发启动。但还是存在有些任务，它们之间存在天生的依赖，不能用"套接字激活"(socket activation)、D-Bus activation 和 autofs 三大方法来解除依赖（三大方法详情见后续描述）。比如：挂载必须等待挂载点在文件系统中被创建；挂载也必须等待相应的物理设备就绪。为了解决这类依赖问题，systemd 的配置单元之间可以彼此定义依赖关系。

Systemd 用配置单元定义文件中的关键字来描述配置单元之间的依赖关系。比如：unit A 依赖 unit B，可以在 unit B 的定义中用"require A"来表示。这样 systemd 就会保证先启动 A 再启动 B。

Systemd事务：

Systemd 能保证事务完整性。Systemd 的事务概念和数据库中的有所不同，主要是为了保证多个依赖的配置单元之间没有环形引用。 存在循环依赖，那么 systemd 将无法启动任意一个服务。此时systemd 将会尝试解决这个问题，因为配置单元之间的依赖关系有两种：required是强依赖；want 则是弱依赖，systemd 将去掉 wants 关键字指定的依赖看看是否能打破循环。如果无法修复，systemd会报错。

Systemd 能够自动检测和修复这类配置错误，极大地减轻了管理员的排错负担。

Target和运行级别：

        systemd 用目标（target）替代了运行级别的概念，提供了更大的灵活性，如您可以继承一个已有的目标，并添加其它服务，来创建自己的目标。下表列举了 systemd 下的目标和常见 runlevel 的对应关系：

Systemd 的并发启动原理

如前所述，在 Systemd 中，所有的服务都并发启动，比如Avahi、D-Bus、livirtd、X11、HAL 可以同时启动。乍一看，这似乎有点儿问题，比如 Avahi 需要syslog 的服务，Avahi 和syslog 同时启动，假设 Avahi 的启动比较快，所以syslog 还没有准备好，可是 Avahi 又需要记录日志，这岂不是会出现问题？

Systemd 的开发人员仔细研究了服务之间相互依赖的本质问题，发现所谓依赖可以分为三个具体的类型，而每一个类型实际上都可以通过相应的技术解除依赖关系。

•并发启动原理之一：解决 socket 依赖

绝大多数的服务依赖是套接字依赖。比如服务A 通过一个套接字端口S1 提供自己的服务，其他的服务如果需要服务A，则需要连接S1。因此如果服务A 尚未启动，S1就不存在，其他的服务就会得到启动错误。所以传统地，人们需要先启动服务A，等待它进入就绪状态，再启动其他需要它的服务。Systemd认为，只要我们预先把S1 建立好，那么其他所有的服务就可以同时启动而无需等待服务A 来创建S1 了。如果服务A 尚未启动，那么其他进程向S1 发送的服务请求实际上会被Linux 操作系统缓存，其他进程会在这个请求的地方等待。一旦服务A 启动就绪，就可以立即处理缓存的请求，一切都开始正常运行。

那么服务如何使用由 init 进程创建的套接字呢？

Linux 操作系统有一个特性，当进程调用fork 或者exec 创建子进程之后，所有在父进程中被打开的文件句柄(file descriptor) 都被子进程所继承。套接字也是一种文件句柄，进程A 可以创建一个套接字，此后当进程A 调用 exec 启动一个新的子进程时，只要确保该套接字的close_on_exec 标志位被清空，那么新的子进程就可以继承这个套接字。子进程看到的套接字和父进程创建的套接字是同一个系统套接字，就仿佛这个套接字是子进程自己创建的一样，没有任何区别。

这个特性以前被一个叫做 inetd 的系统服务所利用。Inetd 进程会负责监控一些常用套接字端口，比如Telnet，当该端口有连接请求时，inetd才启动 telnetd 进程，并把有连接的套接字传递给新的telnetd 进程进行处理。这样，当系统没有telnet 客户端连接时，就不需要启动telnetd 进程。Inetd可以代理很多的网络服务，这样就可以节约很多的系统负载和内存资源，只有当有真正的连接请求时才启动相应服务，并把套接字传递给相应的服务进程。

和 inetd 类似，systemd 是所有其他进程的父进程，它可以先建立所有需要的套接字，然后在调用exec 的时候将该套接字传递给新的服务进程，而新进程直接使用该套接字进行服务即可。

•并发启动原理之二：解决 D-Bus 依赖

D-Bus 是 desktop-bus 的简称，是一个低延迟、低开销、高可用性的进程间通信机制。它越来越多地用于应用程序之间通信，也用于应用程序和操作系统内核之间的通信。很多现代的服务进程都使用D-Bus取代套接字作为进程间通信机制，对外提供服务。比如简化Linux 网络配置的NetworkManager 服务就使用D-Bus 和其他的应用程序或者服务进行交互：邮件客户端软件evolution 可以通过D-Bus 从NetworkManager 服务获取网络状态的改变，以便做出相应的处理。

D-Bus 支持所谓"busactivation"功能。如果服务A 需要使用服务 B 的 D-Bus 服务，而服务 B 并没有运行，则 D-Bus 可以在服务 A 请求服务 B 的 D-Bus 时自动启动服务 B。而服务 A 发出的请求会被 D-Bus 缓存，服务 A 会等待服务 B 启动就绪。利用这个特性，依赖D-Bus 的服务就可以实现并行启动。

•并发启动原理之三：解决文件系统依赖

系统启动过程中，文件系统相关的活动是最耗时的，比如挂载文件系统��对文件系统进行磁盘检查（fsck），磁盘配额检查等都是非常耗时的操作。在等待这些工作完成的同时，系统处于空闲状态。那些想使用文件系统的服务似乎必须等待文件系统初始化完成才可以启动。但是systemd 发现这种依赖也是可以避免的。

Systemd 参考了 autofs 的设计思路，使得依赖文件系统的服务和文件系统本身初始化两者可以并发工作。autofs可以监测到某个文件系统挂载点真正被访问到的时候才触发挂载操作，这是通过内核automounter 模块的支持而实现的。比如一个open()系统调用作用在"/misc/cd/file1"的时候，/misc/cd 尚未执行挂载操作，此时 open()调用被挂起等待，Linux 内核通知 autofs，autofs 执行挂载。这时候，控制权返回给open()系统调用，并正常打开文件。

Systemd 集成了 autofs 的实现，对于系统中的挂载点，比如/home，当系统启动的时候，systemd 为其创建一个临时的自动挂载点。在这个时刻/home真正的挂载设备尚未启动好，真正的挂载操作还没有执行，文件系统检测也还没有完成。可是那些依赖该目录的进程已经可以并发启动，他们的open()操作被内建在systemd 中的autofs 捕获，将该open()调用挂起（可中断睡眠状态）。然后等待真正的挂载操作完成，文件系统检测也完成后，systemd将该自动挂载点替换为真正的挂载点，并让open()调用返回。由此，实现了那些依赖于文件系统的服务和文件系统本身同时并发启动。

当然对于"/"根目录的依赖实际上一定还是要串行执行，因为systemd 自己也存放在/之下，必须等待系统根目录挂载检查好。

不过对于类似/home 等挂载点，这种并发可以提高系统的启动速度，尤其是当/home是远程的 NFS 节点，或者是加密盘等，需要耗费较长的时间才可以准备就绪的情况下，因为并发启动，这段时间内，系统并不是完全无事可做，而是可以利用这段空余时间做更多的启动进程的事情，总的来说就缩短了系统启动时间。