Systemctl详细理解及常用命令(转载)

一、systemctl理解

Linux 服务管理两种方式service和systemctl

systemd是Linux系统最新的初始化系统(init),作用是提高系统的启动速度,尽可能启动较少的进程,尽可能更多进程并发启动。

systemd对应的进程管理命令是systemctl

1. systemctl命令兼容了service

即systemctl也会去/etc/init.d目录下,查看,执行相关程序

systemctl start redis
systemctl stop redis
# 开机自启动
systemctl enable redis

2. systemctl命令管理systemd的资源Unit

systemd的Unit放在目录/usr/lib/systemd/system(Centos)或/etc/systemd/system(Ubuntu)

主要有四种类型文件.mount,.service,.target,.wants 

.mount文件

.mount文件定义了一个挂载点,[Mount]节点里配置了What,Where,Type三个数据项

等同于以下命令:
mount -t hugetlbfs /dev/hugepages hugetlbfs

 .service文件

.service文件定义了一个服务,分为[Unit],[Service],[Install]三个小节

[Unit]
Description:描述,
After:在network.target,auditd.service启动后才启动
ConditionPathExists: 执行条件

[Service]
EnvironmentFile:变量所在文件
ExecStart: 执行启动脚本
Restart: fail时重启

[Install]
Alias:服务别名
WangtedBy: 多用户模式下需要的

.target文件 

.wants文件

 .wants文件定义了要执行的文件集合,每次执行,.wants文件夹里面的文件都会执行

二、常用命令

1.查看版本号

systemctl –-version

2.管理服务(unit)

systemctl 提供了一组子命令来管理单个的 unit,其命令格式为:

systemctl [command] [unit]

command 主要有:
start:立刻启动后面接的 unit。
stop:立刻关闭后面接的 unit。
restart:立刻关闭后启动后面接的 unit,亦即执行 stop 再 start 的意思。
reload:不关闭 unit 的情况下,重新载入配置文件,让设置生效。
enable:设置下次开机时,后面接的 unit 会被启动。
disable:设置下次开机时,后面接的 unit 不会被启动。
status:目前后面接的这个 unit 的状态,会列出有没有正在执行、开机时是否启动等信息。
is-active:目前有没有正在运行中。
is-enable:开机时有没有默认要启用这个 unit。
kill :不要被 kill 这个名字吓着了,它其实是向运行 unit 的进程发送信号。
show:列出 unit 的配置。
mask:注销 unit,注销后你就无法启动这个 unit 了。
unmask:取消对 unit 的注销。

我们先通过 etcd.service 来观察服务类型 unit 的基本信息:

输出内容的第一行是对 unit 的基本描述。

第二行中的 Loaded 描述操作系统启动时会不会启动这个服务,enabled 表示开机时启动,disabled 表示开机时不启动。而启动该服务的配置文件路径为:/lib/systemd/system/etcd.service。

第三行 中的 Active 描述服务当前的状态,active (running) 表示服务正在运行中。如果是 inactive (dead) 则表示服务当前没有运行。后面则是服务的启动时间。

第四行的 Docs 提供了在线文档的地址。

下面的 Main PID 表示进程的 ID,接下来是任务的数量,占用的内存和 CPU 资源。

再下面的 Cgroup 描述的是 cgrpup 相关的信息,笔者会在后续的文章中详细的介绍。

最后是输出的日志信息。

  • 关于 unit 的启动状态,除了 enable 和 disable 之外还有:

static:这个 unit 不可以自己启动,不过可能会被其它的 enabled 的服务来唤醒。

mask:这个 unit 无论如何都无法被启动!因为已经被强制注销。可通过 systemctl unmask 改回原来的状态。

  • 关于 unit 的运行状态 Active,除了 active 和 inactive 之外还有:

active (exited):仅执行一次就正常结束的服务,目前并没有任何程序在系统中执行。举例来说,开机或者是挂载时才会进行一次的 quotaon 功能,就是这种模式! Quotaon 不需要一直执行,只在执行一次之后,就交给文件系统去自行处理。通常用 bash shell 写的小型服务,大多是属于这种类型。

active (waiting):正在执行当中,不过还再等待其他的事件才能继续处理。举例来说,打印的相关服务就是这种状态。

  • enable 和 disable 操作

比如我们为 etcd 服务创建了配置文件 /lib/systemd/system/etcd.service,然后执行 enable 命令:

systemctl enable etcd.service

所谓的 enable 就是在 multi-user.target.wants 下面创建了一个链接文件:

至于为什么会链接到 multi-user.target.wants 目录下,则是由 etcd.server 文件中的配置信息决定的。

  • 查看 unit 的配置

使用 show 子命令可以查看 unit 的详细配置情况:

systemctl show etcd.service
  • 注销与反注销 unit

如果我们想暂时的禁用某个 unit,比如 etcd.service,可以注销这个 unit,注销之后就无法再启动这个服务了:

systemctl mask etcd.service

从上图中的输出我们可以看到,所谓的注销就是把 etcd.service 文件链接到 /dev/null 这个空设备中去了。所以就无法再启动该服务了。下面我们尝试执行一次反注销:

systemctl unmask etcd.service

unmask 操作就是删除掉 mask 操作中创建的链接。

  • 查看系统上的 unit

systemctl 提供了子命令可以查看系统上的 unit,命令格式为:

systemctl [command] [--type=TYPE] [--all]

command 有:

list-units:列出当前已经启动的 unit,如果添加 -all 选项会同时列出没有启动的 unit。

list-unit-files:根据 /lib/systemd/system/ 目录内的文件列出所有的 unit。

--type=TYPE:可以过滤某个类型的 unit。

不带任何参数执行 systemctl 命令会列出所有已启动的 unit:

列举已经启动的unit

systemctl list-units (或者直接 sudo systemctl)


系统默认启动的服务是非常多的,上图只截取了前面几行。下面是对输出的介绍:

UNIT:项目的名称,包括各个 unit 的类别(看扩展名)。

LOAD:开机时 unit 的配置是否被加载。

ACTIVE:目前的状态,须与后续的 SUB 搭配!就是我们用 systemctl status 观察时,active的内容。

DESCRIPTION:描述信息。

注意,systemctl 不加参数,其实等同于 systemctl list-units

查看系统上一共装了多个unit

systemctl list-unit-files

结果也非常的多,我们仍然只截取一部分结果。这里的 STATE 就是我们前面介绍的 服务的启动状态,有 enable 和 disable、static 和 mask。

只查看某种类型的unit

比如我们只查看服务类型的unit:

systemctl list-units --type=service -all

查看加载失败的 unit

如果发现某个 unit 不工作,可以查看是否有 unit 加载失败:

systemctl --failed

  • 管理不同的操作环境(target unit)

通过指定 --type=target 就可以用 systemctl list-units 命令查看系统中默认有多少种 target:

我们在此仅介绍几个常用的 target。

graphical.target:就是文字界面再加上图形界面,这个 target 已经包含了下面的 multi-user.target。

multi-user.target:纯文本模式!

rescue.target:在无法使用 root 登陆的情况下,systemd 在开机时会多加一个额外的临时系统,与你原本的系统无关。这时你可以取得 root 的权限来维护你的系统。

emergency.target:紧急处理系统的错误,在无法使用 rescue.target 时,可以尝试使用这种模式!

shutdown.target:就是执行关机。

getty.target:可以设置 tty 的配置。

正常的模式是 multi-user.target 和 graphical.target 两个,救援方面的模式主要是 rescue.target 以及更严重的 emergency.target。如果要修改可提供登陆的 tty 数量,则修改 getty.target。

下面是操作 target unit 命令的格式:

systemctl [command] [unit.target]

command 有:

get-default:取得目前的 target。

set-default:设置后面接的 target 成为默认的操作模式。

isolate:切换到后面接的模式。

查看和设置默认的 target

systemctl get-default

切换 target

我们还可以在不重新启动的情况下切换不同的 target,比如从图形界面切换到纯文本的模式:

systemctl isolate multi-user.target

在一般情况下,使用上述 isolate 的方式即可完成不同 target 的切换。不过为了方便起见,systemd 也提供了

几个简单的指令用来切换操作模式,大致如下所示:

sudo systemctl poweroff # 系统关机
sudo systemctl reboot  # 重新开机
sudo systemctl suspend  # 进入暂停模式
sudo systemctl hibernate # 进入休眠模式
sudo systemctl rescue  # 强制进入救援模式
sudo systemctl emergency # 强制进入紧急救援模式

这里简单介绍一下暂停模式与休眠模式的区别

suspend:暂停模式会将系统的状态保存到内存中,然后关闭掉大部分的系统硬件,当然,并没有实际关机。当用户按下唤醒机器的按钮,系统数据会从内存中回复,然后重新驱动被大部分关闭的硬件,所以唤醒系统的速度比较快。

hibernate:休眠模式则是将系统状态保存到硬盘当中,保存完毕后,将计算机关机。当用户尝试唤醒系统时,系统会开始正常运行,然后将保存在硬盘中的系统状态恢复回来。因为数据需要从硬盘读取,因此唤醒的速度比较慢(如果你使用的是 SSD 磁盘,唤醒的速度也是非常快的)。

  • 检查 unit 之间的依赖性

很多服务之间是有依赖关系的,systemd 的一大亮点就是可以管理 unit 之间的依赖关系。我们可以通过下面的命令来查看 unit 间的依赖关系:

systemctl list-dependencies [unit] [--reverse] 选项 --reverse 会反向追踪是谁在使用这个 unit。

下面让我们看看当前运行的 target 的依赖关系:

我们当前运行在 graphical.target 下,它由一个长长的依赖列表(上图并未展示所有的项目),其中最重要的依赖项目为 multi-user.target。下面我们使用 --reverse 选项查看 multi-user.target unit 被谁使用:

systemctl list-dependencies multi-user.target --reverse

从上面两张图上我们可以确定下面的关系:graphical.target 依赖 multi-user.target。

我们这里只是通过 target unit 介绍了如何查看 unit 之间的依赖关系,实际使用中更多的是检查服务 unit 之间的依赖关系。

  • 相关的目录和文件

在不同的发行版中与 systemd 相关的文件路径可能会不太一样,强调一下,本文介绍的是 ubuntu 16.04 。

/lib/systemd/system/ 大多数 unit 的配置文件都放在这个目录下。

/run/systemd/system/ 系统运行过程中产生的脚本,比如用户相关的脚本和会话相关的脚本。

/etc/systemd/system/ 这个目录中主要的文件都是指向 /lib/systemd/system/ 目录中的链接文件。

注意,在我们自己创建 unit 配置文件时,既可以把配置文件放在 /lib/systemd/system/ 目录下,也可以放在 /etc/systemd/system/ 目录下。

/etc/default/ 这个目录中放置很多服务默认的配置文件。

/var/lib/ 一些会产生数据的服务都会将他的数据写入到 /var/lib/ 目录中,比如 docker 相关的数据文件就放在这个目录下。

/run/ 这个目录放置了好多服务运行时的临时数据,比如 lock file 以及 PID file 等等。

我们知道 systemd 里管理了很多会用到本机 socket 的服务,所以系统中肯定会产生很多的 socket 文件。那么,这些 socke 文件都存放在哪里呢?我们可以使用 systemctl 进行查看:

systemctl list-sockets

其实,绝大多数的 socket 文件都存放在 /run 目录及其子目录中。

systemctl daemon-reload 子命令

daemon-reload 是一个很容易被误用的子命令,主要是因为它名字中包含的 daemon 一词很容易让它和 reload 子命令混淆。

我们在前文简略的介绍了 reload 子命令,它的作用是重新加载某个服务程序的配置文件。这里的程序指的是服务类型 unit 的配置中指定的程序,也就是我们常说的 daemon(提供某种服务的应用程序)。比如服务类型的 unit prometheus.service,提供服务的 daemon 程序在我的机器上是 /usr/local/share/prometheus/prometheus,所以 reload 子命令重新加载的是 prometheus 的配置文件。

如果把 daemon-reload 子命令中的 daemon 理解为 systemd 程序,就可以把这个命令解释为重新加载 systemd 程序的配置文件。而所有的 unit 配置文件都是作为 systemd 程序的配置文件存在的。这样得出的结论就是:

新添加 unit 配置文件时需要执行 daemon-reload 子命令

有 unit 的配置文件发生变化时也需要执行 daemon-reload 子命令

daemon-reload 命令会做很多的事情,其中之一是重新生成依赖树(也就是 unit 之间的依赖关系),所以当你修改了 unit 配置文件中的依赖关系后如果不执行 daemon-reload 命令是不会生效的。

以上内容整理:

https://www.cnblogs.com/shijingjing07/p/9301590.html

https://www.jb51.net/article/136559.htm

发表评论

邮箱地址不会被公开。 必填项已用*标注