本文记录了在使用systemd过程中遇到的问题，由此mark一下。
Systemctl 简介
Systemd(system daemon)是系统的管理软件，一号进程，掌管整个系统的其他进程。
每个服务都有一个启动文件，描述systemd应该如何启动自己，systemd默认会从目录/etc/systemd/system中读取各个服务的启动配置文件。其实在/etc/systemd/system中存放的是服务启动文件的符号链接，这些符号链接指向的真正的服务配置文件存放在/usr/lib/systemd/system目录中。
1、当我们用systemctl enable命令enable某个服务时：
[root@struma4 ~]# systemctl enable docker
Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to /usr/lib/systemd/system/docker.service.
实际上是建立一个符号链接：
ln -s '/usr/lib/systemd/system/docker.service' '/etc/systemd/system/multi-user.target.wants/docker.service'
这个命令表示激活开机启动。
2、撤销开机启动命令
# systemctl disable docker.service
Removed symlink /etc/systemd/system/multi-user.target.wants/docker.service.
3、当我们修改了配置文件，需要重新加载服务的配置文件，然后重启服务，新的配置才能生效：
systemctl daemon-reload
systemctl restart docker.service
4、查看服务状态
# systemctl status docker.service
● docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; vendor preset: disabled)
Active: active (running) since Wed 2019-07-03 23:23:23 PDT; 1h 1min ago
Docs: https://docs.docker.com
Main PID: 29497 (dockerd)
CGroup: /system.slice/docker.service
├─27251 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/d213fb3a188b0037464814e841eeab69b8c1a22638e773c6852a95b40101eae6 -address /var/run/docker/...
└─29497 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --exec-opt native.cgroupdriver=systemd
5、查看某个配置文件的具体内容：
$ systemctl cat docker.service
# /usr/lib/systemd/system/docker.service
[Unit] //定义文件的metadata
Description=Docker Application Container Engine //描述
Documentation=https://docs.docker.com //文档位置
BindsTo=containerd.service //依赖的服务，如果containerd.service退出，docker也会推出
After=network-online.target firewalld.service containerd.service //如果这三个服务要启动,必须在docker之前启动
Wants=network-online.target //与docker配合的其他服务，如果它们没有运行，docker不会启动失败
Requires=docker.socket //docker 依赖的服务，如果依赖服务没有运行，docker会启动失败
[Service]
Type=notify //docker启动完毕，会通知Systemd，再继续往下执行
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --exec-opt native.cgroupdriver=systemd //启动当前服务的命令
ExecReload=/bin/kill -s HUP $MAINPID //重启当前服务时执行的命令
TimeoutSec=0 //定义 Systemd 停止当前服务之前等待的秒数
RestartSec=2 //自动重启当前服务间隔的秒数
Restart=always //定义何种情况 Systemd 会自动重启当前服务，可能的值包括always（总是重启）
# Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229.
# Both the old, and new location are accepted by systemd 229 and up, so using the old location
# to make them work for either version of systemd.
StartLimitBurst=3 //
# Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230.
# Both the old, and new name are accepted by systemd 230 and up, so using the old name to make
# this option work for either version of systemd.
StartLimitInterval=60s
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
# Comment TasksMax if your systemd version does not supports it.
# Only systemd 226 and above support this option.
TasksMax=infinity
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process
[Install] //用来定义如何启动，以及是否开机启动
WantedBy=multi-user.target //它的值是一个或多个 Target，当前 Unit 激活时（enable）符号链接会放入/etc/systemd/system目录下面以 Target 名 + .wants后缀构成的子目录中
配置文件是有具体的格式规范的，上面我们解析了docker配置文件的含义。
Systemd日志管理
Systemd 统一管理所有 Unit 服务的启动日志，统一用journalctl命令来查看日志。日志的配置文件/etc/systemd/journald.conf
# journalctl -u docker.service -f
-- Logs begin at Wed 2019-07-03 12:07:05 PDT. --
Jul 04 00:37:14 struma4.fyre.ibm.com dockerd[29497]: time="2019-07-04T00:37:14.860300542-07:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jul 04 00:37:38 struma4.fyre.ibm.com dockerd[29497]: time="2019-07-04T00:37:38.431114948-07:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jul 04 00:38:22 struma4.fyre.ibm.com dockerd[29497]: time="2019-07-04T00:38:22.636599721-07:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jul 04 00:42:45 struma4.fyre.ibm.com dockerd[29497]: time="2019-07-04T00:42:45.464684168-07:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jul 04 00:44:23 struma4.fyre.ibm.com dockerd[29497]: time="2019-07-04T00:44:23.713816082-07:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jul 04 00:45:23 struma4.fyre.ibm.com dockerd[29497]: time="2019-07-04T00:45:23.817311432-07:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jul 04 00:47:53 struma4.fyre.ibm.com dockerd[29497]: time="2019-07-04T00:47:53.441644418-07:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jul 04 00:51:23 struma4.fyre.ibm.com dockerd[29497]: time="2019-07-04T00:51:23.754137833-07:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jul 04 00:52:26 struma4.fyre.ibm.com dockerd[29497]: time="2019-07-04T00:52:26.508817533-07:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
