我在 3 月 31日的时候发表了一篇《shell 脚本之一键部署安装 Nginx》，介绍了如何通过 shell 脚本一键安装 Nginx
我脚本中执行了 Nginx 开机自启动的命令，当我使用 systemctl status nginx 命令复核的时候，我发现 Nginx 服务设置开机自启动并没有生效
使用下面的命令设置一下
通常来说，设置开机自启动其实就是将 nginx.service 这个文件创建一个软连接然后挂在/etc/systemd/system/multi-user.target.wants/ 目录下面
举个例子，我要将 atd.service 设置开机自启动
可以看到设置了开机自启动的服务都在这个目录下面有软连接，但是没有 Nginx 服务
我们使用下面的命令来看下 nginx 服务有没有设置开机自启动
奇怪，怎么 systemctl enable nginx.service 没有生效？
手动创建一下软链接试试
发现设置开机自启动成功
问题：使用 systemctl 命令不能设置 nginx 服务开机自启动，需要手动去挂载软连接
在排查问题之前，我先给大家简单介绍一下 daemon 与 服务（service）
daemon 与 服务（service）
我们知道，在 Linux 中，服务（service）其实就是一个个程序，它们能够实现某一功能、提供某一服务
但通常我们在查阅类 Unix 系统相关的技术文档时，又经常会看到“请启动某某 daemon 来提供某某功能”
那么这个 daemon 到底是啥意思？它跟 service 有什么区别？
简单点来说，系统为了实现某些功能必须要提供一些服务（比如想要实现负载均衡的功能需要提供 Nginx 服务）
但是提供的 service 需要程序的运作（例如你需要启动 Nginx 进程），所以我们一般认为使系统能够提供某些 service 的程序称作 daemon（例如使系统能够提供负载均衡服务的程序 nginx 为 daemon）
看到这里小伙伴们可能都晕了，说实话我第一次看到的时候也是这样的
其实你不必去区分什么是 daemon 和 service，因为提供某一 service 是需要一个 daemon 在运作，没有这个运作的 daemon 就不会有这个 service
无论是命令行模式（runlevel 3），还是图像界面模式（runlevel 5），我们在开机进入 Linux 主机之后，系统已经开始提供很多 service 了（例如 sshd ）
那么这些 service 是如何启动的，系统又是怎么管理它们的呢？
在早期 Linux 是使用 SystemV 来管理服务的，启动系统服务的管理方式被称为 SysV 的 init 脚本处理方式——系统内核第一个程序是 init，然后 init 去唤起所有系统需要的服务
SystemV 管理服务的开机自启动有两种方式：
通过挂软连接的方式
将 /etc/rc.d/rc[0-6]/SXX 服务名字挂载到 /etc/init.d/ 下（其中 SXX 中的 S 表示启动该服务，XX 是数字，为启动的顺序）
通过 chkconfig 命令
创建软连接的方式比较麻烦，一般来说都是用命令来管理
但是 CentOS 7 之后就放弃了使用多年的 SystemV ，改用 systemd 来管理服务
systemd 管理服务
systemd 将过去所谓的 daemon 程序称作一个个服务单位（unit），而每个 unit 根据功能来区分成不同的类型（type）：
系统服务（service）
负责网络数据监听与交换的服务（socket）
快照服务（sanpshot）
而且 systemd 将许多的 unit 集合成一个所谓的 target 项目，你执行某个 target 其实就是执行 target 下的多个 unit
可能有小伙伴觉得，这么多 unit 分成不同的 type，然后又被合集到不同的 target ，管理起来不会很麻烦吗
其实也还好，因为相关的文件都存放在下面的目录当中了
总结，系统开机会不会执行某些服务是看 /etc/systemd/system/ 目录下有没有该服务的启动脚本，而服务的启动脚本是放在 /usr/lib/systemd/system/下的
systemctl 命令
systemd 来管理服务的方式是通过 systemctl 命令，相较于 SysV 通过 service / chkconfig / setup / init 一堆命令，systemd 管理服务的方式简单多了
PS：关闭服务除了 systemctl 命令，也能用 kill 命令的方式，但是这两个命令不要混用！
服务的状态
服务的当前状态：
active (running)：表示服务正在运行
active (exited)：表示该服务执行一次就正常结束，目前没有执行
active (waiting)：表示该服务正在运行，不要需要等待其他事件执行之后才能继续处理
inactive：表示服务目前关闭，没有运行
服务预设状态：
enable：开机的时候将自启动
disable：开机的时候不会自启动
static：这个服务不会开机自启动，但是有可能会被其他开机自启动的服务来唤醒（依赖性）
mask：无论如何都不会被启动，因为已经被强制注销
服务的启动文件
前面我们说过，服务的启动脚本文件放在 /usr/lib/systemd/system/下的，如果需要对服务的启动脚本文件修改，需要进入到该目录下（官方不建议直接修改该目录下的文件，但是会比较麻烦且繁琐）
我们就拿 sshd.service 举例，来了解下服务的启动脚本里面的配置字段
分析上面文件中的内容，我们可以看到分成了三个部分（block）：
[Unit]
unit（即服务）本身的说明，以及与其他服务的依赖性设定（After、Wants 字段）
[Service]
还有 [Socket], [Timer], [Mount], [Path] 等等，不同的 type 就用不同的字段
我们拿的是 sshd.service，所以就是 [Service]
这个部分中主要规定了服务的启动脚本、环境文件名、重启方式等等
[Install]
表示这个服务安装到哪个 target 下面去
这部分与 systemctl enable 或 systemctl disable 命令相结合，用于 enable 或 disable 一个服务
下面我将分别列出三个部分的一些常见配置字段
现在我们已经大致对 Linux 的服务有了一个初步了解
我们回到刚开始的问题：nginx 服务无法通过 systemctl 命令设置开机自启动，手动挂载软连接之后自启动状态不是 enable ，而是 static
既然是跟 systemctl 相关的，我们去看下 nginx 的服务启动脚本
可以看到，这台机器上 nginx 的服务启动脚本只有两个部分（[Unit]、[Service]），并没有 [Install]
而 [Install] 部分往往是跟服务的开机自启动相关
我们加上 [Install]
其中 multi-user.target 表示命令行模式（即等效于系统运行级别为 3 ）
而 WantedBy表示该服务放在哪个 target 下，一般来讲 WantedBy 对应的 target 为指定系统的运行级别
然后重启一下 nginx 启动脚本文件
设置开机自启动，发现创建软连接成功了
看下状态
总结：
一般来讲，服务无法设置开机自启动首先考虑是不是服务启动脚本配置有问题（/usr/lib/systemd/system/ 目录下），这种情况常见于编译安装的时候需要自己编写服务启动文件
服务能够开机自启动其实就是将 /usr/lib/systemd/system/ 目录下的服务启动脚本挂载到了 /etc/systemd/system/ 下，一般是挂载到 /etc/systemd/system/multi-user.target.wants/
multi-user.target.wants：表示启动了 multi-user.target 之后（即系统启动且运行级别为 3，为系统的默认启动 target）这个目录下的文件都会跟着启动
systemctl status 命令显示的内容里面有一个 vendor preset: disabled 字段，这个表示该服务首次安装之后不会自启动，需要手动启动（systemctl enable）
感谢阅读，喜欢作者就动动小手[一键三连]，这是我写作最大的动力