Difference between systemctl init.d and service
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:
-
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 inSysVInit
. There's some legacy functionality for this on newer systems withSystemD
, 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.
Related videos on Youtube
Waqas Tariq
I am from Lahore, Pakistan and currently living in Karachi with 2 kids and a beautiful wife. I freelance for a living.
Updated on September 18, 2022Comments
-
Waqas Tariq over 1 year
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.
- Should I prefer one command over the other?
- If yes then why?
- 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.
-
Panther about 7 yearsIn Linux there is often more then one way to perform an action. There is not one that is better or worse or right or wrong. Personally I use the one with the least typing. Many of these commands may be sym links or back compatibility as Ubuntu changes to systemd.
-
Panther about 7 years
systemctl
is the preferred syntax andservice
is provided as backward compatibility./etc/init.d/pure-ftpd
or similar are calling the start/stop scripts directly.
-
Waqas Tariq about 7 yearsThank you so much for your detailed reply. I am also Googling for answers but this one really confused me, so I posted it here. I also see that sudo systemctl status apache2 works, instead of (sudo systemctl status apache2.service). Is there a harm in foregoing the .service part?
-
TopHat about 7 years@WaqasTariq no problem! Both of those should work,
systemctl
will search the directories where the service files are stored and add the ".service" for you if it finds it. So for example, if you hit tab once after only writingsudo systemctl status apache2
it should complete it by adding.service
for you. If there's more than one apache2 systemctl file (such as.service
and a.target
you'd have to hit tab twice so that it shows you all the available options. -
Waqas Tariq about 7 yearsGot it. Thank you for your answers and your time.
-
TopHat about 7 years@WaqasTariq your welcome!