As a systems administrator, you are tasked to handle quite a lot. And that list grows longer and more complicated every day. To make matters worse, things change. I remember, back in the day, to start or stop a Linux service, I’d have to open a terminal window, change into the /etc/rc.d/ (or /etc/init.d, depending upon which distribution I was using), locate the service, and the issue the command /etc/rc.d/SERVICE start|stop|restart (Where SERVICE is the name of the service to be started, stopped, or restarted). When working between Redhat and Debian distributions, that had a tendency to get confusing; I’d try to issue /etc/rc.d/service start on one distribution, only to find out it should have been /etc/init.d/service start.

That has changed. How a service is stopped, started, and restarted now makes perfect sense. Even better, it has (for the most part) become universal.

Sort of.

How you start|stop|restart a service will depend upon whether your distribution uses systemd or init. Even then, you might be able to control those services via multiple means. Let me explain.

systemctl vs. service

This is the crux of the issue. There are two officially adopted methods for controlling services:

  • systemctl
  • service

Which one you use will depend on if your distribution makes use of systemd or init. Most modern distributions have made the switch to systemd, so systemctl is the service manager of choice. However, old habits die hard, so many administrators still hold onto the aging service command. Fortunately, the developers of systemd made sure to retain service and redirect it to systemctl. To complicate matters more, you might find a random service you’ve installed that hasn’t been updated to either the service or systemctl tools and have to manually start it from with /etc/rc.d (or /etc/init.d).

So it can still be a bit confusing.

But we’re looking for best practices here; and for starting|stopping|restarting applications on Linux, best practices begin and end with systemctl.

systemctl usage

The complication ends here. In fact, the stopping|starting|restarting of services on Linux is now quite simple. Let’s say we’re on CentOS and we want to stop the Apache server. To do this we’d open up a terminal window and issue the command:

sudo systemctl stop httpd

The Apache server would stop and you’d be returned to the bash prompt. To start the same service, we’d issue the command:

sudo systemctl start httpd

The service would start and you’d be returned to your bash prompt.

To restart the same service, we’d issue the command:

sudo systemctl restart httpd

The service would restart and you’d be returned to the bash prompt.

The above commands can be run on CentOS, Ubuntu, Redhat, Fedora, Debian, and many more.

service usage

To make matters interesting, the service command still works — even for those distributions that have migrated to systemd and systemctl. This means those who instinctively type service, when needing to restart a service on Linux, won’t receive an “Unknown command” error. In the case of service, the command will redirect to systemctl. In fact, when you run the service command on a systemctl-enabled distribution, you will clearly see the redirect information (Figure A).

Figure A

The service command usage is a bit different from systemctl. The service name and start|stop|restart options are switched:

sudo service httpd start
​sudo service httpd stop
​sudo service httpd restart

In each case, you will see service redirected to systemctl, but the service you are attempted to start|stop|restart will succeed in doing so.

It’s not that complicated

I’ve complicated the issue by mentioning the old methods of starting, stopping, and restarting services in Linux. Truth be told, the process of controlling services in Linux is not that complex; you only have to understand the right command to use.

To learn more about what systemctl can do you for, make sure to issue the command man systemctl and give the man page a read.