daemon（守护进程；后台程序）与服务：
系统为了某些功能必须要提供一些服务 (不论是系统本身还是网络方面)，这个服务就称为 service 。但是 service 的提供总是需要程序的运作，否则如何执行，所以达成这个 service 的程序我们就称呼他为 daemon。
不必刻意去区分什么是 daemon 与 service ！事实上，可以将这两者视为相同！因为达成某个 service 是需要一支 daemon 在背景中运作， 没有这支 daemon 就不会有 service ！
早期 System V 的 init 管理行为中 daemon 的主要分类 (Optional)
启动系统服务的管理方式被称为 SysV 的 init 脚本程序的处理方式！即系统核心第一支呼叫的程序是 init ， 然后 init 去唤起所有的系统所需要的服务，不论是本地服务还是网络服务。
基本上 init 的管理机制有几个特色：
服务的启动、关闭与观察等方式：
所有的服务启动脚本通通放置于 /etc/init.d/ 底下，基本上都是使用 bash shell script 所写成的脚本程序，需要启动、关闭、重新启动、观察状态时， 可以透过如下的方式来处理：
o 启动：/etc/init.d/daemon start
o 关闭：/etc/init.d/daemon stop
o 重新启动：/etc/init.d/daemon restart
o 状态观察：/etc/init.d/daemon status
服务启动的分类：
init 服务的分类中，依据服务是独立启动或被一只总管程序管理而分为两大类：
o 独立启动模式 (stand alone)：服务独立启动，该服务直接常驻于内存中，提供本机或用户的服务行为，反应速度快。
o
总管程序 (super daemon)：由特殊的 xinetd 或 inetd 这两个总管程序提供 socket 对应或 port 对应的管理。当没有用户要求某 socket 或 port 时， 所需要的服务是不会被启动的。若有用户要求时，xinetd 总管才会去唤醒相对应的服务程序。当该要求结束时，这个服务也会被结束掉～ 因为透过xinetd 所总管，因此这个家伙就被称为 super daemon。好处是可以透过 super daemon 来进行服务的时程、联机需求等的控制，缺点是唤醒服务需要一点时间的延迟。
服务的相依性问题：
服务是可能会有相依性的。init 在管理员自己手动处理这些服务时，是没有办法协助相依服务的唤醒的！
执行等级的分类：
init 是开机后核心主动呼叫的， 然后 init 可以根据用户自定义的执行等级 (runlevel) 来唤醒不同的服务，以进入不同的操作界面。基本上 Linux 提供 7 个执行等级，分别是 0, 1, 2...6 ， 比较重要的是 1)单人维护模式、3)纯文本模式、5)文字加图形界面。而各个执行等级的启动脚本是透过 /etc/rc.d/rc[0-6]/SXXdaemon 连结到 /etc/init.d/daemon ， 连结档名 (SXXdaemon) 的功能为： S 为启动该服务，XX 是数字，为启动的顺序。由于有 SXX 的设定，因此在开机时可以『依序执行』所有需要的服务，同时也能解决相依服务的问题。这点与管理员自己手动处理不太一样就是了。
制定执行等级默认要启动的服务：
若要建立如上提到的 SXXdaemon 的话，不需要管理员手动建立连结档， 透过如下的指令可以来处理默认启动、预设不启动、观察预设启动否的行为：
o 预设要启动： chkconfig daemon on
o 预设不启动： chkconfig daemon off
o 观察预设为启动否： chkconfig --list daemon
执行等级的切换行为：
当你要从纯文本界面 (runlevel 3) 切换到图形界面 (runlevel 5)， 不需要手动启动、关闭该执行等级的相关服务，只要『 init 5 』即可切换，init 这小子会主动去分析 /etc/rc.d/rc[35].d/ 这两个目录内的脚本， 然后启动转换 runlevel 中需要的服务～就完成整体的 runlevel 切换。
systemd 使用的 unit 分类
CentOS 7.x 以后，Red Hat 系列的 distribution 放弃沿用多年的 System V 开机启动服务的流程，改用 systemd 这个启动服务管理机制。
好处：
平行处理所有服务，加速开机流程：
旧的 init 启动脚本是『一项一项任务依序启动』的模式，因此不相依的服务也是得要一个一个的等待。但目前我们的硬件主机系统与操作系统几乎都支持多核心架构，未相依的服务能同时启动，systemd 就是可以让所有的服务同时启动。
一经要求就响应的 on-demand 启动方式：
systemd 全部就是仅有一只 systemd 服务搭配 systemctl 指令来处理，无须其他额外的指令来支持。不像system V 还要 init, chkconfig, service... 等等指令。
服务相依性的自我检查
systemd 可以自定义服务相依性的检查并解决依赖。因此如果 B 服务是架构在 A 服务上面启动的，那当你在没有启动 A 服务的情况下仅手动启动 B 服务时， systemd 会自动帮你启动 A 服务喔！这样就可以免去管理员得要一项一项服务去分析的麻烦。
依 daemon 功能分类：
首先 systemd 先定义所有的服务为一个服务单位 (unit)，并将该 unit 归类到不同的服务类型 (type) 去。旧的 init 仅分为 stand alone 与 super daemon 实在不够看。systemd 将服务单位 (unit) 区分为 service, socket, target, path, snapshot, timer 等多种不同的类型(type)。
将多个 daemons 集合成为一个群组：
如同 systemV 的 init 里头有个 runlevel 的特色，systemd 亦将许多的功能集合成为一个所谓的 target 项目，这个项目主要在设计操作环境的建置， 所以是集合了许多的 daemons，即执行某个 target 就是执行好多个 daemon
向下兼容旧有的 init 服务脚本：
基本上， systemd 是可以兼容于 init 的启动脚本的，因此，旧的 init 启动脚本也能够透过 systemd 来管理，只是更进阶的 systemd 功能就没有办法支持。
但是，systemd 也是有些地方无法完全取代 init 。包括：
在 runlevel 的对应上，大概仅有 runlevel 1, 3, 5 有对应到 systemd 的某些 target 类型而已，没有全部对应；
全部的 systemd 都用 systemctl 这个管理程序管理，而 systemctl 支持的语法有限制，不像/etc/init.d/daemon 就是纯脚本可以自定义参数，systemctl 不可自定义参数。；
如果某个服务启动是管理员自己手动执行启动，而不是使用 systemctl 去启动的 (例如你自己手动输入crond 以启动 crond 服务)，那么 systemd 将无法侦测到该服务，而无法进一步管理。
systemd 启动过程中，无法与管理员透过 standard input 传入讯息！因此，自行撰写 systemd 的启动设定时，务必要取消互动机制～(连透过启动时传进的标准输入讯息也要避免！)
systemd 的配置文件放置目录：
基本上， systemd 将过去所谓的 daemon 执行脚本通通称为一个服务单位 (unit)，而每种服务单位依据功能来区分时，就分类为不同的类型 (type)。基本的类型有包括系统服务、数据监听与交换的插槽档服务 (socket)、储存系统状态的快照类型、提供不同类似执行等级分类的操作环境 (target) 等等。
配置文件都放置在以下目录中：
/usr/lib/systemd/system/：每个服务最主要的启动脚本设定，有点类似以前的 /etc/init.d 底下的文件；
/run/systemd/system/：系统执行过程中所产生的服务脚本，这些脚本的优先序要比 /usr/lib/systemd/system/ 高！
/etc/systemd/system/：管理员依据主机系统的需求所建立的执行脚本，其实这个目录有点像以前 /etc/rc.d/rc5.d/Sxx 之类的功能！执行优先序又比 /run/systemd/system/ 高！
也就是说，到底系统开机会不会执行某些服务其实是看 /etc/systemd/system/ 底下的设定，所以该目录底下就是一大堆连结档。而实际执行的 systemd 启动脚本配置文件， 其实都是放置在 /usr/lib/systemd/system/ 底下。
systemd 的 unit 类型分类说明：
/usr/lib/systemd/system/ 以下的数据按扩展名区分不同的类型 (type)。
常见的 systemd 的服务类型：
|
扩展名
|
主要服务功能
|
|
.service
|
一般服务类型 (service unit)：主要是系统服务，包括服务器本身所需要的本地服务以及网络服务都是！比较经常被使用到的服务大多是这种类型！ 所以，这也是最常见的类型了！
|
|
.socket
|
内部程序数据交换的插槽服务 (socket unit)：主要是 IPC (Inter-process communication) 的传输讯息插槽文件 (socket file) 功能。 这种类型的服务通常在监控讯息传递的插槽文件，当有透过此插槽文件传递讯息来说要链接服务时，就依据当时的状态将该用户的要求传送到对应的 daemon， 若 daemon 尚未启动，则启动该daemon 后再传送用户的要求。
使用 socket 类型的服务一般是比较不会被用到的服务，因此在开机时通常会稍微延迟启动的时间 (因为比较没有这么常用嘛！)。一般用于本地服务比较多，例如我们的图形界面很多的软件都是透过 socket 来进行本机程序数据交换的行为。 (这与早期的xinetd 这个 super daemon 有部份的相似喔！)
|
|
.target
|
执行环境类型 (target unit)：其实是一群 unit 的集合，例如 multi-user.target 其实就是一堆服务的集合～也就是说， 选择执行 multi-user.target 就是执行一堆其他 .service 或 .socket 之类的服务！
|
|
.mount
.automount
|
文件系统挂载相关的服务 (automount unit / mount unit)：例如来自网络的自动挂载、NFS 文件系统挂载等与文件系统相关性较高的程序管理。
|
|
.path
|
侦测特定文件或目录类型 (path unit)：某些服务需要侦测某些特定的目录来提供队列服务，例如最常见的打印服务，就是透过侦测打印队列目录来启动打印功能！ 这时就得要 .path 的服务类型支持了！
|
|
.timer
|
循环执行的服务 (timer unit)：这个东西有点类似 anacrontab 喔！不过是由 systemd 主动提供的，比 anacrontab 更加有弹性！
|
其中又以 .service 的系统服务类型最常见，因为我们一堆网络服务都是透过这种类型来设计的。
透过 systemctl 管理服务
基本上， systemd 这个启动服务的机制，主要是透过一只名为 systemctl 的指令来处理。
跟以前systemV 需要 service / chkconfig / setup / init 等指令来协助不同， systemd 就是仅有 systemctl 这个指令。
明确：服务启动脚本 = unit；unit 根据扩展名划分为不同的 type；type 中的 target unit 是许多 unit 的集合；
systemctl 管理单一服务 (service unit) 的启动/开机启动与观察状态
一般来说，服务的启动有两个阶段，一个是『开机的时候设定要不要启动这个服务』， 以及『你现在要不要启动这个服务』
不应该使用 kill 的方式来关掉一个正常的服务！否则 systemctl 会无法继续监控该服务！
用 systemtctl status xxx 的输出结果中，第 2, 3 两行很重要～因为那个是告知我们该 unit 下次开机会不会预设启动，以及目前启动的状态！最底下是这个 unit 的登录档～如果你的这个 unit 曾经出错过，观察这个地方！【登录文件信息格式为：“时间” “讯息发送主机” “哪一个服务的讯息” “实际讯息内容”】
很多服务彼此之间是有相依性! 透过这个 mask 功能，可以不必管其他相依服务可能会启动到这个想要关闭的服务。要取消的话只需要用 umask 命令。
Active 基本上有几个常见的状态：
active (running)：正有一只或多只程序正在系统中执行的意思，举例来说，正在执行中的 vsftpd 就是这种
模式。
active (exited)：仅执行一次就正常结束的服务，目前并没有任何程序在系统中执行。 举例来说，开机或者
是挂载时才会进行一次的 quotaon 功能，就是这种模式！ quotaon 不须一直执行～只须执行一次之后，就
交给文件系统去自行处理啰！通常用 bash shell 写的小型服务，大多是属于这种类型 (无须常驻内存)。
active (waiting)：正在执行当中，不过还再等待其他的事件才能继续处理。举例来说，打印的队列相关服务
就是这种状态！ 虽然正在启动中，不过，也需要真的有队列进来 (打印作业) 这样他才会继续唤醒打印机
服务来进行下一步打印的功能。
inactive：这个服务目前没有运作的意思。
开机启动的几个状态值：
enabled：这个 daemon 将在开机时被执行
disabled：这个 daemon 在开机时不会被执行
static：这个 daemon 不可以自己启动 (enable 不可)，不过可能会被其他的 enabled 的服务来唤醒 (相依属
性的服务)
mask：这个 daemon 无论如何都无法被启动！因为已经被强制注销 (非删除)。可透过 systemctl unmask 方
式改回原本状态
systemctl 观察系统上所有的服务
系统上面有多少的服务存在呢？这个时候就得要透过 list-units 及 list-unit-files 来观察。
|
列字段
|
说明
|
|
UNIT
|
项目的名称，包括各个 unit 的类别 (看扩展名)
|
|
LOAD
|
开机时是否会被加载，默认 systemctl 显示的是有加载的项目而已！
|
|
ACTIVE
|
目前的状态，须与后续的 SUB 搭配！就是我们用 systemctl status 观察时，active 的项目！
|
|
DESCRIPTION
|
详细描述
|
systemctl 不加参数，其实预设就是 list-units 的意思。
使用 systemctl list-unit-files 会将系统上所有的服务通通列出来～而不像 list-units 仅以 unit 分类作大致的说明。至于 STATE 状态就是开机是否会加载的那个状态项目
systemctl 管理不同的操作环境 (target unit)
跟操作界面相关性比较高的 target 主要有底下几个：
graphical.target：就是文字加上图形界面，这个项目已经包含了底下的 multi-user.target 项目！
multi-user.target：纯文本模式！
rescue.target：在无法使用 root 登入的情况下，systemd 在开机时会多加一个额外的暂时系统，与你原本的
系统无关。这时你可以取得 root 的权限来维护你的系统。但是这是额外系统，因此可能需要动到 chroot 的
方式来取得你原有的系统喔！再后续的章节我们再来谈！
emergency.target：紧急处理系统的错误，还是需要使用 root 登入的情况，在无法使用 rescue.target 时，可以尝试使用这种模式！
shutdown.target：就是关机的流程。
getty.target：可以设定你需要几个 tty 之类的，如果想要降低 tty 的项目，可以修改这个东西的配置文件！
正常的模式是 multi-user.target 以及 graphical.target 两个，救援方面的模式主要是 rescue.target 以及更严重的 emergency.target。 如果要修改可提供登入的 tty 数量，则修改 getty.target 项目。
要注意，改变 graphical.target 以及 multi-user.target 是透过 isolate 来处理的。
切换操作模式：
suspend：暂停模式会将系统的状态数据保存到内存中，然后关闭掉大部分的系统硬件，当然，并没有实际关机喔！ 当用户按下唤醒机器的按钮，系统数据会重内存中回复，然后重新驱动被大部分关闭的硬件，就开始正常运作！唤醒的速度较快。
hibernate：休眠模式则是将系统状态保存到硬盘当中，保存完毕后，将计算机关机。当用户尝试唤醒系统时，系统会开始正常运作， 然后将保存在硬盘中的系统状态恢复回来。因为数据是由硬盘读出，因此唤醒的效能与你的硬盘速度有关。
systemctl 分析各服务之间的相依性
systemd 的 daemon 运作过程相关的目录简介
跟系统的 daemon 运作有关的目录基本上是这样的：
/usr/lib/systemd/system/：
使用 CentOS 官方提供的软件安装后，默认的启动脚本配置文件都放在这里，这里的数据尽量不要修改～要修改时，请到 /etc/systemd/system 底下修改较佳！
/run/systemd/system/：
系统执行过程中所产生的服务脚本，这些脚本的优先序要比 /usr/lib/systemd/system/ 高！
/etc/systemd/system/：
管理员依据主机系统的需求所建立的执行脚本，其实这个目录有点像以前 /etc/rc.d/rc5.d/Sxx 之类的功能！
执行优先序又比 /run/systemd/system/ 高喔！
/etc/sysconfig/*：
几乎所有的服务都会将初始化的一些选项设定写入到这个目录下，举例来说，mandb 所要更新的 man page
索引中，需要加入的参数就写入到此目录下的 man-db 当中喔！而网络的设定则写在 /etc/sysconfig/network-scripts/ 这个目录内。所以，这个目录内的文件也是挺重要的；
/var/lib/：
一些会产生数据的服务都会将他的数据写入到 /var/lib/ 目录中。举例来说，数据库管理系统 Mariadb 的数
据库默认就是写入 /var/lib/mysql/ 这个目录下啦！
/run/：
放置了好多 daemon 的暂存档，包括 lock file 以及 PID file 等等。
网络服务与端口口对应：
IP 就是代表你的主机在因特网上面的『门牌号码』。 但是你的主机总是可以提供非常多的网络服务而不止一项功能而已，但我们仅有一个 IP ！当客户端联机过来我们的主机时， 我们主机是如何分辨不同的服务要求？那就是透过埠号 (port number) ！埠号简单的想象，他就是你家门牌上面的第几层楼！ 这个 IP 与 port 就是因特网联机的最重要机制之一。
为了统一整个因特网的端口号对应服务的功能，好让所有的主机都能够使用相同的机制来提供服务与要求服务，所以就有了『通讯协议』。
系统上面有没有什么设定可以让服务与埠号对应在一起呢？查看文件 /etc/services 设定服务与埠号对应 ：
什么是网络服务呢？基本上，会产生一个网络监听端口口 (port) 的程序，你就可以称他是个网络服务了！
systemctl 针对 service 类型的配置文件
以前，我们如果想要建立系统服务，就得要到 /etc/init.d/ 底下去建立相对应的 bash shell script 来处
理。
服务的管理是透过 systemd，而 systemd 的配置文件大部分放置于/usr/lib/systemd/system/ 目录内。但是 Red Hat 官方文件指出， 该目录的文件主要是原本软件所提供的设定，建议不要修改！而要修改的位置应该放置于 /etc/systemd/system/ 目录内。
举例来说，如果你想要额外修改 vsftpd.service 的话， 他们建议要放置到哪些地方？
/usr/lib/systemd/system/vsftpd.service：官方释出的预设配置文件；
/etc/systemd/system/vsftpd.service.d/custom.conf：在 /etc/systemd/system 底下建立与配置文件相同文件名的目录，但是要加上 .d 的扩展名。然后在该目录下建立配置文件即可。另外，配置文件最好附档名取名为 .conf较佳！ 在这个目录下的文件会『累加其他设定』进入 /usr/lib/systemd/system/vsftpd.service 内喔！
/etc/systemd/system/vsftpd.service.wants/*：此目录内的文件为链接档，设定相依服务的连结。意思是启动了vsftpd.service 之后，最好再加上这目录底下建议的服务。
/etc/systemd/system/vsftpd.service.requires/*：此目录内的文件为链接档，设定相依服务的连结。意思是在启动 vsftpd.service 之前，需要事先启动哪些服务的意思。
配置文件大概能够将整个设定分为三个部份，就是：
[Unit]： unit 本身的说明，以及与其他相依 daemon 的设定，包括在什么服务之后才启动此 unit 之类的设
定值，即这个项目与此 unit 的解释、执行服务相依性有关；
[Service], [Socket], [Timer], [Mount], [Path]..：不同的 unit type 就得要使用相对应的设定项目。我们拿的是
sshd.service 来当模板，所以这边就使用 [Service] 来设定。 这个项目内主要在规范服务启动的脚本、环境配置文件档名、重新启动的方式等等。即这个项目与实际执行的指令参数有关。
[Install]：这个项目就是将此 unit 安装到哪个 target 里面去的意思！即这个项目说明此 unit 要挂载哪个 target 底下。
配置文件内有些设定规则：
设定项目通常是可以重复的，例如我可以重复设定两个 After 在配置文件中，不过，后面的设定会取代前
面的喔！因此，如果你想要将设定值归零， 可以使用类似『 After= 』的设定，亦即该项目的等号后面什
么都没有，就将该设定归零了 (reset)。
如果设定参数需要有『是/否』的项目 (布尔值, boolean)，你可以使用 1, yes, true, on 代表启动，用 0, no, false,off 代表关闭！随你喜好选择啰！
空白行、开头为 # 或 ; 的那一行，都代表批注！
|
[Unit] 部份
|
|
|
设定参数
|
参数意义说明
|
|
Description
|
就是当我们使用 systemctl list-units 时，会输出给管理员看的简易说明！当然，使用 systemctl status 输出的此服务的说明，也是这个项目！
|
|
Documentation
|
这个项目在提供管理员能够进行进一步的文件查询的功能！提供的文件可以是如下的资料：
Documentation=
http://www....
Documentation=man:sshd(8)
Documentation=file:/etc/ssh/sshd_config
|
|
After
|
说明此 unit 是在哪个 daemon 启动之后才启动的意思！基本上仅是说明服务启动的顺序而已，并没有强制要求里头的服务一定要启动后此 unit 才能启动。 以 sshd.service 的内容为例，该文件提到 After 后面有 network.target 以及 sshd-keygen.service，但是若这两个 unit 没有启动而强制启动 sshd.service 的话， 那么 sshd.service 应该还是能够启动的！这与 Requires 的设定是有差异的喔！
|
|
Before
|
与 After 的意义相反，是在什么服务启动前最好启动这个服务的意思。不过这仅是规范服务启动的顺序，并非强制要求的意思。
|
|
Requires
|
明确的定义此 unit 需要在哪个 daemon 启动后才能够启动！就是设定相依服务啦！如果在此项设定的前导服务没有启动，那么此 unit 就不会被启动！
|
|
Wants
|
与 Requires 刚好相反，规范的是这个 unit 之后最好还要启动什么服务比较好！不过，并没有明确的规范就是了！主要的目的是希望建立让使用者比较好操作的环境。 因此，这个 Wants后面接的服务如果没有启动，其实不会影响到这个 unit 本身！
|
|
Conflicts
|
代表冲突的服务！亦即这个项目后面接的服务如果有启动，那么我们这个 unit 本身就不能启动！我们 unit 有启动，则此项目后的服务就不能启动！ 反正就是冲突性的检查！
|
|
[Service] 部份
|
|
|
设定参数
|
参数意义说明
|
|
Type
|
说明这个 daemon 启动的方式，会影响到 ExecStart 喔！一般来说，有底下几种类型：
simple：默认值，这个 daemon 主要由 ExecStart 接的指令串来启动，启动后常驻于内存中。
forking：由 ExecStart 启动的程序透过 spawns 延伸出其他子程序来作为此 daemon 的主要服务。原生的父程序在启动结束后就会终止运作。 传统的 unit 服务大多属于这种项目，例如 httpd 这个 WWW 服务，当 httpd 的程序因为运作过久因此即将终结了，则 systemd 会再重新生出另一个子程序持续运作后， 再将父程序删除。据说这样的效能比较好！！
oneshot：与 simple 类似，不过这个程序在工作完毕后就结束了，不会常驻在内存中。
dbus：与 simple 类似，但这个 daemon 必须要在取得一个 D-Bus 的名称后，才会继续运作！因此设定这个项目时，通常也要设定 BusName= 才行！
idle：与 simple 类似，意思是，要执行这个 daemon 必须要所有的工作都顺利执行完毕后才会执行。这类的 daemon 通常是开机到最后才执行即可的服务！比较重要的项目大概是 simple, forking 与 oneshot 了！毕竟很多服务需要子程序 (forking)，而有更多的动作只需要在开机的时候执行一次(oneshot)，例如文件系统的检查与挂载啊等等的。
|
|
EnvironmentFile
|
可以指定启动脚本的环境配置文件！例如 sshd.service 的配置文件写入到 /etc/sysconfig/sshd 当中！你也可以使用 Environment= 后面接多个不同的 Shell 变量来给予设定！
|
|
ExecStart
|
就是实际执行此 daemon 的指令或脚本程序。你也可以使用 ExecStartPre (之前) 以及ExecStartPost (之后) 两个设定项目来在实际启动服务前，进行额外的指令行为。 但是你得要特别注意的是，指令串仅接受『指令 参数 参数...』的格式，不能接受 <, >, >>, |, & 等特殊字符，很多的 bash 语法也不支持喔！ 所以，要使用这些特殊的字符时，最好直接写入到指令脚本里面去！不过，上述的语法也不是完全不能用，亦即，若要支持比较完整的 bash 语法，那你得要使用 Type=oneshot 才行喔！ 其他的 Type 才不能支持这些字符。
|
|
ExecStop
|
与 systemctl stop 的执行有关，关闭此服务时所进行的指令。
|
|
ExecReload
|
与 systemctl reload 有关的指令行为
|
|
Restart
|
当设定 Restart=1 时，则当此 daemon 服务终止后，会再次的启动此服务。举例来说，如果你在 tty2 使用文字界面登入，操作完毕后注销，基本上，这个时候 tty2 就已经结束服务了。 但是你会看到屏幕又立刻产生一个新的 tty2 的登入画面等待你的登入！那就是 Restart 的功能！除非使用 systemctl 强制将此服务关闭，否则这个服务会源源不绝的一直重复产生！
|
|
RemainAfterExit
|
当设定为 RemainAfterExit=1 时，则当这个 daemon 所属的所有程序都终止之后，此服务会再尝试启动。这对于 Type=oneshot 的服务很有帮助！
|
|
TimeoutSec
|
若这个服务在启动或者是关闭时，因为某些缘故导致无法顺利『正常启动或正常结束』的情况下，则我们要等多久才进入『强制结束』的状态！
|
|
KillMode
|
可以是 process, control-group, none 的其中一种，如果是 process 则 daemon 终止时，只会终止主要的程序 (ExecStart 接的后面那串指令)，如果是 control-group 时， 则由此 daemon 所产生的其他 control-group 的程序，也都会被关闭。如果是 none 的话，则没有程序会被关闭喔！
|
|
RestartSec
|
与 Restart 有点相关性，如果这个服务被关闭，然后需要重新启动时，大概要 sleep 多少时间再重新启动的意思。预设是 100ms (毫秒)。
|
|
[Install] 部份
|
|
|
设定参数
|
参数意义说明
|
|
WantedBy
|
这个设定后面接的大部分是 *.target unit ！意思是，这个 unit 本身是附挂在哪一个 target unit 底下的！一般来说，大多的服务性质的 unit 都是附挂在 multi-user.target 底下！
|
|
Also
|
当目前这个 unit 本身被 enable 时，Also 后面接的 unit 也请 enable 的意思！也就是具有相依性的服务可以写在这里呢！
|
|
Alias
|
进行一个连结的别名的意思！当 systemctl enable 相关的服务时，则此服务会进行连结档的建立！以 multi-user.target 为例，这个家伙是用来作为预设操作环境 default.target 的规划， 因此当你设定用成 default.target 时 ， 这 个 /etc/systemd/system/default.target 就 会 连 结 到 /usr/lib/systemd/system/multi-user.target 啰！
|