How can I start, stop or restart services using the `systemctl` command?

Linux 3 min read

systemctl is the command-line tool for managing systems and services in systemd. On almost all modern Linux distributions (AlmaLinux, Rocky Linux, CloudLinux, Ubuntu, Debian), it can be used to start, stop and monitor services running in the background, such as the web server, the database or the SSH server. root or sudo privileges are required to manage services, so this article is intended for those operating their own VPS or dedicated server.

Start, stop, restart

sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx
sudo systemctl reload nginx

A restart stops and restarts the service, causing a brief outage. A reload simply re-reads the settings without interruption; not all services support this, in which case systemctl reload-or-restart is the safe option. Before making configuration changes, it is advisable to test the settings using the service’s own checker (for example, nginx -t, apachectl configtest or sshd -t), as the service will not restart if there is an error in the file.

It is not necessary to specify the .service suffix; systemctl restart nginx and systemctl restart nginx.service mean the same thing.

Check status

systemctl status nginx
systemctl is-active nginx
systemctl --failed

The status shows whether the service is running (active (running)), how long it has been running, its process ID (PID), and also displays the most recent log entries. The is-active command returns a single-word response, making it useful in scripts. The systemctl --failed command lists all services in a failed systemctl --failed.

Automatic start-up at system boot

sudo systemctl enable nginx
sudo systemctl enable --now nginx
sudo systemctl disable nginx
systemctl is-enabled nginx

The enable command sets the service to start automatically after the server is restarted, but does not actually start the service itself. The enable --now command both enables and starts the service in a single step. The disable command disables automatic start-up. The mask command can be used to completely disable a service, meaning it cannot even be started manually until it is unmasked using unmask. During testing, an attempt to start a masked service resulted in the following: Failed to start crond.service: Unit crond.service is masked.

Common service names

The names of the services may vary depending on the distribution:

Service AlmaLinux, Rocky Linux Debian, Ubuntu
Apache web server httpd apache2
MariaDB database mariadb mariadb
SSH server sshd ssh
Scheduled tasks crond cron
Firewall firewalld ufw

There are a few differences on the test machines (AlmaLinux 10.2, Ubuntu 24.04, Debian 12 cloud image):

  • On Debian, the name sshd also works, as it is an ssh.service of alias.
  • On Ubuntu 24.04, SSH is started via socket activation: the ssh.service is disabled, the ssh.socket listens on port 22, and the service is started upon the first connection. This is important when changing the SSH port (see: SSH server security settings).
  • ufw is installed on Ubuntu, but is not enabled by default; the Debian cloud image does not include either ufw or firewalld, and cron is not installed either (sudo apt install cron).

The command systemctl list-units --type=service displays a list of all loaded services. You can read more about SSH in our article on Linux Secure Shell (SSH).

What should you do if a service fails to start?

  1. Check the output of the systemctl status szolgaltatas command: the error message is often visible here.
  2. Retrieve the full log for the service: journalctl -u szolgaltatas -n 50 --no-pager. Our article on reading logs covers journalctl and the /var/log directory.
  3. Common causes: a syntax error in the configuration file, a port already in use by another program (the command ss -tlnp shows what is listening on that port), insufficient disk space or incorrect file permissions.
  4. If you have modified a unit file (/etc/systemd/system/*.service), run the command sudo systemctl daemon-reload, otherwise systemd will continue to use the old configuration.
Back: Linux articles (62)