利用 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:实例单元的限制,这个选项指定如果单元被允许运行默认的实例。
本文介绍了如何在Linux系统中利用systemctl管理自定义服务,包括启动、停止、重启服务和设置开机自启等操作。重点讲解了服务脚本的编写,包括[Unit]、[Service]、[Install]三个部分,以及各个部分的关键参数和配置,帮助读者理解并创建自己的Linux服务。
9392

被折叠的 条评论
为什么被折叠?



