systemd 使用的 unit 分类

一起看海

从 CentOS 7.x 后，改用 systemd 启动服务管理机制。好处如下

平行处理所有服务，加速开机流程

init 启动脚本是一项一项依序启动，不想依赖的服务也是一个一个等待启动，systemd 可以让所有服务同时启动，系统启动速度变快了

一经要求就响应的 on-demand 启动方式

systemd 全部只有一个 systemd 服务搭配 systemctl 指令来处理，无需其他额外的指令来支持。

服务相互依赖自我检查

systemd 可以自定义服务相依性检查，当你定义 B 依赖 A 时，你启动 B 服务时，会自动帮你启动 A 服务

依 daemon 功能分类

systemd 旗下管理的服务非常多，先定义所有的服务为一个服务单位（unit），并将 unit 归类到不同的服务类型（type）去。systemd 将服务单位（unit）区分为 service、socket、target、path、snapshot、timer 等多种不同的类型（type），方便管理员的分类与记忆。而旧的 init 仅分为 stand alone 与 super daemon

将多个 saemons 集合成为一个群组

systemd 将许多的功能集合成为一个所谓的 target 项目，只要在设计操作环境的配置，所以是集合了许多的 daemons，执行某个 target 就是执行好多个 daemon

这个概念类似于 systemV 的 init 中的 runlevel

向下兼容旧的 init 服务脚本

但是更进阶的 systemd 功能没有办法支持 init 服务脚本，普通功能还是兼容的

systemd 某些地方无法完全取代 init，如：

- 在 runlevel 的对应上，大概仅有 1、3、4 有对应到 systemd 的某些 target 类型
- 全部的 systemd 都用 systemctl 管理，而systemctl 支持的语法有限制，无法像 `/etc/init.d/daemon` 那样纯脚本可以自定义参数，systemctl 不可自定义参数
- 如果某个服务启动时管理员自己通过程序指令手动启动的（如手动执行 crond），那么 systemd 将无法管理该服务
- systemd 启动过程中，无法与管理员通过 standard input 传入信息，因此，自行编写 systemd 的启动设置时，务必要取消互动机制，连通过启动时传进的标准输入信息也要避免


不过，光是同步启动服务脚本这个工具就可以节省很多开机时间，同时还有很多特殊的服务类型 type 可以提供更多的功能。