17.1.2 【Linux】systemd使用的unit分类

systemd 有什么好处？

平行处理所有服务，加速开机流程：旧的 init 启动脚本是“一项一项任务依序启动”的模式，因此不相依的服务也是得要一个一个的等待。但目前我们的硬件主机系统与操作系统几乎都支持多核心架构了，systemd 可以让所有的服务同时启动，因此你会发现到，系统启动的速度变快了！

一经要求就回应的 on-demand 启动方式： systemd 全部就是仅有一只 systemd 服务搭配 systemctl 指令来处理，无须其他额外的指令来支持。不像 systemV 还要 init,chkconfig, service... 等等指令。此外， systemd 由于常驻内存，因此任何要求（on-demand）都可以立即处理后续。

服务相依性的自我检查：由于 systemd 可以自订服务相依性的检查，因此如果 B 服务是架构在 A 服务上面启动的，那当你在没有启动 A 服务的情况下仅手动启动 B 服务时，systemd 会自动帮你启动 A 服务。这样就可以免去管理员得要一项一项服务去分析的麻烦。

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

将多个 daemons 集合成为一个群组：如同 systemV 的 init 里头有个 runlevel 的特色，systemd 亦将许多的功能集合成为一个所谓的 target 项目，这个项目主要在设计操作环境的创建，所以是集合了许多的 daemons，亦即是执行某个 target 就是执行好多个daemon 的意思。

向下相容旧有的 init 服务脚本：基本上， systemd 是可以相容于 init 的启动脚本的，因此，旧的 init 启动脚本也能够通过 systemd 来管理，只是更进阶的 systemd 功能就没有办法支持就是了。

虽然如此，不过 systemd 也是有些地方无法完全取代 init 的！包括：

在 runlevel 的对应上，大概仅有 runlevel 1, 3, 5 有对应到 systemd 的某些 target 类型而已，没有全部对应；

全部的 systemd 都用 systemctl 这个管理程序管理，而 systemctl 支持的语法有限制，不像 /etc/init.d/daemon 就是纯脚本可以自订参数，systemctl 不可自订参数。

如果某个服务启动是管理员自己手动执行启动，而不是使用 systemctl 去启动的（例如你自己手动输入 crond 以启动 crond 服务），那么 systemd 将无法侦测到该服务，而无法进一步管理。

systemd 启动过程中，无法与管理员通过 standard input 传入讯息！因此，自行撰写systemd 的启动设置时，务必要取消互动机制（连通过启动时传进的标准输入讯息也要避免！）

同时 systemd 还有很多特殊的服务类型（type）可以提供更多有趣的功能，首先就得要针对 systemd 管理的 unit 来了解一下。

systemd 的配置文件放置目录

基本上， systemd 将过去所谓的 daemon 执行脚本通通称为一个服务单位（unit），而每种服务单位依据功能来区分时，就分类为不同的类型（type）。基本的类型有包括系统服务、数据监听与交换的插槽档服务（socket）、储存系统状态的快照类型、提供不同类似执行等级分类的操作环境（target）等等。配置文件都放置在下面的目录中：

/usr/lib/systemd/system/：每个服务最主要的启动脚本设置，有点类似以前的 /etc/init.d下面的文件；

/run/systemd/system/：系统执行过程中所产生的服务脚本，这些脚本的优先序要比/usr/lib/systemd/system/ 高！

/etc/systemd/system/：管理员依据主机系统的需求所创建的执行脚本，其实这个目录有点像以前 /etc/rc.d/rc5.d/Sxx 之类的功能！执行优先序又比 /run/systemd/system/ 高。

如果想要修改某个服务启动的设置，应该去 /usr/lib/systemd/system/ 下面修改。

systemd 的 unit 类型分类说明