Systemctl vs Service – Deciding the Better Command?

Stuck figuring out which command to run to manage the services running on your Linux machine? Trying to figure out why System and Systemctl are sometimes used interchangeably and at other times not quite so?

If you’re here trying to get the answers to all these questions and are looking to dive deeper into the implicit workings of these two command types, then you’ve landed on the right page!

To figure out the differences between these two, as with any other software, we need to take a look at the underlying code and how it runs. In this case, it’s going to be the Linux kernel, and the accompanying init daemon process that every machine runs at boot.

What Are Systemctl Or Service Commands?

Before diving into the technical differences between the two, a general overview of what the Linux init system is needed. In Unix-based operating systems, the first process that is started during bootup is the init, short for initialization, process. That is why init is typically assigned process identifier one.

Init is a daemon process that remains active throughout a user session till system termination. It is responsible for spawning/starting all other processes and as such is responsible for the initialization of the system.

Everything from starting services (such as a firewall) to resetting or terminating processes falls into the init daemon’s responsibility. As it’s the first process, init is started by the kernel during bootup. Moreover being the first process to run, init is responsible for starting all other critical system processes and services.

There are two most relevant init systems in Linux, namely System V init (SysV) and SystemD. For SysVInit, the Service command is used, while Systemctl is utilized for SystemD.

Systemctl vs Service

Differences Between Systemctl And System Commands

While being ‘init’ systems at the core and performing more or less the same actions, some differences separate these two commands. The biggest one is the different architecture that these are based on. Most other differences stem from this fact.

Init Systems

Systemctl is the command interface of the SysVInit system. It is a more recent release that aims to replace systemd as the default init system. It offers new features such as parallel service load-up at boot and on-demand activation of a service.

While initially being a purely systemd init command, ‘service’ has extended itself to perform as a wrapper function for any underlying init system the machine is running. It tries running different commands (even other than Systemctl) in order until one runs. If all else fails, it falls back to basic init functions.

Thus if all you want to do is a simple service-related task such as restarting or terminating one and you are not sure of the underlying service management architecture, you can simply use ‘service’ commands. They’ll be sure to get the job done as they are translated to whatever service management system is running under the hood.

Portability

In the same vein as the above discussion about there being different init systems, the need for a central command to start and stop services would emerge. This is where ‘service’ comes into play.

Regardless of the Linux distro, you are using, you can be certain that you can use the service command to perform standard operations such as starting, stopping, or examining the status of a service.

The reason this is possible is because of the aforementioned fact that the service command is simply a wrapper script that tries to run all equivalent init commands during execution until it finds one that works.

Systemctl does not offer the same portability. Suppose the Linux distro you are using does not run systemd under the hood. In that case, you won’t be able to call the Systemctl command as the machine will not recognize the Systemctl function call, even though the equivalent system call might be available.

Functionality

Being a wrapper function, the system command can do much more than what a direct Systemctl command might be able to do. Such as, it ‘cleans’ the data before execution, meaning that any sort of variables or extraneous scripts are removed from the command before executing the called scripts.

Another additional functionality that ‘system’ commands have is that if you use them to terminate a service, they also stop the sockets connected to that service. This is important in servers where each socket handles a client and needs to be freed up afterward so that new clients can be accommodated.

On the flip side, Systemctl provides users with more control and a wider array of commands to run. While system commands have extra external functionality, the Systemctl commands offer implicit diversity in terms of what a user can do.

For example, using Systemctl, users can list all services running on a system or mask/unmask services. You can mask a service so that other services cannot activate or enable it.

Verdict: System Or Service Commands

For simple requirements such as stopping or restarting a service, System commands will do just fine as they will call the underlying Systemctl command if one exists or just use the init ones. If you need more powerful and modern service management, then you’ll have to invoke specific Systemctl commands.

Below we provide all the aforementioned differences in a table.

Features	System	Systemctl
Init System	Result of the classic init system used in systemd machines	A newer superset of commands that are built on top of the SysV architecture
Portability	Wrapper function thus can run on any Linux distro for architecture.	Cannot run on non-SysV systems, particularly older devices
Functionality	Extra error checks and data validation before the command is sent to be executed	More powerful commands that can do more than what simple system commands do

Conclusion

While from a technical or developer perspective, there are differences between the two types of system commands, in general, most people can live without getting into the nitty gritty.

With one being backward compatible and the other acting as a wrapper function that calls all System commands, usage-wise, they are pretty much the same.