Linux command: systemctl

You install a web server, edit its configuration, and want it running now and again after every reboot. You need to stop a service to update it, check why one crashed, or find out what starts automatically at boot. On almost every modern Linux system, the single command behind all of this is systemctl. It is the control panel for systemd, the program that starts your services, mounts your disks, and brings the whole system up in the right order. Learn systemctl and you learn how a Linux machine really runs.

2. Where the Name Comes From

The name is two parts joined together: system plus ctl.

systemctl  =  SYSTEM + con-TROL

The system part points at systemd, whose own name means "system daemon" (the trailing d is the classic Unix convention for a background daemon, as in sshd or httpd). So systemctl is the tool that controls the system daemon.

The ctl ending is short for control, and it is a house style across the whole systemd family. Once you spot the pattern, a long list of tool names suddenly makes sense:

So systemctl reads as "the control program for the system manager". It is the central member of the family: the others manage one slice of the system, while systemctl manages the units that make up the whole thing.

4. Simple Use Cases

Four verbs cover almost all day-to-day service work: start, stop, restart, and reload. Each takes one or more unit names. The .service suffix is optional; if you leave off the type, systemd assumes .service.

4.1 Start and Stop a Service

start activates a unit now; stop deactivates it now. Neither affects what happens at the next boot.

$ sudo systemctl start nginx      # bring nginx up now
$ sudo systemctl stop nginx       # shut nginx down now

These commands are quiet on success: no news is good news. Run systemctl status nginx afterwards, or check the exit code, to confirm the change.

4.2 Restart After a Change: restart

When you change a program's configuration file, restart stops the service and starts it again so the new settings take effect:

$ sudo systemctl restart nginx    # full stop, then start

A restart briefly drops the service. For something like a web server that means a short moment where it does not answer, which is where the next command helps.

4.3 Reload Without Dropping the Service: reload

reload asks the running service to re-read its configuration without stopping. It keeps existing connections alive, so a web server or database does not go down:

$ sudo systemctl reload nginx     # re-read config, stay up

The catch: a service can only reload if its author wrote support for it. If it cannot, you get an error. When you are unsure which one you need, reload-or-restart reloads when possible and otherwise restarts:

$ sudo systemctl reload-or-restart nginx

6. Advanced Use Cases

6.1 Editing a Unit the Right Way: systemctl edit

Never edit a vendor's unit file under /lib/systemd/system directly; a package update will overwrite it. Instead, use systemctl edit, which creates a small drop-in override file that only changes the settings you name and leaves the original alone:

$ sudo systemctl edit nginx        # opens an override drop-in in an editor

This writes to /etc/systemd/system/nginx.service.d/override.conf. Your lines there win over the vendor's. To replace the whole file instead of layering on top, use systemctl edit --full. After editing, systemd needs to re-read its configuration, which is the next command.

6.2 Reloading systemd Itself: daemon-reload

There are two very different kinds of "reload", and mixing them up is a classic trap:

• systemctl reload nginx tells the nginx service to re-read its own config.
• systemctl daemon-reload tells systemd itself to re-read all unit files.

Whenever you add, edit, or remove a unit file, run daemon-reload so systemd notices the change, then restart the affected service:

$ sudo systemctl daemon-reload     # systemd re-reads unit files
$ sudo systemctl restart nginx     # apply the new unit definition

If you edit a unit and your changes seem ignored, a missing daemon-reload is the usual reason.

6.3 Writing Your Own Service Unit

Sooner or later you want to run your own program as a managed service, so it starts at boot, restarts on failure, and logs to the journal like any other unit. You do this by writing a small unit file under /etc/systemd/system/. A service unit has three sections:

$ sudo nano /etc/systemd/system/myapp.service

[Unit]
Description=My Application
After=network.target

[Service]
ExecStart=/opt/myapp/app.sh
Restart=on-failure
User=myapp

[Install]
WantedBy=multi-user.target

Each section has a clear job:

After creating the file, tell systemd about it and turn it on:

$ sudo systemctl daemon-reload      # systemd notices the new file
$ sudo systemctl enable --now myapp  # start it now and at every boot

The Restart=on-failure line is one of the reasons to prefer a real unit over a hand-run script: systemd will bring your program back up if it crashes.

6.4 Controlling Order and Requirements

The [Unit] section is where you say how a unit relates to others, and two different ideas are easy to confuse: ordering (when) and requirement (whether):

The trap is that ordering and requirement are separate. Requires= says the other unit must be there, but it does not say to wait for it; you almost always pair it with After= to also get the order right:

[Unit]
Requires=postgresql.service
After=postgresql.service

Wants= is the gentler and more common choice: it is what enable writes for you behind the scenes, and it keeps one failing dependency from dragging your service down with it.

6.5 Understanding Dependencies: list-dependencies

Once units depend on each other, you often need to see the whole tree. list-dependencies shows what a unit pulls in, and with --reverse, what depends on it:

$ systemctl list-dependencies nginx    # what nginx pulls in
$ systemctl list-dependencies --reverse nginx   # what depends on nginx

This is how you answer "why does this service start?" and "what breaks if I stop that one?".

6.6 Hardening a Service: Sandboxing

One of systemd's most underused powers is that the [Service] section can lock a service into a sandbox, shrinking what a compromised program can reach. You add these as plain directives, no container needed:

You can measure how well a service is locked down with a built-in scanner that scores each unit and suggests what to add:

$ systemd-analyze security nginx    # exposure score and per-setting advice

For a service exposed to the internet, a few of these lines can turn a full-system compromise into a contained one. Add them through systemctl edit so they survive updates.

6.7 Seeing the Real Unit File: cat and show

systemctl cat prints the exact unit file systemd loaded, including any drop-ins layered on top, so you see the effective definition:

$ systemctl cat nginx              # the unit file plus any overrides

systemctl show goes further and dumps every resolved property as KEY=VALUE, which is how you check what a setting actually became:

$ systemctl show nginx -p MemoryCurrent -p ExecStart

6.8 Masking: The Strongest "Off" Switch

disable stops a service starting at boot, but something else can still pull it in as a dependency, or you can still start it by hand. mask is the absolute block: it makes the unit impossible to start at all, by anyone, until you unmask it:

$ sudo systemctl mask nginx        # nginx cannot be started at all now
$ sudo systemctl unmask nginx      # allow it again

Use masking when you truly want a service dead, for example replacing a distribution's default web server with your own. Under the hood, masking links the unit to /dev/null, which section 7 explains.

6.9 Targets: Grouping Units into System States

A target is a special unit that groups other units, used to describe a whole system state. Targets are systemd's replacement for the old runlevels:

You can see the boot default, change it, or switch the running system into another target:

$ systemctl get-default                       # e.g. graphical.target
$ sudo systemctl set-default multi-user.target  # boot without a desktop next time
$ sudo systemctl isolate rescue.target          # switch to rescue mode now

6.10 Reboot, Power Off, and Suspend

Because systemd manages the whole system state, it also owns shutdown and sleep. These verbs replace the older separate commands:

$ systemctl reboot         # restart the machine
$ systemctl poweroff       # shut down and power off
$ systemctl suspend        # sleep to RAM
$ systemctl hibernate      # sleep to disk

8. Best Practices

• Decide "now" and "at boot" on purpose. For a service you want permanently, use enable --now. For a one-off, use plain start. Being clear about which you mean prevents surprises after a reboot.
• Prefer reload over restart when it exists. A reload keeps connections alive; a restart drops them for a moment. Fall back to reload-or-restart when unsure.
• Never edit vendor unit files directly. Use systemctl edit to add a drop-in override, so a package update cannot wipe your changes.
• Run daemon-reload after any unit-file change. Otherwise systemd keeps using the old definition and your edits appear to do nothing.
• Give your own program a real unit. A short [Unit]/[Service]/[Install] file with Restart=on-failure beats a hand-run script: it starts at boot, restarts on crash, and logs to the journal.
• Sandbox internet-facing services. Add a few lines such as ProtectSystem=strict, PrivateTmp=true, and NoNewPrivileges=true, and check the result with systemd-analyze security.
• Check systemctl --failed regularly. On a server it is the fastest way to spot a service that quietly died.
• Use systemctl cat to see the truth. It shows the real, effective unit including overrides, which avoids guessing about which file is in force.
• Read the manual when unsure. The behaviour is fully documented; man systemctl and man systemd.unit are the reference.

$ man systemctl         # the command and all its verbs
$ man systemd.service    # how to write a service unit
$ systemctl --help       # a quick summary of the commands

10. Summary

The systemctl command is the control panel for systemd, and systemd runs everything on a modern Linux machine. Learn a handful of verbs and one key distinction, and managing services becomes calm and predictable instead of guesswork.

• systemctl queries and controls systemd, the manager that starts every service, mount, and timer as a unit.
• The name means "system control", part of the systemd family alongside journalctl and timedatectl.
• It replaced SysV init scripts with declarative unit files and parallel startup, arriving with systemd in 2010.
• Manage a running service with start, stop, restart, and reload; check it with status.
• The crucial distinction: start/stop act now, enable/disable act at boot, and --now does both.
• Ask yes-or-no with is-active, is-enabled, and is-failed; list state with list-units, list-unit-files, and --failed.
• Write your own service as a small [Unit]/[Service]/[Install] file, order it with After=/Before=, and require others with Wants=/Requires=.
• Harden a service in its [Service] section with sandboxing (ProtectSystem=, PrivateTmp=, NoNewPrivileges=), scored by systemd-analyze security.
• Edit units safely with systemctl edit (a drop-in), then run daemon-reload so systemd notices.
• Block a service completely with mask; group units and system states with targets like multi-user.target.
• Under the hood, enabling is a symlink in a target's .wants directory, masking is a symlink to /dev/null, and systemctl reaches systemd over D-Bus.
• A unit in /etc/systemd/system always overrides the vendor copy in /usr/lib/systemd/system, which is what makes drop-ins survive updates.
• You have a second, personal systemd reached with --user, and every manageable thing (service, timer, mount, target) is a unit.

This is the quick reference worth keeping:

systemctl status nginx           is it running, enabled, and healthy
systemctl start nginx            run it now
systemctl stop nginx             shut it down now
systemctl restart nginx          full stop then start
systemctl reload nginx           re-read config, stay up
systemctl enable nginx           start at boot (not now)
systemctl enable --now nginx     start at boot AND now
systemctl disable --now nginx    stop now AND at boot
systemctl is-active nginx        one-word running check
systemctl is-enabled nginx       one-word boot check
systemctl --failed               list everything that failed
systemctl list-units --type=service   loaded services
systemctl list-unit-files        every installed unit and its state
systemctl edit nginx             safe drop-in override
systemctl daemon-reload          reload unit files after editing
systemctl cat nginx              show the effective unit file
systemctl mask nginx             block a service completely
systemctl list-dependencies nginx     what it needs
systemd-analyze security nginx   score a service's sandboxing
systemctl --user status          your own user services
systemctl reboot                 restart the machine

Managing services well is one of the quiet skills that separates a calm server administrator from a stressed one: the difference between a site that comes back cleanly after every reboot and one that silently forgets to start a service at the worst possible moment. If your servers have services that do not survive a restart, changes that never seem to take effect, or a boot that no one fully understands, it pays to have systemd set up correctly before the next incident, so the machine behaves exactly as you expect.