Mastering systemctl: systemd's management command

1. View the status of a service

systemctl status nginx

This shows whether the service is active (`active (running)`), inactive (`inactive`), failed, or `masked`. Below that you see the latest log lines of the service — a quick first impression without having to open `journalctl`.

2. Start a service directly

sudo systemctl start nginx

This starts the service now, but not at the next system boot. For a web server that needs to run after a reboot, you need step 3.

3. Enable a service at startup

sudo systemctl enable nginx

This creates a symbolic link from the unit file to the `multi-user.target` — the system will now automatically start the service.

4. Start and enable in one go

sudo systemctl enable --now nginx

The `--now` option combines steps 2 and 3. For a new service, this is almost always what you want: running now and after a reboot.

5. Stop a service

sudo systemctl stop nginx

This stops the service immediately. Use `disable` to also turn off automatic startup at boot.

6. Restart a service

sudo systemctl restart nginx

This stops and starts the service again. Useful after a configuration change, but it breaks active connections. For nginx and other services that can reload configuration without stopping, `reload` is the better choice:

sudo systemctl reload nginx

`reload` sends the signal that the service itself has defined to re-read configuration — without downtime.

Mask: making a service impossible

Sometimes a service must not only be stopped, but also must not be able to start — not by you, not by another service that depends on it.

sudo systemctl mask nginx

This links the unit file to `/dev/null`. Any attempt to start the service fails, even indirectly via dependencies. Use `unmask` to undo this:

sudo systemctl unmask nginx

This is stricter than `disable`: a disabled service can still be started by another service that needs it. A masked service cannot.

Managing user services

Not everything needs to be done as root. With the `--user` flag, you manage services that run under your own user account:

systemctl --user status my-service
systemctl --user enable --now my-service

This works for background processes such as a personal backup timer or a development server. The services are located in `~/.config/systemd/user/`. You do not need sudo for this.

Targets: the modern runlevel

A target in systemd replaces the runlevel of the old SysV init. Where you previously ran `telinit 3` to go to multi-user mode, you now use:

sudo systemctl isolate multi-user.target

This disables all services that are not in this target. `multi-user.target` is the text mode without a GUI; `graphical.target` is the equivalent with a desktop environment. The old commands such as `telinit` still work, but internally they simply send systemd commands.

The structure of systemctl

The basic form is predictable:

systemctl [options] [command] [unit]

The most commonly used options:

• `--now`: start or stop immediately with enable or disable
• `--no-block`: do not wait for the action to complete
• `--force`: force the action, even if the service does not respond

Verification

Check that everything works:

systemctl status nginx
systemctl is-enabled nginx
systemctl is-active nginx

`is-enabled` shows whether the service starts at boot; `is-active` shows whether it is running now. Both should show `enabled` and `active`.

Common problems

1. Service does not start after a configuration change

sudo systemctl daemon-reload

systemd caches unit files. After editing a unit file in `/etc/systemd/system/`, you must reload the daemon, otherwise it will use the old configuration.

2. Service keeps failing — no clear error message

sudo journalctl -u nginx -n 50

`systemctl status` only shows the last few log lines. `journalctl` gives the full output of the service, often with the actual error that would otherwise remain hidden.

3. A service is masked and you do not know why

systemctl list-unit-files | grep masked

This shows all masked units. A `masked` service cannot be started, even by dependencies. This is sometimes necessary, but can be confusing when a dependent service does not start.

What systemctl costs you

Systemd is not the most minimalist init system out there. Criticism of its complexity is justified: where SysV init ran on simple shell scripts, systemd works with its own configuration format, its own logging daemon, and its own service manager. Anyone who just wanted to type `service nginx start` now has to know the difference between `start`, `enable`, and `mask`.

That complexity buys you something: parallel startup, better dependency tracking, and one uniform interface for services, timers, mounts, and power management. The old commands `service` and `chkconfig` still work on most distributions, but internally they just drive systemd.

And if you don't want systemd, you have a problem: alternatives like OpenRC or runit exist, but the major distributions have switched. Even if you run an alternative init system, you often have to configure software that accounts for systemd components. The choice has effectively been made.

`systemctl` is therefore no longer an option, but the standard — and anyone managing Linux cannot avoid it.