linux中systemctl详细理解及常用命令
systemctl show etcd.service注销与反注销 unit
如果我们想暂时的禁用某个 unit，比如 etcd.service，可以注销这个 unit，注销之后就无法再启动这个服务了：
systemctl mask etcd.service从上图中的输出我们可以看到，所谓的注销就是把 etcd.service 文件链接到 /dev/null 这个空设备中去了。所以就无法再启动该服务了。下面我们尝试执行一次反注销：
systemctl unmask etcd.serviceunmask 操作就是删除掉 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 [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 命令是不会生效的。
以上内容整理：