|
从 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 可以提供更多的功能。
|
|