On quite a few Linux distributions these days, the init system has been switched to systemd. This is true of Debian and CentOS starting with Version 8 and 7, respectively, but other distributions such as Fedora, Ubuntu, Arch Linux, and others have switched as well. Although some administrators prefer sysvinit, which was the previous dominant init system, systemd offers quite a few advancements over older systems.

With systemd, commands you would use to start processes are now different, though the majority of the older commands still work (for now). With sysvinit on a Debian 7 system, you would use the following command to restart Samba:

/etc/init.d/samba restart

However, with systemd, we now use systemctl to start, stop, or restart a process:

# systemctl restart samba

The sysvinit style of managing processes was the same in CentOS and Debian, and it is still the same now. At the time of this writing, both have switched to systemd. But the older /etc/init.d/<process-name> restart|stop|start commands still work in both Debian and CentOS with current releases, but instead of using sysvinit (which is gone) the commands are just translated to systemd commands instead. If you were to run the older sysvinit style commands, you'll likely see some text in the output informing you that the system is using systemctl instead. While this is great for the sake of compatibility (scripts relying on sysvinit style commands will likely still work), this won't be around forever. Learning systemd is important as once the sysvinit compatibility layer is removed, you'll no longer be able to rely on the older method. Thankfully, the basics of systemd are quick to learn.

To start a process with systemd, execute systemctl followed by the action you want to perform, followed by the process you would like to perform the action on. As we've done earlier with Samba, we executed systemctl restart samba. But we can also stop samba using systemctl stop samba, or we can start it by executing systemctl start samba as root.

The systemd init system also allows you to enable or disable a process. A process which is enabled will be started as the system is booted. A disabled process will only start if you do so manually. Depending on the distribution, processes (or units, as systemd calls them) may not be enabled by default. On CentOS, for example, you can install Samba, but it won't start automatically unless you tell it to do so. On Debian systems, it's largely assumed that since you installed something, you probably want it to run, so it will enable the newly installed process by default. Either way, it's not a good idea to assume that a process will automatically start with systemd. To find out, use the following command:

systemctl status <process>

Checking the status of a unit with systemctl

Checking the status with systemctl gives you a great deal of useful information, typically more than checking the status of processes with sysvinit. First, you can see whether or not a unit is running. In the previous screenshot, we can see that nfs-kernel-server is running. In addition, status gives us a few lines of log output as well, so if there are any problems starting a unit we may find the error right there.

You might be wondering how to find out whether or not a unit is configured to come up automatically when the system is booted. Systemd makes that easy as well. We can use is-enabled with systemctl in order to find out if the unit is enabled. For example, to ensure the ssh daemon is configured to automatically start, we would issue the following command on a Debian system:

systemctl is-enabled ssh

To show all the units on your system and how they're configured, run the following command:

systemctl list-unit-files

To enable a unit, pass enable as a parameter to systemctl. Similarly, you can do the same with disable to ensure a unit does not start at boot. Therefore, on a Debian system, systemctl enable ssh would configure the ssh daemon to start at boot, while systemctl disable ssh would ensure that it doesn't. CentOS would be the same, but substitute sshd for ssh. While the differing unit names can be annoying between Linux systems, always remember that you can use systemctl list-unit-files as mentioned earlier to see a list of the units registered to your system and what they're named.

In a nutshell, that's pretty much all the knowledge required to use systemctl to manage processes (units) on your Linux system. For the most part, starting, stopping, enabling, and disabling units covers most use cases. For more advanced usage, see the man page for systemctl.