Linux 创建自定义服务

利用 systemctl 管理服务

 
老版本中的 linux 对服务的操作是通过 service 来完成的。若创建用户自定义的服务，则需要较为复杂的操作。目前 linux 新的发行版已经内置了 systemctl 来管理服务，比以往更加的方便。

systemctl 常用命令：

启动服务：

systemctl start xxx.service

关闭服务：

systemctl stop xxx.service

重启服务：

systemctl restart xxx.service

设置开机自启：

systemctl enable xxx.service

关闭开机自启：

systemctl disable xxx.service

查看服务状态：

systemctl status xxx.service

查看所有服务：

systemctl list-units --type=service

 

服务脚本编写

 
自定义服务脚本以 service 为后缀，这些 service 文件存放于 /lib/systemd/system 中。我们只需要编写符合标准规范的 service 脚本文件，放在这个文件夹下面即可。

标准的服务文件格式如下（以 redis 为例）：

[Unit]
Description=redis.server
After=network.target

[Service]
Type=forking
PIDFILE=/var/run/redis_6379.pid
ExecStart=/usr/local/redis/bin/redis-server /usr/local/redis/redis.conf
ExecReload=/usr/local/redis/bin/redis-server -s reload
ExecStop=/usr/local/redis/bin/redis-cli -h 192.168.56.100 -p 6379 shutdown
Restart=always
PrivateTmp=true

[Install]
WantedBy=multi-user.target

下面对服务脚本的相关配置和参数进行简单介绍，内容根据 linux 系统中 man systemd.service 用户手册说明经过翻译和整理而得，可能会有一些描述不准确的地方。
 

三个部分

 
服务脚本分为 3 个部分：[Unit] [Service] [Install]
 

Unit

 
Unit 表明该服务的基本信息。systemd 将一个服务称之为一个单元，比较典型的情况是单元 A 要求在单元 B 启动之后再启动。这种设置是通过 Unit 下面的 Requires、After、Before、Wants 来调整的。比如上述场景的编写可以这样（在 A 中编写）：

Requires=B
After=B

这段设置表明了 A 的启动依赖于 B，同时有要求在 B 启动之后启动自己。设置十分简洁。需要注意的是，依赖关系通常用在服务（Service）而不是目标（Target）上。

参数说明：

• Description：服务描述

• Documentation：服务文档

• Before | After：服务启动顺序

  Before=xxx.service，代表本服务在 xxx.service 启动之前启动。

  After=xxx.service，代表本服务在 xxx.service 启动之后启动。

• Requires | Wants：服务依赖关系

  Requires：这个单元启动了，它需要的单元也会被启动；它需要的单元被停止了，这个单元也停止了。

  Wants：推荐使用。这个单元启动了，它需要的单元也会被启动；它需要的单元被停止了，对本单元没有影响。
   

Service

 
Service 是脚本的关键部分，这一部分用于设置一些服务运行时的关键参数。

参数说明：

• Type：设置服务进程的启动方式

  simple（默认值）：systemd 认为该服务将立即启动。服务进程不会 fork。如果该服务要启动其他服务，不要使用此类型启动，除非该服务是 socket 激活型。

  forking：systemd 认为当该服务进程 fork，且父进程退出后服务启动成功。对于常规的守护进程（daemon），除非你确定此启动方式无法满足需求，否则使用此类型启动即可。使用此启动类型应同时指定 PIDFile，以便 systemd 能够跟踪服务的主进程。

  oneshot：这一选项适用于只执行一项任务、随后立即退出的服务。可能需要同时设置 RemainAfterExit=yes 使得 systemd 在服务进程退出之后仍然认为服务处于激活状态。

  notify：与 Type=simple 相同，但约定服务会在就绪后向 systemd 发送一个信号。这一通知的实现由 libsystemd-daemon.so 提供。

  dbus：若以此方式启动，当指定的 BusName 出现在 DBus 系统总线上时，systemd 认为服务就绪。

  idle：systemd 会等待所有任务(Jobs)处理完成后，才开始执行 idle 类型的单元。除此之外，其他行为和 Type=simple 类似。

• PIDFile：服务进程号文件

  采用一个绝对路径的文件名指定守护进程的 PID 文件。当 Type=forking 被设置的时候，建议采取这个设置。当服务启动后，systemd 会读取守护进程的主进程 id。systemd 不会对该文件写入数据。

• BusName：总线名称

  使用一个 D-Bus 的总线名称，作为该服务的可访问名称。当 Type=dbus 的时候，该设置被强制使用。

• BusPolicy：总线策略

  如果该选项被指定，一个自定义的 kdbus 终结点将会被创建，并且会被指定为默认的 dbus 节点安装到服务上。这样的自定义终结点自身持有一个策略规则集合。这些规则将会在总线范围内被强制指定。该选项只有在 kdbus 被激活时有效。

• ExecStart：指定启动服务之星的命令或者脚本

• ExecStartPre | ExecStartPost：指定在 ExecStart 之前或者之后用户自定义执行的命令或者脚本。Type=oneshot 允许指定多个希望顺序执行的用户自定义命令。

• ExecReload：指定重启服务时执行的命令或者脚本

• ExecStop：指定停止服务时执行的命令或者脚本

• ExecStopPost：指定在 ExecStop 之后执行的命令或者脚本。

• PrivateTmp：True 表示给服务分配独立的临时空间

• Restart：这个选项如果被允许，服务重启的时候进程会退出，会通过 systemctl 命令执行清除并重启的操作。

• GuessMainPID：采用 boolean 值，指定 systemd 在无法确切的查明服务的时候是否需要猜测服务的main pid。除非 Type=forking 被采用并且 PIDFile 没有被设置，否则这个选项会被忽略。因为当设置为 Type 的其他选项，或者显示的指定了 PID 文件后，systemd 总是能够知道 main pid。

• RemainAfterExit：默认值为 no，采用 booleean 值，可以是 0、no、off、1、yes、on 等值。它表明服务是否应当被视为激活的，即便当它所有的进程都退出了。简言之，这个设置用于告诉systemd服务是否应当是被视为激活状态，而不管进程是否退出。当为 true 时，即便服务退出，systemd 依然将这个服务视为激活状态，反之则服务停止。

注意：

值得注意的是，在脚本中关于服务启动、重启、关闭的指令需要使用绝对路径，否则会出现无法识别的情况。
 

Install

 
Install 部分为可选，用于设置服务安装的相关信息。

参数说明：

• Alias：为单元提供一个空间分离的附加名字。

• RequiredBy：单元被允许运行需要的一系列依赖单元，RequiredBy 列表从 Require 获得依赖信息。

• WantBy：单元被允许运行需要的弱依赖性单元，WantBy 从 Want 列表获得依赖信息。

• Also：指出和单元一起安装或者被协助的单元。

• DefaultInstance：实例单元的限制，这个选项指定如果单元被允许运行默认的实例。