一、简介

Centos7开机第一个程序从init完全换成了systemd这种启动方式，同centos 5 6已经是实质差别。systemd是靠管理unit的方式来控制开机服务，开机级别等功能。
在/usr/lib/systemd/system目录下包含了各种unit文件，有service后缀的服务unit，有target后缀的开机级别unit等，这里介绍关于service后缀的文件。因为systemd在开机要想执行自启动，都是通过这些*.service 的unit控制的，服务又分为系统服务(system)和用户服务(user)。

Centos7的服务systemctl 脚本一般存放在：/usr/lib/systemd , 目录下又有user和system之分

    • /usr/lib/systemd/system   # 系统服务，开机不需要登录就能运行的程序(相当于开机自启)

    • /usr/lib/systemd/user       # 用户服务，需要登录后才能运行的程序

　　目录下又存在两种类型的文件：

    • *.service   # 服务unit文件

    • *.target     # 开机级别unit

二、配置文件说明：

CentOS7的每一个服务以.service结尾，一般会分为3部分：[Unit]、[Service]和[Install]

# vim /usr/lib/systemd/system/service@.service 
---------------------------------------------------------------------------------------------------------------
[Unit]   # 主要是服务说明,启动顺序与依赖关系
Description=test   # 简单描述服务
Documentation=     # 给出文档位置。 
After=network.target    # 描述服务类别，表示本服务需要在network服务启动后在启动。如果network.target或sshd-keygen.service需要启动
Before=xxx.service      # 表示需要在某些服务启动之前启动。 
注：After和Before字段只涉及启动顺序，不涉及依赖关系。

#举例来说，某 Web 应用需要 postgresql 数据库储存数据。在配置文件中，它只定义要在 postgresql 之后启动，而没有定义依赖 postgresql 。
#上线后，由于某种原因，postgresql 需要重新启动，在停止服务期间，该 Web 应用就会无法建立数据库连接。 
#设置依赖关系，需要使用Wants字段和Requires字段。

Wants字段：表示sshd.service与sshd-keygen.service之间存在"弱依赖"关系，即如果"sshd-keygen.service"启动失败或停止运行，不影响sshd.service继续执行。 
Requires字段则表示"强依赖"关系，即如果该服务启动失败或异常退出，那么sshd.service也必须退出。 
注意，Wants字段与Requires字段只涉及依赖关系，与启动顺序无关，默认情况下是同时启动的。
[Service]  # 核心区域
Type=forking     # 表示后台运行模式。
User=user        # 设置服务运行的用户
Group=user       # 设置服务运行的用户组
KillMode=control-group   # 定义systemd如何停止服务
PIDFile=/usr/local/test/test.pid    # 存放PID的绝对路径
Environment=OPTS="" PROFILE=""  #设置进程的环境变量， 值是一个空格分隔的 VAR=VALUE 列表。 可以多次使用此选项以增加新的变量或者修改已有的变量 (同一个变量以最后一次的设置为准)。 若设为空， 则表示清空先前所有已设置的变量。
EnvironmentFile=/data/service/%i/.env   #与 Environment= 类似， 不同之处在于此选项是从文本文件中读取环境变量的设置。 文件中的空行以及以分号(;)或井号(#)开头的行会被忽略，从文件中读取的环境变量会覆盖 Environment= 中设置的同名变量。 文件的读取顺序就是它们出现在单元文件中的顺序， 并且对于同一个变量，以最后读取的文件中的设置为准。
WorkingDirectory=/data/service/%i      # %i是实例名称,对于实例化的服务，这是指 @和后缀之间的部分。    
ExecStart=/usr/java/default/jre/bin/java $OPTS -jar %i.jar $PROFILE   # 服务启动命令，命令需要绝对路径
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
SuccessExitStatus=0 143
PrivateTmp=true                               # 表示给服务分配独立的临时空间
LimitNOFILE=1000000
LimitNPROC=100000
TimeoutStopSec=10s
Restart=on-failure        # 定义服务进程退出后，systemd的重启方式，默认是不重启
RestartSec=30
User=app
Group=app
   
[Install]   
WantedBy=multi-user.target  # 多用户

表 1. 可执行文件前的特殊前缀

前缀效果
"@"如果在绝对路径前加上可选的 "@" 前缀，那么其后的那些参数将依次作为"argv[0] argv[1] argv[2] …"传递给被执行的进程(注意，argv[0] 是可执行文件本身)。
"-"如果在绝对路径前加上可选的 "-" 前缀，那么即使该进程以失败状态(例如非零的返回值或者出现异常)退出，也会被视为成功退出。
"+"如果在绝对路径前加上可选的 "+" 前缀，那么进程将拥有完全的权限(超级用户的特权)，并且 User=, Group=, CapabilityBoundingSet= 选项所设置的权限限制以及 PrivateDevices=, PrivateTmp= 等文件系统名字空间的配置将被该命令行启动的进程忽略(但仍然对其他 ExecStart=, ExecStop= 有效)。
"!"与 "+" 类似(进程仍然拥有超级用户的身份)，不同之处在于仅忽略 User=, Group=, SupplementaryGroups= 选项的设置，而例如名字空间之类的其他限制依然有效。注意，当与 DynamicUser= 一起使用时，将会在执行该命令之前先动态分配一对 user/group ，然后将身份凭证的切换操作留给进程自己去执行。
"!!"与 "!" 极其相似，仅用于让利用 ambient capability 限制进程权限的单元兼容不支持 ambient capability 的系统(也就是不支持 AmbientCapabilities= 选项)。如果在不支持 ambient capability 的系统上使用此前缀，那么 SystemCallFilter= 与 CapabilityBoundingSet= 将被隐含的自动修改为允许进程自己丢弃 capability 与特权用户的身份(即使原来被配置为禁止这么做)，并且 AmbientCapabilities= 选项将会被忽略。此前缀在支持 ambient capability 的系统上完全没有任何效果。

"@", "-" 以及 "+"/"!"/"!!" 之一，可以按任意顺序同时混合使用。 注意，对于 "+", "!", "!!" 前缀来说，仅能单独使用三者之一，不可混合使用多个。 注意，这些前缀同样也可以用于ExecStartPre=, ExecStartPost=, ExecReload, ExecStop=, ExecStopPost= 这些接受命令行的选项。

启动类型

Type字段定义启动类型。它可以设置的值如下：       
simple(默认值)  #ExecStart字段启动的进程为主进程       
forking  #ExecStart字段将以fork()方式启动，此时父进程将会退出，子进程将成为主进程(后台运行)       
oneshot  #类似于simple，但只执行一次，Systemd 会等它执行完，才启动其他服务        
dbus     #类似于simple，但会等待 D-Bus 信号后启动         
notify   #类似于simple，启动结束后会发出通知信号，然后 Systemd 再启动其他服务       
idle     #类似于simple，但是要等到其他任务都执行完，才会启动该服务。一种使用场合是为让该服务的输出，不与其他服务的输出相混合

重启行为

Service区块有一些字段，定义了重启行为：       
**KillMode字段：定义 Systemd 如何停止 sshd 服务：**      
control-group(默认值)  #当前控制组里面的所有子进程，都会被杀掉      
process  #只杀主进程    
mixed    #主进程将收到 SIGTERM 信号，子进程收到 SIGKILL 信号   
none     #没有进程会被杀掉，只是执行服务的stop命令Restart的类型 

**Restart字段：定义了 sshd 退出后，Systemd 的重启方式**          
no(默认值)   #退出后不会重启        
on-success   #只有正常退出时(退出状态码为0)，才会重启      
on-failure   #非正常退出时(退出状态码非0)，包括被信号终止和超时，才会重启     
on-abnormal  #只有被信号终止和超时，才会重启     
on-abort     #只有在收到没有捕捉到的信号终止时，才会重启       
on-watchdog  #超时退出，才会重启      
always       #不管是什么退出原因，总是重启       
注：对于守护进程，推荐设为on-failure。对于那些允许发生错误退出的服务，可以设为on-abnormal。
     
**RestartSec字段：表示 Systemd 重启服务之前，需要等待的秒数。**  
**WatchdogSec字段：设置该服务的watchdog的超时时长。默认值"0"表示禁用watchdog功能**

启动命令   

ExecStart    # 启动服务时执行的命令
ExecReload   # 重启服务时执行的命令 
ExecReload   # 用于设置当该服务被要求重新载入配置时所执行的命令行。有一个特殊的环境变量 $MAINPID 可用于表示主进程的PID， 例如可以这样使用： /bin/kill -HUP $MAINPID
               注意，像上例那样，通过向守护进程发送复位信号， 强制其重新加载配置文件，并不是一个好习惯。 因为这是一个异步操作， 所以不适用于需要按照特定顺序重新加载配置文件的服务。 我们强烈建议将 ExecReload= 设为一个 能够确保重新加载配置文件的操作同步完成的命令行。
ExecStop      # 停止服务时执行的命令 
ExecStartPre  # 启动服务前执行的命令 
ExecStartPost # 启动服务后执行的命令 
ExecStopPost  # 停止服务后执行的命令连词号
注：在所有启动设置之前，添加的变量字段，都可以加上连词号(-)，表示抑制错误，即发生错误时，不影响其他命令的执行。
比如`EnviromentFile=-/etc/sysconfig/xxx` 就表示即使`/etc/sysconfig/sshd`文件不存在，也不会抛出错误。

注意：[Service]中的启动、重启、停止命令全部要求使用绝对路径！

[Install] 
#Install区块，定义如何安装这个配置文件，即怎样做到开机启动。 
#WantedBy字段：表示该服务所在的 Target。 
#Target的含义是服务组，表示一组服务。 
WantedBy=multi-user.target  #表示多用户命令行状态,sshd 所在的 Target 是multi-user.target。 这个设置非常重要，因为执行systemctl enable sshd.service命令时，sshd.service的一个符号链接，就会放在/etc/systemd/system目录下面的multi-user.target.wants子目录之中。
WantedBy=graphical.target:  # 表示图形用户状体，它依赖于multi-user.target

Systemd 有默认的启动 Target。

systemctl get-default
#输出multi-user.target

上面的结果表示，默认的启动 Target 是multi-user.target。在这个组里的所有服务，都将开机启动。这就是为什么systemctl enable命令能设置开机启动的原因。使用 Target 的时候，systemctl list-dependencies命令和systemctl isolate命令也很有用。

#查看 multi-user.target 包含的所有服务
systemctl list-dependencies multi-user.target

#切换到另一个 target
#shutdown.target 就是关机状态
systemctl isolate shutdown.target

一般来说，常用的 Target 有两个： multi-user.target：表示多用户命令行状态； graphical.target：表示图形用户状态，它依赖于multi-user.target。

三、注册服务实例

  • 配置文件目录 
    systemctl脚本目录：/usr/lib/systemd/

系统服务目录：/usr/lib/systemd/system/ 
用户服务目录：/usr/lib/systemd/system/

  • 在/usr/lib/systemd/system目录下新建service-name.service文件：

[UNIT]
#服务描述
Description=Media wanager Service
#指定了在systemd在执行完那些target之后再启动该服务
After=network.target

[Service]
#定义Service的运行类型，一般是forking(后台运行)   
Type=forking

#定义systemctl start|stop|reload *.service 的执行方法(具体命令需要写绝对路径)
#注：ExecStartPre为启动前执行的命令
ExecStartPre=/usr/bin/test "x${NETWORKMANAGER}" = xyes
ExecStart=/home/mobileoa/apps/shMediaManager.sh -start
ExecReload=
ExecStop=/home/mobileoa/apps/shMediaManager.sh -stop

#创建私有的内存临时空间
PrivateTmp=True

[Install]
#多用户
WantedBy=multi-user.target

systemctl 命令

systemctl daemon-reload    # 重载系统服务
systemctl enable *.service # 开启某服务开机启动  
systemctl disable *.service # 关闭某服务开机启动    
systemctl start *.service  # 启动某服务  
systemctl stop *.service   # 停止某服务 
systemctl reload *.service # 重启某服务

 注：修改完配置文件要重载配置文件。

特殊字符串

许多设置支持使用特殊的字符串，可以在运行或加载时替换成特定的内容。下表是支持的字符串。

字符串简介详细信息
%n完整的服务名称
%N不转义的完整服务名称
%p前缀名对于实例化的服务，这是前@前面的部分，对于其它的服务，是指去掉后缀(即类型)的部分。
%P不转义的前缀名
%i实例名称对于实例化的服务，这是指 @和后缀之间的部分。
%I不转义的实例名。
%f不转义的文件名。这可以不转义的实例名(如果可用)或前缀名，带有/前缀。
%c服务的控制组路径。？
%rsystemd 的根控制组路径。？
%Rsystemd 的根控制组路径的父目录。
%t运行时 Socket 目录。这可以是 /run (系统管理器) 或 $XDG_RUNTIME_DIR (用户管理器).
%u用户名这是服务配置的用户或systemd运行实例的用户(如果没有配置的话)。
%U用户 UID这是服务配置的用户UID或systemd运行实例的用户UID(如果没有配置的话)
%h用户家目录这是服务配置的用户家目录或systemd运行实例的用户家目录(如果没有配置的话)
%s用户Shell这是服务配置的用户shell或systemd运行实例的用户shell(如果没有配置的话)
%m机器 ID运行系统的机器 ID ，格式是一个字符串。
%b启动 ID运行系统的启动 ID ，格式是一个字符串。.
%H主机名运行系统的主机名。
%%转义 %一个单百分号.

四、systemd的资源控制机制

问题现象

我们希望通过systemd拉起服务并通过cgroup限制其CPU、memory的使用，因此我们新建了一个.service文件，文件里面创建了自己的cgroup目录，设置了cpu、memory限制，然后通过cgexec拉起我们的服务进程。假设我们的服务叫xx，.service文件大概是这样的：

[Unit]
Description=xx Server
Documentation=xx docs

[Service]
EnvironmentFile=-/etc/xx
ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/memory/xx
ExecStartPre=/usr/bin/bash -c "echo 2G > /sys/fs/cgroup/memory/xx/memory.limit_in_bytes"
ExecStartPre=/usr/bin/bash -c "echo 2G > /sys/fs/cgroup/memory/xx/memory.memsw.limit_in_bytes"

ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/cpu/xx
ExecStartPre=/usr/bin/bash -c "echo 100000 > /sys/fs/cgroup/cpu/xx/cpu.cfs_period_us"
ExecStartPre=/usr/bin/bash -c "echo 100000 > /sys/fs/cgroup/cpu/xx/cpu.cfs_quota_us"
ExecStartPre=/usr/bin/bash -c "echo 1024 > /sys/fs/cgroup/cpu/xx/cpu.shares"

ExecStart=/usr/bin/cgexec -g cpu,memory:xx /usr/bin/xx

Restart=on-failure
KillMode=process
LimitNOFILE=102400
LimitNPROC=102400
LimitCORE=infinity

[Install]
WantedBy=multi-user.target

设置完.service文件后，将其拷贝到/usr/lib/systemd/system目录(CentOS 7)下，然后通过systemctl start xx.service启动，通过systemctl enable xx.service关联自启动项。
但在运行很久之后，发现我们的xx服务内存使用爆了，然后查看我们自己创建的xx cgroup目录丢失了，因此对应的CPU、memory资源也就没有限制住。

分析过程

刚开始的定位过程是很懵逼的，各种日志查看没有发现线索，尝试复现也没有成功。正在苦恼没有方向之际，无意中发现执行了其他服务的systemd的某些操作(stop/start/enable)之后，复现了问题，就这样盯上了systemd。
后来发现其实一开始就可以通过查看进程的cgroup信息就能很快找到线索：进程cgroup移到了/system.slice/xx.service目录下：

[root@localhost ~]# cat /proc/214041/cgroup 
10:memory:/system.slice/xx.service
4:cpuacct,cpu:/system.slice/xx.service

而/system.slice/xx.service正是systemd为xx这个服务创建的cgroup目录。所以问题锁定为systemd把xx进程从我们自己创建的cgroup移动到它默认创建的cgroup里，但是它默认创建的cgroup显然没有设置过资源限制。

systemd资源控制

systemd通过Unit的配置文件配置资源控制，Unit包括services(上面例子就是一个service unit), slices, scopes, sockets, mount points, 和swap devices六种。systemd底层也是依赖Linux Control Groups (cgroups)来实现资源控制。

cgroup v1和v2

cgroup有两个版本，新版本的cgroup v2即Unified cgroup(参考cgroup v2)和传统的cgroup v1(参考cgroup v1)，在新版的Linux(4.x)上，v1和v2同时存在，但同一种资源(CPU、内存、IO等)只能用v1或者v2一种cgroup版本进行控制。systemd同时支持这两个版本，并在设置时为两者之间做相应的转换。对于每个控制器，如果设置了cgroup v2的配置，则忽略所有v1的相关配置。
在systemd配置选项上，cgroup v2相比cgroup v1有如下不一样的地方：
1.CPU： CPUWeight=和StartupCPUWeight=取代了CPUShares=和StartupCPUShares=。cgroup v2没有"cpuacct"控制器。
2.Memory：MemoryMax=取代了MemoryLimit=. MemoryLow= and MemoryHigh=只在cgroup v2上支持。
3.IO：BlockIO前缀取代了IO前缀。在cgroup v2，Buffered写入也统计在了cgroup写IO里，这是cgroup v1一直存在的问题。

配置选项(新版本systemd)

CPUAccounting=：是否开启该unit的CPU使用统计，BOOL型，true或者false。

CPUWeight=weight, StartupCPUWeight=weight：用于设置cgroup v2的cpu.weight参数。取值范围1-1000，默认值100。StartupCPUWeight应用于系统启动阶段，CPUWeight应用于正常运行时。这两个配置取代了旧版本的CPUShares=和StartupCPUShares=。

CPUQuota=：用于设置cgroup v2的cpu.max参数或者cgroup v1的cpu.cfs_quota_us参数。表示可以占用的CPU时间配额百分比。如：20%表示最大可以使用单个CPU核的20%。可以超过100%，比如200%表示可以使用2个CPU核。

MemoryAccounting=：是否开启该unit的memory使用统计，BOOL型，true或者false。

MemoryLow=bytes：用于设置cgroup v2的memory.low参数，不支持cgroup v1。当unit使用的内存低于该值时将被保护，其内存不会被回收。可以设置不同的后缀：K,M,G或者T表示不同的单位。

MemoryHigh=bytes：用于设置cgroup v2的memory.high参数，不支持cgroup v1。内存使用超过该值时，进程将被降低运行时间，并快速回收其占用的内存。同样可以设置不同的后缀：K,M,G或者T(单位1024)。也可以设置为infinity表示没有限制。

MemoryMax=bytes：用于设置cgroup v2的memory.max参数，如果进程的内存超过该限制，则会触发out-of-memory将其kill掉。同样可以设置不同的后缀：K,M,G或者T(单位1024)，以及设置为infinity。该参数去掉旧版本的MemoryLimit=。

MemorySwapMax=bytes：用于设置cgroup v2的memory.swap.max"参数。和MemoryMax类似，不同的是用于控制Swap的使用上限。

TasksAccounting=：是否开启unit的task个数统计，BOOL型，ture或者false。

TasksMax=N：用于设置cgroup的pids.max参数。控制unit可以创建的最大tasks个数。

IOAccounting：是否开启Block IO的统计，BOOL型，true或者false。对应旧版本的BlockIOAccounting=参数。

IOWeight=weight, StartupIOWeight=weight：设置cgroup v2的io.weight参数，控制IO的权重。取值范围0-1000，默认100。该设置取代了旧版本的BlockIOWeight=和StartupBlockIOWeight=。

IODeviceWeight=device weight：控制单个设备的IO权重，同样设置在cgroup v2的io.weight参数里，如“/dev/sda 1000”。取值范围0-1000，默认100。该设置取代了旧版本的BlockIODeviceWeight=。

IOReadBandwidthMax=device bytes, IOWriteBandwidthMax=device bytes：设置磁盘IO读写带宽上限，对应cgroup v2的io.max参数。该参数格式为“path bandwidth”，path为具体设备名或者文件系统路径(最终限制的是文件系统对应的设备名)。数值bandwidth支持以K,M,G,T后缀(单位1000)。可以设置多行以限制对多个设备的IO带宽。该参数取代了旧版本的BlockIOReadBandwidth=和BlockIOWriteBandwidth=。

IOReadIOPSMax=device IOPS, IOWriteIOPSMax=device IOPS：设置磁盘IO读写的IOPS上限，对应cgroup v2的io.max参数。格式和上面带宽限制的格式一样一样的。

IPAccounting=：BOOL型，如果为true，则开启ipv4/ipv6的监听和已连接的socket网络收发包统计。

IPAddressAllow=ADDRESS[/PREFIXLENGTH]…, IPAddressDeny=ADDRESS[/PREFIXLENGTH]…：开启AF_INET和AF_INET6 sockets的网络包过滤功能。参数格式为IPv4或IPv6的地址列表，IP地址后面支持地址匹配前缀(以'/'分隔)，如”10.10.10.10/24“。需要注意，该功能仅在开启“eBPF”模块的系统上才支持。

DeviceAllow=：用于控制对指定的设备节点的访问限制。格式为“设备名 权限”，设备名以"/dev/"开头或者"char-"、“block-”开头。权限为'r','w','m'的组合，分别代表可读、可写和可以通过mknode创建指定的设备节点。对应cgroup的"devices.allow"和"devices.deny"参数。

DevicePolicy=auto|closed|strict：控制设备访问的策略。strict表示：只允许明确指定的访问类型；closed表示：此外，还允许访问包含/dev/null,/dev/zero,/dev/full,/dev/random,/dev/urandom等标准伪设备。auto表示：此外，如果没有明确的DeviceAllow=存在，则允许访问所有设备。auto是默认设置。

Slice=：存放unit的slice目录，默认为system.slice。

Delegate=：默认关闭，开启后将更多的资源控制交给进程自己管理。开启后unit可以在单其cgroup下创建和管理其自己的cgroup的私人子层级，systemd将不在维护其cgoup以及将其进程从unit的cgroup里移走。开启方法：“Delegate=yes”。所以通过设置Delegate选项，可以解决上面的问题。

配置选项(旧版本)

这些是旧版本的选项，新版本已经弃用。列出来是因为centos 7里的systemd是旧版本，所以要使用这些配置。

CPUShares=weight, StartupCPUShares=weight：进程获取CPU运行时间的权重值，对应cgroup的"cpu.shares"参数，取值范围2-262144，默认值1024。

MemoryLimit=bytes：进程内存使用上限，对应cgroup的"memory.limit_in_bytes"参数。支持K,M,G,T(单位1024)以及infinity。默认值-1表示不限制。

BlockIOAccounting=：开启磁盘IO统计选项，同上面的IOAccounting=。

BlockIOWeight=weight, StartupBlockIOWeight=weight：磁盘IO的权重，对应cgroup的"blkio.weight"参数。取值范围10-1000，默认值500。

BlockIODeviceWeight=device weight：指定磁盘的IO权重，对应cgroup的"blkio.weight_device"参数。取值范围1-1000，默认值500。

BlockIOReadBandwidth=device bytes, BlockIOWriteBandwidth=device bytes：磁盘IO带宽的上限配置，对应cgroup的"blkio.throttle.read_bps_device"和 "blkio.throttle.write_bps_device"参数。支持K,M,G,T后缀(单位1000)。

问题解决

回到上面的问题，我们可以通过两种方法解决：
1.在unit配置文件里添加一个Delegate=yes的选项，这样资源控制完全有用户自己管理，systemd不会去移动进程到其默认创建的cgroup里。
2.直接使用systemd的资源控制机制进行资源控制。通过直接使用systemd的资源控制的.service配置文件样例：

[Unit]
Description=xx Server

[Service]
ExecStart=/usr/bin/xx

LimitNOFILE=102400
LimitNPROC=102400
LimitCORE=infinity
Restart=on-failure
KillMode=process
MemoryLimit=1G
CPUShares=1024

[Install]
WantedBy=multi-user.target

修改完.service文件后，通过systemctl daemon-reload重新导入service文件，通过systemctl restart xx重启服务。

总结

systemd有自己的资源控制机制，所以用systemd拉起的服务时，不要自作聪明创建自己的cgroup目录并通过cgexec来拉起进程进行资源控制。

五、异常报错

当我执行systemctl命令后shell阻塞在那里，没有像平时执行命令那样自动结束(只能自己按Ctrl+C强制结束)，效果如下：

php-ka.png

强制结束后，查看程序发现目标程序启动是成功的， 但状态为activating (start)而不是activating (running)态：

php-ka2.png

解决方法：

导致此问题的原因是：php7-fpm.service类型选择有问题, 不应该选forking类型；类型改为Type=simple(或删除Type=forking这句)，问题便得到解决。

参考博客：

https://www.fcwys.cc/index.php/archives/247.html

http://www.jinbuguo.com/systemd/systemd.service.html

http://www.jinbuguo.com/systemd/systemd.exec.html#

systemd 的手册页：http://www.freedesktop.org/software/systemd/man

fedora 的 systemd 说明页面：http://fedoraproject.org/wiki/Packaging:Systemd，中文：https://fedoraproject.org/wiki/Systemd/zh-cn

unbuntu 的 systemd 说明页面：https://wiki.edubuntu.org/systemd

arch 的 systemd 说明页面：https://wiki.archlinux.org/index.php/Systemd/，中文：https://wiki.archlinux.org/index.php/Systemd_(%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87)