systemctl init.d 和 service 的区别

Question

我是 Linux 新手，一直在使用 Amazon Lightsail 实例 (Ubuntu 16.04 LTS) 测试自己。

通过我遇到的许多指南，我看到人们使用不同的命令来启动/停止/重启/重新加载/状态检查服务。特别是这些；

sudo systemctl status apache2.service
sudo /bin/systemctl status apache2.service
sudo /etc/init.d/apache2 status
sudo service apache2 status

以上所有命令都有效。

1. 我应该更喜欢一个命令吗？
2. 如果是，那为什么？
3. 还有其他我需要注意的命令吗？

当我想使用状态选项时，在 Monit 中使用 init.d 会导致问题（状态将是服务在实际在线时处于离线状态——由 Monit 重新启动）。将 Monit 中的代码从 inid.d 更改为 /bin/systemctl 修复它。

似乎使用 init.d 提供了更多关于其他人发生的事情的信息。如果我应该使用其他命令之一，是否可以让它们显示有关已完成操作的更多信息？

ubuntu@ip-172-26-12-245:~$ sudo systemctl restart pure-ftpd.service
ubuntu@ip-172-26-12-245:~$ sudo /bin/systemctl restart pure-ftpd.service
ubuntu@ip-172-26-12-245:~$ sudo /etc/init.d/pure-ftpd restart
[ ok ] Restarting pure-ftpd (via systemctl): pure-ftpd.service.
ubuntu@ip-172-26-12-245:~$ sudo service pure-ftpd restart
ubuntu@ip-172-26-12-245:~$

我要提前感谢所有花时间阅读和回答这个问题的人。

Answer 1

首先，从SysVInit到之间有一段完整的历史和斗争SystemD。不过，与其试图在一个答案中分解所有内容，不如让您参考一些 google 冒险，以了解有关历史的更多详细信息以及有关该主题的一篇特定文章：

'init' 和 'systemd' 背后的故事：为什么在 Linux 中需要用 'systemd' 替换 'init'

总之，这是一个缓慢而艰巨的转变。一些遗留功能保持不变（例如在init.d某种程度上）。如果您可以选择systemctl用于服务控制，我建议您使用该选项。这是 Linux 可预见的未来，最终旧SysVInit方法将被视为完全弃用并删除。

要涵盖您具体列出的每一项：

1. sudo systemctl status apache2.service

   这是SystemD处理服务的新方法。展望未来，Linux 上的应用程序旨在使用 systemd 方法，而不是其他任何方法。

2. sudo /bin/systemctl status apache2.service

   这与之前的命令相同。在这种情况下唯一的区别是它不依赖于 shell 的$PATH环境变量来查找命令，它通过包含命令的路径来显式列出命令。

3. sudo /etc/init.d/apache2 status

   这是SysVInit调用服务的原始方法。将为服务编写初始化脚本并将其放置在此目录中。虽然这种方法仍然被许多人使用，但service在SysVInit. 在带有 的较新系统上有一些遗留功能SystemD，但较新的程序不包含此功能，并且并非所有较旧的应用程序初始化脚本都可以使用它。

4. sudo service apache2 status

   这是SysVInit用于服务系统的主要工具。在某些情况下，它只是链接到/etc/init.d/脚本，但在其他情况下，它会转到存储在其他地方的 init 脚本。它旨在提供更平滑的过渡到服务依赖处理。

最后，您提到想知道如何从命令中获取更多信息，因为有些命令提供的信息比其他命令多。这几乎总是由应用程序以及它们如何设计 init 或服务文件决定。但是，作为一般规则，如果它默默地完成，则它是成功的。然而，为了验证start，stop或者restart，你可以使用status子命令，看看它是如何做的。您提到status旧的 init 脚本中的命令不正确。这是应用程序开发人员必须查看的错误。但是，由于 init 脚本正在成为不推荐使用的处理服务的方法，因此它们可能会忽略该错误，直到完全删除 init 脚本选项。这systemctl status 应始终正常工作，否则应与应用程序开发人员一起记录错误。