Linux Systemd 服务管理教程

发布时间:2024年01月24日

Systemd 简介

历史上,Linux 的启动一直采用init进程。

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

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

这种方法有两个缺点。

  • 启动时间长。init进程是串行启动,只有前一个进程启动完,才会启动下一个进程。
  • 启动脚本复杂。init进程只是执行启动脚本,不管其他事情。脚本需要自己处理各种情况,这往往使得脚本变得很长。

Systemd 就是为了解决这些问题而诞生的。它的设计目标是,为系统的启动和管理提供一套完整的解决方案。根据 Linux 惯例,字母d是守护进程(daemon)的缩写。 Systemd 这个名字的含义,就是它要守护整个系统。

Systemd 是 Linux 系统工具,用来启动守护进程,已成为大多数发行版的标准配置。Systemd 是一系列工具的集合,其作用也远远不仅是启动操作系统,它还接管了后台服务、结束、状态查询,以及日志归档、设备管理、电源管理、定时任务等许多职责,并支持通过特定事件(如插入特定 USB 设备)和特定端口数据触发的 On-demand(按需)任务。Systemd 的后台服务还有一个特殊的身份——它是系统中 PID 值为 1 的进程。

Systemd 架构

Systemd 目录

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

  • /etc/systemd/system:系统或用户自定义的配置文件
  • /run/systemd/system:软件运行时生成的配置文件
  • /usr/lib/systemd/system:系统或第三方软件安装时添加的配置文件。

Systemd 的 Unit 文件

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

Systemd 可以管理所有系统资源,不同的资源统称为 Unit(单位)。

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

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 的功能

# 重新加载一个服务的配置文件
$ sudo systemctl reload nginx.service

# 重载所有修改过的配置文件
$ sudo systemctl daemon-reload

启动服务
$ sudo systemctl start nginx

查看一下该服务的状态
$ sudo systemctl status nginx

停止服务
$ sudo systemctl stop nginx.service

服务停不下来。这时候就不得不"杀进程"了
$ sudo systemctl kill nginx.service

重启服务
$ sudo systemctl restart nginx.service

开机启动 可省略.service
$ sudo systemctl enable nginx
# 等同于
$ sudo ln -s '/usr/lib/systemd/system/nginx.service' '/etc/systemd/system/nginx.service'

Systemd Service Unit 文件结构

注意,键值对的等号两侧不能有空格。

# Stop dance for nginx
# =======================
#
# ExecStop sends SIGSTOP (graceful stop) to the nginx process.
# If, after 5s (--retry QUIT/5) nginx is still running, systemd takes control
# and sends SIGTERM (fast shutdown) to the main process.
# After another 5s (TimeoutStopSec=5), and if nginx is alive, systemd sends
# SIGKILL to all the remaining processes in the process group (KillMode=mixed).
#
# nginx signals reference doc:
# http://nginx.org/en/docs/control.html
#
[Unit]
Description=A high performance web server and a reverse proxy server
Documentation=man:nginx(8)
After=network.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid
TimeoutStopSec=5
KillMode=mixed

[Install]
WantedBy=multi-user.target

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

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

Unit 段

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

Service 段

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

服务生命周期控制相关
  • Type:定义启动时的进程行为,它有以下几种值:
    • Type=simple:默认值,执行ExecStart指定的命令,启动主进程
    • Type=forking:以 fork 方式从父进程创建子进程,创建后父进程会立即退出
    • Type=oneshot:一次性进程,Systemd 会等当前服务退出,再继续往下执行
    • Type=dbus:当前服务通过D-Bus启动
    • Type=notify:当前服务启动完毕,会通知Systemd,再继续往下执行
    • Type=idle:若有其他任务执行完毕,当前服务才会运行
  • RemainAfterExit:值为 true 或 false(默认)。当配置为 true 时,Systemd 只会负责启动服务进程,之后即便服务进程退出了,Systemd 也仍然会认为这个服务还在运行中。这个配置主要是提供给一些并非常驻内存,而是启动注册后立即退出,然后等待消息按需启动的特殊类型服务使用的。
  • ExecStart:启动当前服务的命令
  • ExecStartPre:启动当前服务之前执行的命令
  • ExecStartPos:启动当前服务之后执行的命令
  • ExecReload:重启当前服务时执行的命令
  • ExecStop:停止当前服务时执行的命令
  • ExecStopPost:停止当其服务之后执行的命令
  • RestartSec:自动重启当前服务间隔的秒数
  • Restart:定义何种情况 Systemd 会自动重启当前服务,可能的值包括 always(总是重启)、on-success、on-failure、on-abnormal、on-abort、on-watchdog
  • TimeoutStartSec:启动服务时等待的秒数,这一配置对于使用 Docker 容器而言显得尤为重要,因其第一次运行时可能需要下载镜像,严重延时会容易被 Systemd 误判为启动失败杀死。通常,对于这种服务,将此值指定为 0,从而关闭超时检测
  • TimeoutStopSec:停止服务时的等待秒数,如果超过这个时间仍然没有停止,Systemd 会使用 SIGKILL 信号强行杀死服务的进程
服务上下文配置相关
  • 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 文件中,有时会需要使用到一些与运行环境有关的信息,例如节点 ID、运行服务的用户等。这些信息可以使用占位符来表示,然后在实际运行被动态地替换实际的值。

  • %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 模板文件中表示一个普通的百分号

Install 段

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

  • WantedBy:和 Unit 段的 Wants 作用相似,只有后面列出的不是服务所依赖的模块,而是依赖当前服务的模块。它的值是一个或多个 Target,当前 Unit 激活时(enable)符号链接会放入 /etc/systemd/system 目录下面以 <Target 名> + .wants 后缀构成的子目录中,如 “/etc/systemd/system/multi-user.target.wants/“
  • 一般来说,常用的 Target 有两个:一个是multi-user.target,表示多用户命令行状态;另一个是graphical.target,表示图形用户状态,它依赖于multi-user.target。官方文档有一张非常清晰的 Target 依赖关系图
root@ip-172-31-16-69:/lib/systemd/system# find /etc/systemd/system/* -type d 
/etc/systemd/system/cloud-final.service.wants
/etc/systemd/system/cloud-init.target.wants
/etc/systemd/system/emergency.target.wants
/etc/systemd/system/final.target.wants
/etc/systemd/system/getty.target.wants
/etc/systemd/system/mdmonitor.service.wants
/etc/systemd/system/multi-user.target.wants
/etc/systemd/system/network-online.target.wants
/etc/systemd/system/open-vm-tools.service.requires
/etc/systemd/system/paths.target.wants
/etc/systemd/system/rescue.target.wants
/etc/systemd/system/sleep.target.wants
/etc/systemd/system/snapd.mounts.target.wants
/etc/systemd/system/sockets.target.wants
/etc/systemd/system/sshd-keygen@.service.d
/etc/systemd/system/sysinit.target.wants
/etc/systemd/system/timers.target.wants
  • RequiredBy:和 Unit 段的 Wants 作用相似,只有后面列出的不是服务所依赖的模块,而是依赖当前服务的模块。它的值是一个或多个 Target,当前 Unit 激活时,符号链接会放入 /etc/systemd/system 目录下面以 <Target 名> + .required 后缀构成的子目录中
  • Also:当前 Unit enable/disable 时,同时 enable/disable 的其他 Unit
  • Alias:当前 Unit 可用于启动的别名

Unit 管理

# 列出正在运行的 Unit
$ systemctl list-units

# 列出所有Unit,包括没有找到配置文件的或者启动失败的
$ systemctl list-units --all

# 列出所有没有运行的 Unit
$ systemctl list-units --all --state=inactive

# 列出所有加载失败的 Unit
$ systemctl list-units --failed

# 列出所有正在运行的、类型为 service 的 Unit
$ systemctl list-units --type=service

# 查看 Unit 配置文件的内容
$ systemctl cat docker.service

创建自定义Unit 案例

创建x11服务文件x11.service

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

[Service]
Type=forking
#PIDFile=/root/.vnc/x11vnc.pid
ExecStart=/usr/bin/x11vnc -display :1 -forever -bg -rfbauth /root/.vnc/passwd
#ExecReload=/bin/kill -s HUP $MAINPID
#ExecStop=/bin/kill -s TERM $MAINPID

[Install]
WantedBy=multi-user.target

创建gunicorn服务文件gunicorn.service

[Unit] 
Description=reset snapshot server 
After=network.target 
 
[Service] 
WorkingDirectory=/root/flask 
PIDFile=/root/flask/log/gunicorn.pid 
ExecStart=/usr/local/bin/gunicorn -w 2 -b 0.0.0.0:5000 pro_resnapshot:app 
ExecReload=/bin/kill -s -HUP $MAINPID 
ExecStop=/bin/kill -s TERM $MAINPID 
  
#ExecStart=/bin/echo execstart 
#ExecReload=/bin/echo execreload 
#ExecStop=/bin/echo execstop 
#ExecStartPre=/bin/echo execstartpre 
#ExecStartPost=/bin/echo execstartpost 
#ExecStopPost=/bin/echo execstoppost 
 
Type=simple 
 
[Install] 
WantedBy=multi-user.target

一般我们使用apt或yum安装的软件会自动创建Unit文件, 直接使用systemctl status xxx就可以了, 下图enabled说明是开机启动, 否则systemctl enable xxx设置开机启动

如果没有可以自己创建

  1. 创建Unit文件放入/usr/lib/systemd/system 目录下
  2. 重载配置文件sudo systemctl daemon-reload
  3. 设置开机启动sudo systemctl enable x11
  4. 查看状态sudo systemctl enable x11

日志管理

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

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

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

# 查看所有日志(默认情况下 ,只保存本次启动的日志)
$ sudo journalctl

# 查看内核日志(不显示应用日志):--dmesg 或 -k
$ sudo journalctl -k

# 查看系统本次启动的日志(其中包括了内核日志和各类系统服务的控制台输出):--system 或 -b
$ sudo journalctl -b
$ sudo journalctl -b -0

# 查看上一次启动的日志(需更改设置)
$ sudo journalctl -b -1

# 查看指定服务的日志:--unit 或 -u
$ sudo journalctl -u docker.servcie

# 查看指定服务的日志
$ sudo journalctl /usr/lib/systemd/systemd

# 实时滚动显示最新日志
$ sudo journalctl -f

# 查看指定时间的日志
$ sudo journalctl --since="2012-10-30 18:17:16"
$ sudo journalctl --since "20 min ago"
$ sudo journalctl --since yesterday
$ sudo journalctl --since "2015-01-10" --until "2015-01-11 03:00"
$ sudo journalctl --since 09:00 --until "1 hour ago"

# 显示尾部的最新 10 行日志:--lines 或 -n
$ sudo journalctl -n

# 显示尾部指定行数的日志
$ sudo journalctl -n 20

# 将最新的日志显示在前面
$ sudo journalctl -r -u docker.service

# 改变输出的格式:--output 或 -o
$ sudo journalctl -r -u docker.service -o json-pretty

# 查看指定进程的日志
$ sudo journalctl _PID=1

# 查看某个路径的脚本的日志
$ sudo journalctl /usr/bin/bash

# 查看指定用户的日志
$ sudo journalctl _UID=33 --since today

# 查看某个 Unit 的日志
$ sudo journalctl -u nginx.service
$ sudo journalctl -u nginx.service --since today

# 实时滚动显示某个 Unit 的最新日志
$ sudo journalctl -u nginx.service -f

# 合并显示多个 Unit 的日志
$ journalctl -u nginx.service -u php-fpm.service --since today

# 查看指定优先级(及其以上级别)的日志,共有 8 级
# 0: emerg
# 1: alert
# 2: crit
# 3: err
# 4: warning
# 5: notice
# 6: info
# 7: debug
$ sudo journalctl -p err -b

# 日志默认分页输出,--no-pager 改为正常的标准输出
$ sudo journalctl --no-pager

# 以 JSON 格式(单行)输出
$ sudo journalctl -b -u nginx.service -o json

# 以 JSON 格式(多行)输出,可读性更好
$ sudo journalctl -b -u nginx.serviceqq
 -o json-pretty

# 显示日志占据的硬盘空间
$ sudo journalctl --disk-usage

# 指定日志文件占据的最大空间
$ sudo journalctl --vacuum-size=1G

# 指定日志文件保存多久
$ sudo journalctl --vacuum-time=1years

Systemd 工具集

  • systemctl:用于检查和控制各种系统服务和资源的状态
  • bootctl:用于查看和管理系统启动分区
  • hostnamectl:用于查看和修改系统的主机名和主机信息
  • journalctl:用于查看系统日志和各类应用服务日志
  • localectl:用于查看和管理系统的地区信息
  • loginctl:用于管理系统已登录用户和 Session 的信息
  • machinectl:用于操作 Systemd 容器
  • timedatectl:用于查看和管理系统的时间和时区信息
  • systemd-analyze 显示此次系统启动时运行每个服务所消耗的时间,可以用于分析系统启动过程中的性能瓶颈
  • systemd-ask-password:辅助性工具,用星号屏蔽用户的任意输入,然后返回实际输入的内容
  • systemd-cat:用于将其他命令的输出重定向到系统日志
  • systemd-cgls:递归地显示指定 CGroup 的继承链
  • systemd-cgtop:显示系统当前最耗资源的 CGroup 单元
  • systemd-escape:辅助性工具,用于去除指定字符串中不能作为 Unit 文件名的字符
  • systemd-hwdb:Systemd 的内部工具,用于更新硬件数据库
  • systemd-delta:对比当前系统配置与默认系统配置的差异
  • systemd-detect-virt:显示主机的虚拟化类型
  • systemd-inhibit:用于强制延迟或禁止系统的关闭、睡眠和待机事件
  • systemd-machine-id-setup:Systemd 的内部工具,用于给 Systemd 容器生成 ID
  • systemd-notify:Systemd 的内部工具,用于通知服务的状态变化
  • systemd-nspawn:用于创建 Systemd 容器
  • systemd-path:Systemd 的内部工具,用于显示系统上下文中的各种路径配置
  • systemd-run:用于将任意指定的命令包装成一个临时的后台服务运行
  • systemd-stdio- bridge:Systemd 的内部 工具,用于将程序的标准输入输出重定向到系统总线
  • systemd-tmpfiles:Systemd 的内部工具,用于创建和管理临时文件目录
  • systemd-tty-ask-password-agent:用于响应后台服务进程发出的输入密码请求

查看原文:Linux Systemd 服务管理教程

关注公众号 "字节航海家" 及时获取最新内容

文章来源:https://blog.csdn.net/l475378094/article/details/135746116
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。