SysVInit 与 SystemD

systemd是Linux电脑操作系统之下的一套中央化系统及设置管理程序（init），包括有守护进程、程序库以及应用软件，由Lennart Poettering带头开发。其开发目标是提供更优秀的框架以表示系统服务间的依赖关系，并依此实现系统初始化时服务的并行启动，同时达到降低Shell的系统开销的效果，最终代替现在常用的System V与BSD风格init程序。

目前绝大多数的Linux发行版都已采用systemd代替原来的System V。

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:

The Story Behind 'init' and 'systemd': Why 'init' Needed to be Replaced with 'systemd' in Linux

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:

1. 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.

2. 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.

3. 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.

4. 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.