Difference between systemctl init.d and service

I am new to linux and have been testing myself using an Amazon Lightsail instance (Ubuntu 16.04 LTS).

Going through the many guides I have came across, I see people using different commands to start/stop/restart/reload/status-check a service. Specifically these;

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

All the above commands work.

1. Should I prefer one command over the other?
2. If yes then why?
3. Are there any other commands I need to be aware of?

Using init.d in Monit caused issues when I wanted to use the status option (status will be that the service is offline when it was actually online -- restarted by Monit). Change the code in Monit from inid.d to /bin/systemctl fixed it.

It seems that using init.d provides more information on what happened that the others. If I should be using one of the other commands, is it possible to have them display more information on what was done?

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:~$

I would like to thank everyone in advance who has taken the time to read and reply to this question.

Solution 1:

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.