systemctl自定义服务

常用操作

  • 文件位置

    • CentOS 7
      脚本存放在/usr/lib/systemd,有系统(system)和用户(user)之分,需要开机不登陆就能运行的程序,存在系统服务里,即/usr/lib/systemd/system目录下。

    • Ubuntu
      /etc/systemd/system

  • systemctl

    • 检查服务是否开机启动

      systemctl is-enabled docker.service
      
    • 将服务配置成开机启动

      systemctl enable/disable docker.service
      
    • 启动服务

      systemctl start docker.service
      

Unit编写方法

[Unit]
Description=led daemon
After=syslog.target network.target
Wants=network.target
 
[Service]
# 指定目录
WorkingDirectory=/home/witcomm/witposeidon-single-backend/
Type=simple
ExecStart=/home/witcomm/.virtualenvs/witposeidon-single-backend-YxtQLtDF/bin/python /home/witcomm/witposeidon-single-backend/LED_tcp_new.py
# 指定用户
User=witcomm
Restart=always
RestartSec=2

[Install]
# 和前面的 Wants 作用相似,只是后面列出的不是服务所依赖的模块,而是依赖当前服务的模块。
# 上一句看不懂,但是开机自启一定要设置 WantedBy=multi-user.target
WantedBy=multi-user.target
Alias=alias.service
  • Unit段

    • Description:一段描述这个Unit文件的文字,通常只是简短的一句话。
    • Documentation:指定服务的文档,可以是一个或多个文档的URL路径。
    • Requires:依赖的其他Unit列表,列在其中的Unit 模块会在这个服务启动的同时被启动,并且如果其中有任意一个服务启动失败,这个服务也会被终止。
    • Wants:与Requires相似,但只是在被配置的这个 Unit 启动时,触发启动列出的每个 Unit 模块,而不去考虑这些模块启动是否成功。
    • After:与Requires 相似,但会在后面列出的所有模块全部启动完成以后,才会启动当前的服务。
    • Before:与After 相反,在启动指定的任一个模块之前,都会首先确保当前服务已经运行。
    • BindsTo:与Requires 相似,但是一种更强的关联。启动这个服务时会同时启动列出的所有模块,当有模块启动失败时终止当前服务。反之,只要列出的模块全部启动以后,也会自动启动当前服务。并且这些模块中有任意一个出现意外结束或重启,这个服务会跟着终止或重启。
    • PartOf:这是一个 BindTo 作用的子集,仅在列出的任何模块失败或重启时,终止或重启当前服务,而不会随列出模块的启动而启动。
    • OnFailure:当这个模块启动失败时,就自动启动列出的每个模块。
    • Conflicts:与这个模块有冲突的模块,如果列出模块中有已经在运行的,这个服务就不能启动,反之亦然。

    上面这些配置中,除了Description 外,都能够被添加多次。比如前面第一个例子中的After参数在一行中使用空格分隔指定所有值,也可以像第二个例子中那样使用多个After参数,在每行参数中指定一个值。

  • Service段

    • Type:服务的类型,常用的有 simple(默认类型) 和 forking。++默认的 simple 类型可以适应于绝大多数的场景,因此一般可以忽略这个参数的配置++。而如果服务程序启动后会通过 fork 系统调用创建子进程,然后关闭应用程序本身进程的情况,则应该将 Type 的值设置为 forking,否则 systemd 将不会跟踪子进程的行为,而认为服务已经退出。
    • RemainAfterExit:值为 true 或 false(也可以写 yes 或 no),默认为 false。当配置值为 true 时,systemd 只会负责启动服务进程,之后即便服务进程退出了,systemd 仍然会认为这个服务是在运行中的。这个配置主要是提供给一些并非常驻内存,而是启动注册后立即退出然后等待消息按需启动的特殊类型服务使用
    • ExecStart:这个参数是几乎每个 .service 文件都会有的,指定服务启动的主要命令,在每个配置文件中只能使用一次。
    • ExecStartPre:指定在启动执行 ExecStart 的命令前的准备工作,可以有多个,如前面第二个例子中所示,所有命令会按照文件中书写的顺序依次被执行。
    • ExecStartPost:指定在启动执行 ExecStart 的命令后的收尾工作,也可以有多个。
    • TimeoutStartSec:启动服务时的等待的秒数,如果超过这个时间服务任然没有执行完所有的启动命令,则 systemd 会认为服务自动失败。这一配置对于使用 Docker 容器托管的应用十分重要,由于 Docker 第一次运行时可以能会需要从网络下载服务的镜像文件,因此造成比较严重的延时,容易被 systemd 误判为启动失败而杀死。通常对于这种服务,需要将 TimeoutStartSec 的值指定为 0,从而关闭超时检测,如前面的第二个例子。
    • ExecStop:停止服务所需要执行的主要命令。
    • ExecStopPost:指定在 ExecStop 命令执行后的收尾工作,也可以有多个。
    • TimeoutStopSec:停止服务时的等待的秒数,如果超过这个时间服务仍然没有停止,systemd 会使用 SIGKILL 信号强行杀死服务的进程。
      Restart 这个值用于指定在什么情况下需要重启服务进程。常用的值有 no,on-success,on-failure,on-abnormal,on-abort 和 always。默认值为 no,即不会自动重启服务。这些不同的值分别表示了在哪些情况下,服务会被重新启动,参见下表。
    • WorkingDirectory:指定服务的工作目录。
    • RootDirectory:指定服务进程的根目录( / 目录),如果配置了这个参数后,服务将无法访问指定目录以外的任何文件
    • User:指定运行服务的用户,会影响服务对本地文件系统的访问权限。
    • Group:指定运行服务的用户组,会影响服务对本地文件系统的访问权限。

参考地址

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容