[toc]

Systemd 概述

Systemd 简介

历史上，Linux 的启动一直采用 init 进程。这种方法有两个缺点。

一是启动时间长。init进程是串行启动，只有前一个进程启动完，才会启动下一个进程。

二是启动脚本复杂。init进程只是执行启动脚本，不管其他事情。脚本需要自己处理各种情况，这往往使得脚本变得很长。

下面的命令用来启动服务。

$ sudo /etc/init.d/apache2 start
# 或者
$ service apache2 start

Systemd 就是为了解决这些问题而诞生的,字母d是守护进程（daemon）的缩写

Systemd 是一系列工具的集合，其作用也远远不仅是启动操作系统，它还接管了后台服务、结束、状态查询，以及日志归档、设备管理、电源管理、定时任务等许多职责，并支持通过特定事件（如插入特定 USB 设备）和特定端口数据触发的 On-demand（按需）任务。

Systemd 的后台服务还有一个特殊的身份——它是系统中 PID 值为 1 的进程。

  1. 更少的进程

Systemd 提供了 服务按需启动 的能力，使得特定的服务只有在真定被请求时才启动。

  1. 允许更多的进程并行启动

在 SysV-init 时代，将每个服务项目编号依次执行启动脚本。Ubuntu 的 Upstart 解决了没有直接依赖的启动之间的并行启动。而 Systemd 通过 Socket 缓存、DBus 缓存和建立临时挂载点等方法进一步解决了启动进程之间的依赖，做到了所有系统服务并发启动。对于用户自定义的服务，Systemd 允许配置其启动依赖项目，从而确保服务按必要的顺序运行。

  1. 使用 CGroup 跟踪和管理进程的生命周期

在 Systemd 之间的主流应用管理服务都是使用 进程树 来跟踪应用的继承关系的，而进程的父子关系很容易通过 两次 fork 的方法脱离。

而 Systemd 则提供通过 CGroup 跟踪进程关系，引补了这个缺漏。通过 CGroup 不仅能够实现服务之间访问隔离，限制特定应用程序对系统资源的访问配额，还能更精确地管理服务的生命周期。

  1. 统一管理服务日志

Systemd 是一系列工具的集合， 包括了一个专用的系统日志管理服务：Journald。这个服务的设计初衷是克服现有 Syslog 服务的日志内容易伪造和日志格式不统一等缺点，Journald 用 二进制格式 保存所有的日志信息，因而日志内容很难被手工伪造。Journald 还提供了一个 journalctl 命令来查看日志信息，这样就使得不同服务输出的日志具有相同的排版格式， 便于数据的二次处理。

Systemd 架构

img

Unit 文件

前面说到Systemd 可以管理所有系统资源，那它所管理不同的资源统称为 Unit（单位）。

在 Systemd 的生态圈中，Unit 文件统一了过去各种不同系统资源配置格式，例如服务的启/停、定时任务、设备自动挂载、网络配置、虚拟内存配置等。而 Systemd 通过不同的文件后缀来区分这些配置文件。

  1. Systemd 支持的 12 种 Unit 文件类型
  • .automount：用于控制自动挂载文件系统，相当于 SysV-init 的 autofs 服务
  • .device：对于 /dev 目录下的设备，主要用于定义设备之间的依赖关系
  • .mount：定义系统结构层次中的一个挂载点，可以替代过去的 /etc/fstab 配置文件
  • .path：用于监控指定目录或文件的变化，并触发其它 Unit 运行
  • .scope：这种 Unit 文件不是用户创建的，而是 Systemd 运行时产生的，描述一些系统服务的分组信息
  • .service：封装守护进程的启动、停止、重启和重载操作，是最常见的一种 Unit 文件
  • .slice：用于表示一个 CGroup 的树，通常用户不会自己创建这样的 Unit 文件
  • .snapshot：用于表示一个由 systemctl snapshot 命令创建的 Systemd Units 运行状态快照
  • .socket：监控来自于系统或网络的数据消息，用于实现基于数据自动触发服务启动
  • .swap：定义一个用户做虚拟内存的交换分区
  • .target：用于对 Unit 文件进行逻辑分组，引导其它 Unit 的执行。它替代了 SysV-init 运行级别的作用，并提供更灵活的基于特定设备事件的启动方式
  • .timer：用于配置在特定时间触发的任务，替代了 Crontab 的功能
  1. Systemd 目录

Unit 文件按照 Systemd 约定，应该被放置指定的三个系统目录之一中。这三个目录是有优先级的，如下所示，越靠上的优先级越高。因此，在三个目录中有同名文件的时候，只有优先级最高的目录里的那个文件会被使用。

  • /etc/systemd/system：系统或用户自定义的配置文件

  • /run/systemd/system：软件运行时生成的配置文件

  • /usr/lib/systemd/system：系统或第三方软件安装时添加的配置文件。

    CentOS 7：Unit 文件指向该目录

    ubuntu 16：被移到了 /lib/systemd/system

Systemd 默认从目录 /etc/systemd/system/ 读取配置文件。但是，里面存放的大部分文件都是符号链接，指向目录 /usr/lib/systemd/system/，真正的配置文件存放在那个目录。

  1. Unit 和 Target

Unit 是 Systemd 管理系统资源的基本单元，可以认为每个系统资源就是一个 Unit，并使用一个 Unit 文件定义。在 Unit 文件中需要包含相应服务的描述、属性以及需要运行的命令。

Target 是 Systemd 中用于指定系统资源启动组的方式，相当于 SysV-init 中的运行级别。

简单说，Target 就是一个 Unit 组，包含许多相关的 Unit 。启动某个 Target 的时候，Systemd 就会启动里面所有的 Unit。从这个意义上说，Target 这个概念类似于”状态点”，启动某个 Target 就好比启动到某种状态。

Unit 内容

Unit 文件结构

[Unit]
Description=Hello World
After=docker.service
Requires=docker.service
[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill busybox1
ExecStartPre=-/usr/bin/docker rm busybox1
ExecStartPre=/usr/bin/docker pull busybox
ExecStart=/usr/bin/docker run --name busybox1 busybox /bin/ sh -c "while true; do echo Hello World; sleep 1; done"
ExecStop="/usr/bin/docker stop busybox1"
ExecStopPost="/usr/bin/docker rm busybox1"
[Install]
WantedBy=multi-user.target

如上所示，Systemd 服务的 Unit 文件可以分为三个配置区段：

  • Unit 和 Install 段：所有 Unit 文件通用，用于配置服务（或其它系统资源）的描述、依赖和随系统启动的方式
  • Service 段：服务（Service）类型的 Unit 文件（后缀为 .service）特有的，用于定义服务的具体管理和操作方法

Unit 段

  • Description：描述这个 Unit 文件的信息
  • Documentation：指定服务的文档，可以是一个或多个文档的 URL 路径
  • Requires：依赖的其它 Unit 列表(有多个unit 用空格 隔开, 以下参数均适用)，列在其中的 Unit 模板会在这个服务启动时的同时被启动。并且，如果其中任意一个服务启动失败，这个服务也会被终止
  • Wants：与 Requires 相似，但只是在被配置的这个 Unit 启动时，触发启动列出的每个 Unit 模块，而不去考虑这些模板启动是否成功
  • After：与 Requires 相似，但是在后面列出的所有模块全部启动完成以后，才会启动当前的服务
  • Before：与 After 相反，在启动指定的任务一个模块之间，都会首先确证当前服务已经运行
  • BindsTo：与 Requires 相似，失败时失败，成功时成功，但是在这些模板中有任意一个出现意外结束或重启时，这个服务也会跟着终止或重启
  • PartOf：一个 Bind To 作用的子集，仅在列出的任务模块失败或重启时，终止或重启当前服务，而不会随列出模板的启动而启动
  • OnFailure：当这个模板启动失败时，就会自动启动列出的每个模块
  • Conflicts：与这个模块有冲突的模块，如果列出的模块中有已经在运行的，这个服务就不能启动，反之亦然

Install 段

这部分配置的目标模块通常是特定运行目标的 .target 文件，用来使得服务在系统启动时自动运行。这个区段可以包含三种启动约束：

  • WantedBy：和 Unit 段的 Wants 作用相似，只有后面列出的不是服务所依赖的模块，而是依赖当前服务的模块。它的值是一个或多个 Target，当前 Unit 激活时（enable）符号链接会放入 /etc/systemd/system 目录下面以 <Target 名> + .wants 后缀构成的子目录中，如 /etc/systemd/system/multi-user.target.wants/
  • RequiredBy：和 Unit 段的 Wants 作用相似，只有后面列出的不是服务所依赖的模块，而是依赖当前服务的模块。它的值是一个或多个 Target，当前 Unit 激活时，符号链接会放入 /etc/systemd/system 目录下面以 <Target 名> + .required 后缀构成的子目录中
  • Also：当前 Unit enable/disable 时，同时 enable/disable 的其他 Unit
  • Alias：当前 Unit 可用于启动的别名

Service 段

用来 Service 的配置，只有 Service 类型的 Unit 才有这个区块。它的主要字段分为服务生命周期和服务上下文配置两个方面。

  1. 服务生命周期控制相关

  • Type：定义启动时的进程行为，它有以下几种值：

    • Type=simple：默认值，执行ExecStart指定的命令，启动主进程

    • Type=forking：以 fork 方式从父进程创建子进程，创建后父进程会立即退出

    • Type=oneshot：一次性进程，Systemd 会等当前服务退出，再继续往下执行

    • Type=dbus：当前服务通过D-Bus启动

    • Type=notify：当前服务启动完毕，会通知Systemd，再继续往下执行

    • Type=idle：若有其他任务执行完毕，当前服务才会运行

      type 常用的是simple和forking, 他们不能混用,

      simple适用于前台执行的命令, 例如启动Redis, RocketMQ

      fork适用于后台执行的命令, 有守护进程的, 例如Nginx

      systemd service 之：服务配置文件编写 (2) | 骏马金龙 (junmajinlong.com)

  • RemainAfterExit：值为 true 或 false（默认）。当配置为 true 时，Systemd 只会负责启动服务进程，之后即便服务进程退出了，Systemd 也仍然会认为这个服务还在运行中。这个配置主要是提供给一些并非常驻内存，而是启动注册后立即退出，然后等待消息按需启动的特殊类型服务使用的。

  • ExecStart：启动当前服务的命令

  • ExecStartPre：启动当前服务之前执行的命令

  • ExecStartPost：启动当前服务之后执行的命令

  • ExecReload：重启当前服务时执行的命令

  • ExecStop：停止当前服务时执行的命令

  • ExecStopPost：停止当其服务之后执行的命令

  • RestartSec：自动重启当前服务间隔的秒数

  • Restart：定义何种情况 Systemd 会自动重启当前服务，可能的值包括 always（总是重启）、on-success、on-failure、on-abnormal、on-abort、on-watchdog

  • TimeoutStartSec：启动服务时等待的秒数，这一配置对于使用 Docker 容器 而言显得尤为重要，因其第一次运行时可能需要下载镜像，严重延时会容易被 Systemd 误判为启动失败杀死。通常，对于这种服务，将此值指定为 0，从而关闭超时检测

  • TimeoutStopSec：停止服务时的等待秒数，如果超过这个时间仍然没有停止，Systemd 会使用 SIGKILL 信号强行杀死服务的进程

  1. 服务上下文配置相关
  • Environment：为服务指定环境变量
  • EnvironmentFile：指定加载一个包含服务所需的环境变量的列表的文件，文件中的每一行都是一个环境变量的定义
  • Nice：服务的进程优先级，值越小优先级越高，默认为 0。其中 -20 为最高优先级，19 为最低优先级
  • WorkingDirectory：指定服务的工作目录
  • RootDirectory：指定服务进程的根目录（/ 目录）。如果配置了这个参数，服务将无法访问指定目录以外的任何文件
  • User：指定运行服务的用户
  • Group：指定运行服务的用户组
  • MountFlags：服务的 Mount Namespace 配置，会影响进程上下文中挂载点的信息，即服务是否会继承主机上已有挂载点，以及如果服务运行执行了挂载或卸载设备的操作，是否会真实地在主机上产生效果。可选值为 shared、slaved 或 private
    • shared：服务与主机共用一个 Mount Namespace，继承主机挂载点，且服务挂载或卸载设备会真实地反映到主机上
    • slave：服务使用独立的 Mount Namespace，它会继承主机挂载点，但服务对挂载点的操作只有在自己的 Namespace 内生效，不会反映到主机上
    • private：服务使用独立的 Mount Namespace，它在启动时没有任何任何挂载点，服务对挂载点的操作也不会反映到主机上
  • LimitCPU / LimitSTACK / LimitNOFILE / LimitNPROC 等：限制特定服务的系统资源量，例如 CPU、程序堆栈、文件句柄数量、子进程数量等

注意：如果在 ExecStart、ExecStop 等属性中使用了 Linux 命令，则必须要写出完整的绝对路径。对于 ExecStartPre 和 ExecStartPost 辅助命令，若前面有个 “-” 符号，表示忽略这些命令的出错。因为有些 “辅助” 命令本来就不一定成功，比如尝试清空一个文件，但文件可能不存在。

Unit 文件占位符和模板

Unit 模板

在现实中，往往有一些应用需要被复制多份运行。例如，用于同一个负载均衡器分流的多个服务实例，或者为每个 SSH 连接建立一个独立的 sshd 服务进程。它们只是一个参数的区别, 如果写很多份文件难以维护, 所以可以通过参数的方式的传入unit文件

Unit 模板文件的写法与普通的服务 Unit 文件基本相同，不过 Unit 模板的文件名是以 @ 符号结尾的。通过模板启动服务实例时，需要在其文件名的 @ 字符后面附加一个参数字符串。

例如:

模版Unit文件: apache@.service

使用: systemctl start apache@8080.service # 这样就启动了一个端口是8080的服务

apache@.service 模板, 其中 %i 就是占位符

[Unit]
Description=My Advanced Service Template
After=etcd.service docker.service
[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill apache%i
ExecStartPre=-/usr/bin/docker rm apache%i
ExecStartPre=/usr/bin/docker pull coreos/apache
ExecStart=/usr/bin/docker run --name apache%i -p %i:80 coreos/apache /usr/sbin/apache2ctl -D FOREGROUND
ExecStartPost=/usr/bin/etcdctl set /domains/example.com/%H:%i running
ExecStop=/usr/bin/docker stop apache1
ExecStopPost=/usr/bin/docker rm apache1
ExecStopPost=/usr/bin/etcdctl rm /domains/example.com/%H:%i
[Install]
WantedBy=multi-user.target

Systemd 在运行服务时，总是会先尝试找到一个完整匹配的 Unit 文件，如果没有找到，才会尝试选择匹配模板。

例如上面的命令，System 首先会在约定的目录下寻找名为 apache@8080.service 的文件，如果没有找到，而文件名中包含 @ 字符，它就会尝试去掉后缀参数匹配模板文件。对于 apache@8080.service ，systemd 会找到 apache@.service 模板文件，并通过这个模板文件将服务实例化。

Unit 文件占位符

既然能传参, 有哪些占位符可以使用呢? 如下:

  • %n：完整的 Unit 文件名字，包括 .service 后缀名
  • %p：Unit 模板文件名中 @ 符号之前的部分，不包括 @ 符号
  • %i：Unit 模板文件名中 @ 符号之后的部分，不包括 @ 符号和 .service 后缀名
  • %t：存放系统运行文件的目录，通常是 “run”
  • %u：运行服务的用户，如果 Unit 文件中没有指定，则默认为 root
  • %U：运行服务的用户 ID
  • %h：运行服务的用户 Home 目录，即 %{HOME} 环境变量的值
  • %s：运行服务的用户默认 Shell 类型，即 %{SHELL} 环境变量的值
  • %m：实际运行节点的 Machine ID，对于运行位置每个的服务比较有用
  • %b：Boot ID，这是一个随机数，每个节点各不相同，并且每次节点重启时都会改变
  • %H：实际运行节点的主机名
  • %v：内核版本，即 “uname -r” 命令输出的内容
  • %%：在 Unit 模板文件中表示一个普通的百分号

系统管理命令

前面说了这么多, 可知道Systemd 并不是一个命令，而是一组命令，涉及到系统管理的方方面面。

  • systemctl是 Systemd 的主命令，用于管理系统。

    几个常用命令

    systemctl start nginx.server # 依次启动定义在 Unit 文件中的 ExecStartPre、ExecStart 和 ExecStartPost 命令
systemctl status nginx.server # 查看服务状态
systemctl stop nginx.server # 依次停止定义在 Unit 文件中的 ExecStopPre、ExecStop 和 ExecStopPost 命令
systemctl enable nginx.server # 在 /etc/systemd/system/ 建立服务的符号链接，指向 /usr/lib/systemd/system/ 中 , 并设置为服务自启动
systemctl disable nginx.server # 取消服务开机启动
systemctl daemon-reload # 刷新 Unit 文件, 更新unit文件后需要执行

  • systemd-analyze命令用于查看启动耗时。

  • hostnamectl命令用于查看当前主机的信息。

  • localectl命令用于查看本地化设置。

  • timedatectl命令用于查看当前时区设置。

  • loginctl命令用于查看当前登录的用户。

日志管理

Systemd 通过其标准日志服务 Journald 提供的配套程序 journalctl 将其管理的所有后台进程打印到 std:out（即控制台）的输出重定向到了日志文件。

Systemd 的日志文件是二进制格式的，必须使用 Journald 提供的 journalctl 来查看，默认不带任何参数时会输出系统和所有后台进程的混合日志。

默认日志最大限制为所在文件系统容量的 10%，可以修改 /etc/systemd/journald.conf 中的 SystemMaxUse 来指定该最大限制。

查看所有日志（默认情况下 ，只保存本次启动的日志）
journalctl

有时候启动服务时, 报错了, 就会提示应该用什么命令查看日志

[xiaokj01@master bin]$ systemctl start namesrv.service
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to manage system services or units.
Authenticating as: xiaokj01
Password:
==== AUTHENTICATION COMPLETE ===

Job for namesrv.service failed because a timeout was exceeded. See "systemctl status namesrv.service" and "journalctl -xe" for details.

Unit 案例

nginx

[Service]
#这里Type一定要写forking
Type=forking
PIDFile=/usr/local/openresty/nginx/logs/nginx.pid
ExecStartPre=/usr/local/openresty/nginx/sbin/nginx -t
ExecStart=/usr/local/openresty/nginx/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

RocketMQ

文件: /lib/systemd/system/rocketMQ.service

[Unit]
Description=rocketMq启动服务
After=network.target rocketMQBroker.service
Requires=rocketMQBroker.service

[Service]

#这里Type一定要写simple
Type=simple

#ExecStart和ExecStop分别在systemctl start和systemctl stop时候调动
ExecStart=/home/xiaokj01/soft/rocketmq-all-4.8.0-bin-release/bin/mqnamesrv

ExecStop=/home/xiaokj01/soft/rocketmq-all-4.8.0-bin-release/bin/mqshutdown namesrv

[Install]
WantedBy=multi-user.target

文件: /lib/systemd/system/rocketMQBroker.service

[Unit]
Description=rocketMq的broker服务
After=network.target
BindsTo=rocketMQ.service
Before=rocketMQ.service

[Service]

#这里Type一定要写simple
Type=simple

#ExecStart和ExecStop分别在systemctl start和systemctl stop时候调动
ExecStart=/home/xiaokj01/soft/rocketmq-all-4.8.0-bin-release/bin/mqbroker -c /home/xiaokj01/soft/rocketmq-all-4.8.0-bin-release/conf/broker.conf

ExecStop=/home/xiaokj01/soft/rocketmq-all-4.8.0-bin-release/bin/mqshutdown broker

[Install]
WantedBy=multi-user.target

这里把 broker和nameserver 做了依赖关系, 启动 rocketMQ.service 文件 就可以一键启动 MQ

这里只做了 单nameserver和单broker的场景, 如果需要做集群处理, 应该可以使用模版的方式, 把参数传进去可以实现

如果不想一键启动, 分开使用(毕竟集群部署下, nameserver和broker不一定会放在一起), 把After, BindsTo 等限制条件删除就行

RocketMQ系列：使用systemd管理nameserver和broker_rocketmq systemd_公众号-测试生财的博客-CSDN博客

可能是史上最全面易懂的 Systemd 服务管理教程 —-全面但错误单词较多

Systemd 入门教程：命令篇 - 阮一峰的网络日志 (ruanyifeng.com)

systemd service 之：服务配置文件编写 (2) | 骏马金龙 (junmajinlong.com)

干货分享 | Systemd 技术原理&实践（上） - 知乎 (zhihu.com)

八卦: systemd 为什么会有那么大的争议？ - 知乎 (zhihu.com)