SysVInit 与 SystemD
最后更新于
最后更新于
systemd是电脑之下的一套（init），包括有、以及应用软件，由带头开发。其开发目标是提供更优秀的以表示间的依赖关系，并依此实现系统初始化时服务的并行启动，同时达到降低的的效果，最终代替现在常用的与风格init程序。
目前绝大多数的都已采用systemd代替原来的。
To start, there's a whole history and struggle between going from SysVInit to SystemD. Rather than trying to break that all down in one answer though, I'll refer you to some google venturing for more details on the history as well as one particular article on the topic:
In summary though, it's been a slow and arduous transition. Some legacy features were kept intact (such as init.d to some degree). If you have the option to use systemctl for your service control I recommend using that one. It's the foreseeable future for Linux and eventually older SysVInit methods will be considered deprecated entirely and removed.
To cover each one you listed specifically:
sudo systemctl status apache2.service
This is the new SystemD approach to handling services. Moving forward, applications on Linux are designed to uses the systemd method, not any other.
sudo /bin/systemctl status apache2.service
This is the same thing as the previous command. The only difference in this case is that it's not depending on the shell's $PATH environment variable to find the command, it's listing the command explicitly by including the path to the command.
sudo /etc/init.d/apache2 status
This is the original SysVInit method of calling on a service. Init scripts would be written for a service and placed into this directory. While this method is still used by many, service was the command that replaced this method of calling on services in SysVInit. There's some legacy functionality for this on newer systems with SystemD, but newer programs don't include this, and not all older application init scripts work with it.
sudo service apache2 status
This was the primary tool used on SysVInit systems for services. In some cases it just linked to the /etc/init.d/ scripts, but in other cases it went to an init script stored elsewhere. It was intended to provide a smoother transition into service dependency handling.
Lastly, you mention wanting to know how to get more information out of the commands, since some provide more information than others. This is almost always determined by the application and how they designed their init or service file. As a general rule though, if it completed silently it was successful. However, to verify a start, stop, or restart, you can use the status sub-command to see how it is doing. You mentioned a status command being incorrect on an old init script. That is a bug that the application developers would have to look at. However, since init scripts are becoming the deprecated method of handling services, they may just ignore the bug until they remove the init script option entirely. The systemctl status should always work correctly otherwise a bug should be logged with the application developers.