假设app服务器上安装了一个应用程序，并且它提供了一个名为 的应用程序控件appctl。作为管理员，我可以通过以下方式启动/停止/重新启动应用程序appctl：
appctl start
appctl stop
appctl restart
然后我意识到我应该使用systemctl来执行此操作，因此我编写了一个app.service并将服务文件链接到/etc/systemd/system.重新加载守护进程后，我可以通过以下方式启动/停止/重新启动应用程序systemctl：
systemctl start app.service
systemctl stop app.service
systemctl restart app.service
现在我的问题来了：使用 停止我的应用程序后appctl restart，系统中的状态systemctl status app.service显示自 1 小时前起不活动（死亡）。这并不反映应用程序的真实状态。可以接受吗？
个人感觉很正常，因为我没用过systemctl重启。但我想要更多的论据，比如文档中的引用、systemctl内部机制的分析。
答案1
你说得对，这就是预期的结果。我并不指望appctl能够阻止这种情况的发生。然而，可能值得考虑如何鼓励正确使用。
系统管理员可能需要被告知他们不应该直接使用appctl start/restart.不仅仅是服务状态“不能反映应用程序的真实状态”。您已经绕过了 systemd，失去了任何优势，例如守护进程将从您运行appctl start的任何 shell 继承各种属性。并且systemctl stop app.service不会工作:)。此外，任何自定义关闭处理（例如）ExecStop=都不会在系统关闭时运行。
systemd 自己的守护程序通过安装在 /usr/lib 的子目录下而不是 /usr/bin 或 /usr/sbin 来鼓励这样做。 systemd-udevd例如，不在用户的 PATH 中。 /usr/libexec/（无论是否为子目录）可用于相同的操作。从技术上讲，即使提供系统 V 风格的 initscript，您也可以做同样的事情......
然而，有一些参数可以方便地访问守护程序，例如，当您有复杂的配置并希望在终端中获取错误消息时。一个例子是apache -t。
如果您有除reload（systemd 服务也可以定义 ExecReload）和启动/重新启动/停止之外的动词，您可能希望将它们分开。例如，使用主守护程序二进制文件来实现这四个，并将其他任何内容放入appctl.例如，Apache 的优雅重启就属于这一类。
系统管理员“应该”已经明白，appd直接启动有很大的缺点，即使它在他们的路径中，但从appctl他们的终端运行是可以的。