当前位置：运维

Systemd入门教程：配置篇

原文链接

通常情况下，当用户自己使用systemd进行管理服务时，需要关注systemd service中的如下几个配置块:

  • Unit: 主要用于配置整个服务的详情信息以及服务依赖，用于快速识别该服务的相关情况以及依赖项目
  • Service: 主要用于配置整个服务生命周期的管理行为
  • Install: 用于配置服务的安装级别，当我们设置服务在Linux的那种级别下启动或开机自启动时会加载该部分(典型的当chkconfig nginx on或者systemctl enable|disable nginx.service时会读取该部分的配置)

Unit 块

Unit 块除了可以简单描述整个服务的相关详情外，还有最重要的一点可以用来管理该服务的启动顺序和启动依赖(必须也得由systemd管理)。

比如通常我们有一些服务，必须依赖一些基础环境(ntpd，rsyslog，network)才能启动成功，或者必须在某个服务后启动，那我们就可以在这里进行配置。

注意: 在Unit 快中，每个指令后都可以指定一个以空格分隔的列表

服务描述

在systemd 的 service 配置中，我们通常会使用如下几个配置项来描述该服务的基本信息:

  • Description: 服务的简单描述
  • Documentation: 指定服务的文档，便于管理员快速追溯，一般可以使用"http://", “https://”, “file:”, “info:”, “man:” 五种 URI 类型

服务依赖管理

systemd 中会有几种服务依赖管理的指令，可能在实际使用过程中会有一些疑惑，有时候功能可能重叠，因此需要根据具体的使用场景进行组合。

  • After: 用于指定该服务在那些服务之后启动 ，停止时正好相反
  • Before: 用于指定该服务在那些服务之前启动，停止时正好相反
  • Requires: 设置该服务必须依赖的其他服务，因此在该服务启动之前，指定的服务列表必须全部在线，否则服务将启动失败或掉线。但如果未设置After和Before指令时，该服务和依赖的服务将会并行的同时启动。注意: 该指令依赖的服务不一定要在整个生命周期都保持一直在线，这取决于其他的检查条件
  • Requisite: 和Requires类似，区别是在该服务启动时，该指令指定的依赖资源必须全部处于启动成功的状态，否则该服务立马失败，并且不会启动那些失败的依赖服务。因此一般建议Requisite和After 一起联合使用会比较好。
  • Wants: Requires的弱化版，当该服务启动时，尽可能的启动该指令指定的服务，但不会影响该服务的启动
  • BindsTo: 和Requires类似，但是依赖性更强，这里列出来的任何服务停止运行或崩溃，该服务将立即被停止。考虑服务的启动依赖，一般会和After一起使用
  • PartOf: 和Requires类似，但仅作用于服务的停止和重启，表示该服务是所列服务的一部分，会随指定服务的启动而启动。注意: 该指令是单向依赖，服务的主动的重启不会影响其他

Service 块

毋庸置疑的是，我们通常使用systemd 最初的想法是用来启动和停止进程，因此，整个systemd最核心的部分也就在 Service 块了，因此我们需要对该部分有很熟悉的理解。

基本指令

  • Type: 指定进程的启动类型，必须设为 simple, exec, forking, oneshot, dbus, notify, idle 之一。常用的几种如下
    • simple: 一般没有其他指令时，为默认值，表示ExecStart后的指令为主进程，主进程启动后服务即启动成功。如果进程需要为其他进程提供服务，需要通过socket来进行
    • exec: 同simple类似，但是表示该服务的主服务进程执行完成之后，才真正启动成功。
    • forking: 标识在使用ExecStart后的指令启动程序后，会进行fork()的系统调用。传统Unix中守护进程的经典做法，如果使用此类型，建议设置PIDFile=来指定该服务的主进程。比如nginx进程的daemon方式，主进程执行完成后，至少有1个进程在运行，此时服务状态会变成active状态
    • oneshot: 同simple类似，但是表示只有在该服务的主服务进程退出之后，才真正执行成功。一般用于执行一次性任务(配置RemainAfterExit=yes设置可停止的一次性服务)
  • PIDFile: 指定该服务的PID文件路径。systemd会在启动后读取主服务进程的PID，并记录在MAINPID变量中，在停止服务后，会主动进行删除该文件
  • KillMode: 指定停止服务时，杀死进程的方式，必须设为 control-group, process, mixed, none之一。(process表示仅杀死主进程;mixed表示向主进程发SIGTERM信号，然后想服务内cgroup的其他进程发SIGKILL信号;none表示仅执行ExecStop动作，而不杀死进程)

注意: 建议对长时间持续运行的服务尽可能使用 Type=simple；如果有master/slave进程的建议使用 Type=forking

环境变量初始化

通常我们的服务主进程可能会有比较多的参数，建议的做法是使用环境变量方式进行维护对应的参数，而在 systemd 中可支持K/V和配置文件方式来进行设置。

  • Environment: 指定Key=Value 的环境配置
  • EnvironmentFile: 指定包含key=value 的配置文件

注意: 通常情况下，我们会看到EnvironmentFile=-filename 和EnvironmentFile=filename 的写法，前者表示可忽略，即当文件不存在或环境变量加载失败时也不影响后续的处理逻辑。(在etcd的高版本里，大部分参数采用了环境变量加载的方式，可见未来通过环境变量来控制服务的启动参数已经是趋势)

进程生命周期管理

整个进程的生命周期是从准备启动进程开始到整个进程结束的过程管理。通常情况下，可以包含为如下几个环节:

  • ExecStartPre: 启动前， 该指令可用于在进程启动前加载一些列的基础环境以及初始化检查机制
  • ExecStart: 启动逻辑， 该指令用于启动进程的核心逻辑
  • ExecStartPost: 启动后， 该指令用于在启动进程后进行回调的相关操作
  • ExecReload: 热加载， 该指令用于对进程进行热加载，通常情况用于 配置变更后的热重启(/bin/kill -s HUP $MAINPID)
  • ExecStop: 停止， 该指令用于对进程执行指定的停止操作，通常情况下用于进行进程的优雅停止(/bin/kill -s TERM $MAINPID)
  • ExecStopPost: 停止后， 该指令用于在进程停止后，进行一些列的资源释放和等待操作，因为通常情况当进程停止后，相关资源不能立即释放，因为服务不算真正呗停止，如果此时认为进程已停止而强制做一些操作，可能会影响到相关服务处理逻辑
  • TimeoutStopSec: 停止超时时间， 指定服务停止后的超时时间，一般在通知服务是会使用SIGTERM信号，待超时时间内资源未释放，将使用SIGKILL进行强制杀死

重启策略

  • Restart: 当服务进程 正常退出、异常退出、被杀死、超时的时候， 是否重新启动该服务。
  • RestartSec: 多久后重启
  • StartLimitBurst: 启动的最大次数限制，超过后停止继续重启
  • StartLimitInterval: 启动时间的最大间隔

所谓"服务进程" 是指 ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, ExecReload=中设置的进程。 当进程是由于 systemd 的正常操作(例如 systemctl stop|restart)而被停止时， 该服务不会被重新启动。 所谓"超时"可以是看门狗的"keep-alive ping"超时， 也可以是 systemctl start|reload|stop 操作超时.

可选值如下:

  • no:默认值，不会重启
  • on-success: 服务进程正常退出(退出码为"0"， 或者进程收到 SIGHUP, SIGINT, SIGTERM, SIGPIPE 信号之一， 并且 退出码符合 SuccessExitStatus= 的设置)时进行重启
  • on-failure: 仅在服务进程异常退出(退出码不为"0"， 或者 进程被强制杀死(包括 “core dump"以及收到 SIGHUP, SIGINT, SIGTERM, SIGPIPE 之外的其他信号)， 或者进程由于 看门狗超时 或者 systemd 的操作超时 而被杀死)时重启
  • always: 无条件重启

资源限制

通常情况下，我们会对目标服务或进程进行一定资源的限制，以防止服务bug导致的整个系统资源耗尽。

在systemd 中，可以使用如下指令进行简单的资源限制:

  • LimitCPU: 限制CPU使用时长(秒)，等同ulimit -t
  • LimitNOFILE: 限制进程使用的文件描述符数量，等同ulimit -n
  • LimitNPROC: 限制进程的数量，等同于ulimit -u

注意: 一般为防止服务导致的系统过载，会对进程设置一些资源限制

计算资源调度

  • CPUSchedulingPolicy: 设置CPU的调度策略可设为 other, batch, idle, fifo, rr 之一
  • CPUSchedulingPriority: 设置CPU调度的优先级，取决于调度策略
  • CPUAffinity: 设置CPU的亲和性，可以指定cpu的编号，比如0,1

Install 块

在systemd 的服务管理中，install块主要包含了单元的启用信息。只有systemctl 的enable/disable 指令会调用该部分内容。

  • Alias: 指定服务的别名信息
  • WantedBy/RequiredBy: 设置启用服务的依赖服务

举例

[Unit]


Description=Docker CE Binary Release.


Documentation=https://docs.docker.com


Documentation=https://download.docker.com/linux/static/stable/x86_64/


After=network-online.target firewalld.service


Wants=network-online.target


[Service]


Type=notify


Environment="WELCOME=BGBiao Docker Base Environment."


ExecStartPre=/bin/echo ${WELCOME}


ExecStart=/usr/local/sbin/dockerd  $DOCKER_NETWORK_OPTIONS --live-restore --data-root /opt/data/docker


ExecStartPost=/usr/sbin/iptables -P FORWARD ACCEPT


ExecReload=/bin/kill -s HUP ${MAINPID}


ExecStop=/bin/kill -s TERM ${MAINPID}


ExecStopPost=/usr/bin/sleep 3


LimitNOFILE=100


LimitNPROC=3000


LimitCORE=infinity


TimeoutStartSec=0


Delegate=yes


KillMode=process


Restart=always


StartLimitBurst=3


StartLimitInterval=60s


[Install]


WantedBy=multi-user.target

评论
一些有趣的事儿