systemctl Command in Linux: Start, Stop, and Manage Services

Every modern Linux distribution runs a handful of services in the background at any given moment: an SSH daemon, a cron daemon, a web server, a database, a firewall. On systemd-based systems, the one tool you use to control all of them is systemctl.

systemctl is the command-line front end for systemd. It starts and stops services, enables them at boot, reloads unit files after an edit, and reports the status of each one. This guide walks through the commands you will reach for most often when managing services on a running system.

systemctl Syntax #

The general syntax of the command is:

systemctl [OPTIONS] COMMAND [UNIT...]

A UNIT is usually a service name such as nginx.service or cron.service. The .service suffix is optional when the unit type is unambiguous, so systemctl start nginx and systemctl start nginx.service do the same thing.

Most commands that change state (start, stop, enable, disable) require root privileges. Run them with sudo or as root.

Check the Status of a Service #

Before you touch a service, check what it is doing. The status command prints the current state, recent log lines, the PID of the main process, and the path of the unit file:

systemctl status nginx

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-04-13 09:12:04 CEST; 2h 3min ago
       Docs: man:nginx(8)
   Main PID: 1591 (nginx)
      Tasks: 3 (limit: 4612)
     Memory: 6.2M
        CPU: 112ms
     CGroup: /system.slice/nginx.service
             ├─1591 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             └─1592 "nginx: worker process"

The two lines to read first are Loaded and Active. Loaded tells you whether the unit file was found and whether it is set to start at boot (enabled, disabled, masked, or static). Active tells you what the service is doing right now (active (running), inactive (dead), failed, and so on).

Start and Stop Services #

To start a service that is not running:

sudo systemctl start nginx

The command returns silently when the service starts. Run systemctl status nginx afterwards to confirm.

To stop a running service:

sudo systemctl stop nginx

Stopping a service only affects the current session. If the service is enabled at boot, it will come back the next time the system starts.

Restart and Reload #

A restart fully stops the service and starts it again, which terminates all active connections. This is the command you use after a binary upgrade or any change that the service cannot pick up on its own:

sudo systemctl restart nginx

A reload asks the service to re-read its configuration without dropping active connections. Whether this works depends on the service itself. Web servers such as Nginx and Apache support it well; some services do not define a reload action.

sudo systemctl reload nginx

If the unit file supports it, reload-or-restart is a safer combination: it tries reload first and falls back to a full restart if the service does not handle reload signals.

sudo systemctl reload-or-restart nginx

Enable and Disable at Boot #

Starting a service with start does not persist across a reboot. To make a service launch automatically at boot, use enable:

sudo systemctl enable nginx

Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /lib/systemd/system/nginx.service.

The output hints at what is happening behind the scenes. Enabling a service creates a symlink in one of the *.wants directories so that the appropriate boot target pulls the unit in.

To disable a service so that it no longer starts at boot:

sudo systemctl disable nginx

enable and disable only change the boot behavior. To start or stop the service in the current session as well, add the --now flag:

sudo systemctl enable --now nginx
sudo systemctl disable --now nginx

To check whether a service is currently enabled at boot:

systemctl is-enabled nginx

Mask and Unmask #

Disabling a service prevents it from starting at boot, but another service, socket, or admin can still start it manually. mask is the stronger option. It links the unit file to /dev/null so that every attempt to start it fails, whether from the command line, from another unit, or from a boot target.

sudo systemctl mask apache2

To undo this:

sudo systemctl unmask apache2

Masking is useful when two services conflict over the same port (for example, Nginx and Apache both wanting port 80) and you want to make sure the one you are not using cannot come back.

Reload systemd After Unit File Changes #

When you add a new unit file or edit an existing one, systemd does not pick up the changes automatically. Tell it to reload its configuration with:

sudo systemctl daemon-reload

Run this command after:

• Creating a new .service file under /etc/systemd/system/
• Editing a unit file (either directly or via systemctl edit)
• Installing a package that ships a new unit file

After daemon-reload, restart the affected service if it was already running, so it starts under the new definition.

List Services #

systemctl can list every unit it knows about, which is useful when you want to see what is active, what is failing, or what is simply installed. Because the listing commands have several useful variations, they have their own dedicated guide: see listing Linux services with systemctl for filtering by state, showing inactive units, and listing unit files.

The quickest view is:

systemctl --failed

It prints every service that has failed since boot, which is usually the first thing you want to know on a box you do not fully trust yet.

View Service Logs #

systemd stores service logs in the journal, which you query with journalctl. To follow the log for a single service:

sudo journalctl -u nginx -f

The -u flag filters by unit, and -f follows new entries as they are written. For a full walkthrough of the journal, see the journalctl command guide.

Reboot, Power Off, and Suspend #

systemctl also controls system power state. These commands do not require a service name:

sudo systemctl reboot
sudo systemctl poweroff
sudo systemctl suspend
sudo systemctl hibernate

They are equivalent to the older reboot, poweroff, and halt commands, and they go through systemd so that services shut down cleanly.

Troubleshooting #

Unit nginx.service could not be found.
The service is not installed, or the unit file is in a location systemd does not scan. Install the package, or run sudo systemctl daemon-reload if you just added a unit file manually.

Failed to start nginx.service: Unit is masked.
The unit has been masked. Run sudo systemctl unmask nginx and try again.

Service keeps failing after a config change
Run systemctl status SERVICE and journalctl -u SERVICE -n 50 to read the most recent log lines. Configuration syntax errors are the most common cause.

Changes to the unit file are ignored
You forgot sudo systemctl daemon-reload. systemd caches unit files in memory and needs to be told to reread them.

Permission denied
Most state-changing commands require root. Prefix the command with sudo, or switch to the root user.

Quick Reference #

For a printable quick reference, see the systemctl cheatsheet .

FAQ #

What is the difference between enable and start?
start launches the service in the current session only. enable creates the symlinks that make systemd start the service at every boot. The two are independent, which is why --now exists to do both in one command.

What is the difference between disable and mask?
disable removes the service from boot targets, but it can still be started manually or pulled in by another unit. mask links the unit file to /dev/null so every start attempt fails.

How do I know if my system uses systemd?
Run ps -p 1 -o comm=. If the output is systemd, your init system is systemd and systemctl applies. Virtually every mainstream distribution has used systemd as the default since around 2015.

Does reload work for every service?
No. It depends on whether the unit file defines an ExecReload command and whether the service itself supports reloading. If you are unsure, use reload-or-restart, which falls back to restart when reload is not available.

What happens to running connections when I restart a service?
They are dropped. A full restart kills the process and starts a new one, so anything holding a connection will see it close. Use reload or reload-or-restart when the service supports it.

Conclusion #

Most day-to-day work with systemctl comes down to status, start, stop, restart, enable, and disable. Keep daemon-reload in mind whenever you edit a unit file, and pair systemctl with journalctl when something fails to start.

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 800+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page