如何在RHEL / CentOS 7中启动时自动启动服务？

想知道如何在后台或启动时管理服务？

引导过程中用于管理和启动进程的机制已更改。在RHEL / CentOS 6.x之前, 你将在/etc/init.d/中创建一个脚本, 并在chkconfig的帮助下启用该脚本, 但是RHEL 7上的情况有所不同。

它已被systemd取代, 并且由于它或多或少是主要Linux版本上的默认流程管理器, 因此精通其他版本的System Admin会让你感到宾至如归。在本文中, 我们将探讨什么是systemd, 切换的原因是什么, 以及如何使用systemd来设置, 运行和管理后台进程。

什么是系统化的？

由于Linux中的每个进程都是透明可见的, 因此让我们看看systemd潜伏在哪里。在我的系统上, 我得到以下信息：

~$ ps -ef | grep systemd
root         1     0  0 Nov11 ?        00:01:02 /lib/systemd/systemd --system --deserialize 22
message+   768     1  0 Nov11 ?        00:05:46 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
root       805     1  0 Nov11 ?        00:10:22 /lib/systemd/systemd-logind
ankush    1132     1  0 Nov11 ?        00:00:00 /lib/systemd/systemd --user
ankush    1176  1132  0 Nov11 ?        00:04:50 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
ankush    9772 20029  0 21:11 pts/6    00:00:00 grep --color=auto systemd
systemd+ 17298     1  0 Nov19 ?        00:00:12 /lib/systemd/systemd-resolved
systemd+ 17303     1  0 Nov19 ?        00:00:00 /lib/systemd/systemd-timesyncd
root     17307     1  0 Nov19 ?        00:00:02 /lib/systemd/systemd-journald
root     18182     1  0 Nov19 ?        00:00:00 /lib/systemd/systemd-udevd

我敢打赌, 你会立即注意到它。清单中的第一个进程以用户root身份启动, 并且具有pid 1。

果然, 这是系统在启动时启动的第一个过程。向systemd打个招呼。 ????

因此, 很简单, systemd是启动, 管理和终止系统中其他进程的”母”进程, 除了提供有关它们的日志记录, 文件系统状态等信息外。

不过, 请注意名称。该名称确实是systemd, 而不是System D或其他名称。 ” d”代表守护程序, 它是标准的Linux进程, 在后台运行(潜伏？), 并且未附加到任何终端会话中。

为什么RHEL切换到systemd？

正如我们已经讨论的那样, systemd是系统和流程管理器, 在RHEL 7中代替了著名的程序Upstart。为什么RHEL(Oracle？)做出此决定？好吧, 这有很好的理由, 让我们快速看一下。

并行服务初始化

与SysV init程序不同, systemd能够并行启动服务。相比之下, init程序将它们一一启动。在一个甚至移动设备都具有多核CPU的时代, 缺乏并行初始化也是一大障碍。

动态(热)服务管理

如果你注意到USB驱动器需要在早期的Fedora系统上显式安装, 而它们会在Ubuntu和类似发行版上自动弹出, 则原因是系统化的。它能够检测硬件的实时变化并根据需要终止/启动服务。有人可以说这是不必要的, 但对许多人而言, 减少认知负担的任何事情都是最受欢迎的。

推迟服务启动

systemd可以缩短启动时间, 因为它可以将服务启动推迟到实际需要的时间。一个简单的示例是与网络文件系统相关的服务。如果没有可用的网络磁盘, 则没有必要启动并运行服务。

更快的过程通讯

systemd的并行功能可以继续进行进程间通信。 systemd能够提供对套接字和系统总线的并行访问, 从而大大减少了通信资源的进程等待时间。

自动重启

如果服务崩溃, systemd可以检测到该情况并尝试重新启动它。在大多数情况下, 除非有更根本的问题, 否则只需重新启动即可使应用程序重新开始运行。

无论如何, systemd在这里使sysadmin的工作更加轻松。

RHEL7中的systemd –对系统管理员有哪些更改？

如果你system昧地认为systemd不会一团糟, 那你是对的。有一些重大的不兼容性可能会令RHEL sysadmin措手不及。让我们快速浏览一下。

有限的运行级别支持

systemd对运行级别有很差的认可和支持。并非所有运行级别都受支持, 对于某些目标甚至可能没有任何运行级别。在这种情况下, systemd返回” N”作为对运行级别命令的响应, 表示它没有与此目标相对应的运行级别。总而言之, Red Hat建议我们不要使用(！)运行级别命令。

没有自定义命令

这个人会受伤的。 SysV的一大优点是能够定义自定义命令, 以提供更好的功能来管理进程。使用systemd时, 没有这样的选项, 你会陷入开始, 停止, 状态, 重新启动等问题。

仅限家庭和非互动

systemd(当然)跟踪已启动的进程并存储其PID。但是, 挑战在于systemd无法处理其未启动的进程。此外, 用户不可能与systemd启动的进程进行交互。所有输出都输出到/ dev / null, 有效地停止了你可能希望捕获输出的任何希望。

没有上下文

与init服务不同, systemd启动的服务不会从系统中的任何用户继承任何环境。换句话说, PATH和其他系统变量之类的信息不可用, 每个新进程都在空的上下文中启动。

如果此限制列表让你哭泣, 那么你并不孤单。 systemd在Linux领域一直是两极分化的力量, 而对” systemd糟透了”的谷歌搜索将挖掘出大量的阅读材料。 ????

停机时如何自动启动服务？

这是部署中一个非常普遍的用例。我们需要使用一种无​​需长时间运行的语言来守护程序：PHP！假设我编写了一个PHP脚本来处理传入的Websocket连接(毕竟, 我们构建了一个聊天应用程序！), 该脚本位于/home/ankush/chat_server/index.php。

由于websocket连接可以随时连接到服务器, 因此该过程需要一直保持下去并监视传入的连接。这里没有传统的PHP生命周期, 因为WebSockets是有状态的连接, 并且如果脚本死了, 则该连接是一个列表。无论如何, 在websocket上足够了；让我们看看如何通过systemd来守护该脚本。

所有systemd服务都位于/ etc / systemd / system中, 因此让我们在此处创建一个文件来描述我们的websocket服务器脚本。假设你以root用户身份登录。

# vi /etc/systemd/system/chat_server.service

然后需要以下内容。

[Unit]
Description=Chat Server Service
After=network.target

[Service]
Type=simple
User=ankush
ExecStart=php /home/ankush/chat_server/index.php
Restart=on-abort


[Install]
WantedBy=multi-user.target

保存文件, 下一步是重新加载systemd守护程序

# systemctl daemon-reload

并启动我们刚刚创建的服务：

# systemctl start chat_server

如果你没有看到错误, 就是这样！

让我们快速查看一下文件中的各种指令的含义：

• [Unit]部分为systemd定义了一个新的服务单元。用系统的话来说, 所有服务都称为服务单元。
• After指令(可以预测)告诉systemd仅在网络服务启动后才启动此服务(否则, 谁将对套接字连接进行低级处理？！)。
• Type = simple告诉systemd该服务不应该进行分叉。换句话说, 任何给定时间都将只运行一个实例。
• User = ankush表示该服务将以用户” ankush”的身份运行。我们可以将其更改为” root”, 但是从安全角度来看, 我们不建议这样做。
• 如你所知, ExecStart是要运行的实际命令。
• Restart = on-abort表示该服务在中止时应重新启动。在PHP中, 长时间运行的进程会泄漏内存并最终爆炸, 因此需要这样做。
• WantedBy =指令告诉systemd该服务属于哪个目标(认为是组)。这将导致在目标内部创建指向服务的符号链接。

通常, 足够使用RHEL 7中的systemd运行后台进程。

重新启动逻辑的更多选项

在上面的示例中, 我已经配置了Restart = on-abort, 但这不是唯一的选择。还有更多根据需求选择。

• 失败–退出代码或信号不洁时将重新启动
• 始终–出现故障, 干净或不干净的信号时重新启动
• 异常–不干净的信号, 看门狗或超时
• 成功–仅当它被清除信号或退出代码停止时

配置服务以在启动时启动

对脚本满意并确保其可以使用后, 接下来你要对其进行配置, 以使其在启动和启动时触发。

转到/ etc / systemd / system并执行以下enable命令(不要忘记使用你拥有的名称更改.service文件名)

# systemctl enable chat_server.service

你会看到确认已创建符号链接。

Created symlink from /etc/systemd/system/multi-user.target.wants/chat_server.service to /etc/systemd/system/chat_server.service.

重新启动服务器, 你应该会在引导中看到服务启动。

那很简单！是不是

救命！我对Upstart进行了大量投资。 ????

我了解你信任我, 你的情况是规范而不是例外。 RHEL使用Upstart已有很长时间了, 以至于切换感觉就像是在背叛。但是, 嘿, 系统不断变化, 我们不应该为琐事争吵。红帽认识到许多人都固守旧版本, 并创建了一个你绝对应该参考的迁移指南。

所有这方面的一个节省之处是systemd与SysV初始化脚本兼容, 因此在大多数情况下, 你只需要移动文件并运行相同的服务即可。

有兴趣了解有关Linux管理和故障排除的更多信息吗？查看此在线课程。