请查找 Linux 中（用户进程）代理和安全守护进程的 Sys V Init 脚本。
代理守护进程启动脚本 /etc/rc.d/init.d/Agentdaemon /etc/rc.d/rc5.d/S91Agentdaemon
安全守护进程启动脚本 /etc/rc.d/init.d/Securitydaemon /etc/rc.d/rc5.d/S91Securitydaemon
让我们假设代理和安全守护进程都需要一个共同的父级，即共同代理。如果重新引导时未启动公共代理，则任何其他守护程序将启动公共代理，而其他守护程序将跳过启动公共代理。有“ps”命令检查通用代理是否正在运行，以跳过 Agentdaemon 和 Securitydaemon 脚本中的创建。这在 RHEL 6.2 中运行良好。但在 RHEL 7 中，我看到两个通用代理正在运行。
而且我怀疑 systemd 是否同时启动了代理和安全守护进程。不知何故，“ps”没有显示通用代理正在运行。
例如： ps -ef | grep 常见 | grep -v grep | grep -v awk '{print $2}' 未显示由其他脚本启动的公共进程，因此其他脚本也启动公共代理。
有什么方法可以避免启动脚本并行运行或者我应该将脚本迁移为 systemd 格式吗？快速解决方法比将所有脚本从 Sys V init 类型迁移到 systemd 更有趣。
答案1
我应该将脚本迁移为 systemd 格式吗？
是的。
rc您正被 System 5脚本中的一个众所周知的缺陷所困扰。这实际上与 systemd 没有任何关系。如果您设法以其他方式并行启动脚本，例如startpar， 您可能会遇到该缺陷。
众所周知，grep 的输出ps很容易发生竞争，无论是针对grep正在进行的系统状态还是针对正在进行的系统状态，人们可以发现 几十年的人报告使用不同的 shell 脚本一遍又一遍地遇到这些相同的错误。这是愚蠢和错误的，并且在 BSD 手册页的“BUGS”部分中提到过ps。世界现在应该更清楚了。
世界确实更了解这一点，而且已经有一段时间了。自 20 世纪 90 年代初以来，我们的服务管理器就可以正常工作，无需所有这些捆绑在一起的机制，这些机制涉及 grep 进程列表和文件（可能包含也可能不包含正确的编号）。你应该确实，如果您遇到这种情况和其他竞争情况，请扔掉那些摇摇欲坠、容易失败、特殊且混乱的 System 5rc脚本，并使用适当的服务管理。没有如果；没有但是；没有“快速解决方法”对您已经使用的 bodges 进行处理（额外的greps 首先本身就是一个 bodges）。
有很多这样的服务管理器。你不有使用systemd。为 runit、nosh 或 perp 编写的各种脚本与为 systemd 编写的单元文件一样简单。
在 nosh 和 systemd 的处理方式中，您没有两个主要服务来检查和运行辅助服务。这就是服务管理系统的工作。相反，你只是简单地声明依赖关系从两个主要服务到次要服务，以便服务管理系统知道当它被告知启动时它Agentdaemon.service也Securitydaemon.service必须启动common.service。在 systemd 服务单元中，这将是一个Requires=或 一个Wants=设置。
进一步阅读
- 什洛米·诺奇 (2009-10-01)。 如何不测试 mysqld 是否还活着。 code.openark.org。
- 乔纳森·德博因·波拉德 (2015)。守护进程工具家族。常见答案。
- 乔纳森·德博因·波拉德 (2014)。并排查看运行脚本和服务单元。。常见答案。
- 伦纳特·珀特林 (2013-10-07)。
systemd.unit。 systemd 手册页。 freedesktop.org。 - 格雷格·伍利奇. 《解析进程树的风险》。流程管理。格雷格的维基。