Table of Contents
Understanding `systemctl` for Service Management
systemctl is the main command line tool used to interact with systemd. In this chapter you focus on using systemctl specifically to manage services that systemd controls, such as web servers, database servers, and background daemons.
Whenever you work with systemctl, you are usually dealing with service unit files that describe how a program should be started, stopped, and supervised. You will see full details of unit files in a separate chapter, so here you concentrate on the practical day to day service operations.
Always remember: systemctl affects the running system at a low level. Many actions require sudo, and a mistaken restart or stop command on a critical service can disconnect users or break running applications.
Checking Service Status
The most common action is to check whether a service is active. You do this with:
systemctl status ssh
This shows whether the service is active, inactive, failed, or in another state. It also prints a short log excerpt, the main process ID, and information such as when the service was started.
If you know the full unit name you can use it directly:
systemctl status ssh.service
Both calls are usually equivalent, because systemctl can infer .service by default when you omit the suffix.
A quick overview of the state of all services is useful for troubleshooting:
systemctl list-units --type=service
This only shows loaded and active service units. If you want to also see inactive ones, add --all:
systemctl list-units --type=service --allThis helps you verify which services are running and whether anything has failed after boot or configuration changes.
A service in state failed indicates that systemd tried to start it and the process exited with an error. Do not just restart it repeatedly. First inspect systemctl status output and related logs to find the underlying cause.
Starting and Stopping Services
To manually control services on a running system, you use start and stop.
To start a service immediately:
sudo systemctl start nginx
This launches the service and returns as soon as systemd has initiated the start operation. It does not automatically enable the service at boot, it only affects the current session.
To stop a running service:
sudo systemctl stop nginx
Stopping a service terminates its processes under systemd supervision. If clients are connected, for example to a web server or database, those connections will be interrupted.
There is also restart which combines stopping and starting:
sudo systemctl restart nginx
restart is useful when you change configuration files and want the service to reload them by restarting from scratch.
Finally, there is reload, intended for services that support reloading configuration without a full restart:
sudo systemctl reload nginx
If a service does not implement a reload operation, systemctl reload may fail. In that case, consult the service documentation and use restart if needed.
Enabling and Disabling Services at Boot
Service startup at boot is controlled separately from starting and stopping services in the current session. This is where enable and disable come in.
To ensure a service starts automatically whenever the system enters its normal multi user or graphical mode, use:
sudo systemctl enable nginx
This typically creates one or more symbolic links from the service unit file to appropriate .wants directories used by systemd boot targets. You do not need to manage those links manually.
To prevent a service from automatically starting at boot, use:
sudo systemctl disable nginxDisabling a service does not stop it if it is already running. It only affects future boots and target transitions.
You can verify whether a service is enabled with:
systemctl is-enabled nginx
Possible results include enabled, disabled, static, and others. A static service cannot be enabled directly, because it lacks its own Install section and is meant to be started by other units or dependencies.
Do not rely on enable or disable to control the immediate running state of a service. enable does not start the service right now, and disable does not stop it. Use start and stop for the current session, and enable and disable for boot time behavior.
Combining Start and Enable Actions
Many distributions provide a convenient pattern for initial service setup: enable a service for future boots and start it in the current session in one step.
You can do this explicitly:
sudo systemctl enable --now nginx
The --now option tells systemctl to both enable the service and start it immediately. Similarly, you can disable and stop a service in a single command:
sudo systemctl disable --now nginxThis is particularly handy when you are deploying new services or cleaning up unneeded ones.
Checking Simple Service States
For quick scripts or checks where you do not need the full verbose status output, systemctl provides shorter queries.
To check if a service is currently active:
systemctl is-active ssh
This prints active, inactive, failed, or related states, which is convenient to parse from shell scripts.
To quickly check if a service is enabled at boot:
systemctl is-enabled sshIf you want to see all installed service units and their enablement state, you can use:
systemctl list-unit-files --type=serviceThis lists unit files rather than currently loaded units, and shows whether each one is enabled, disabled, static, or masked.
Masking and Unmasking Services
Sometimes disabling a service is not enough. A disabled service can still be started manually or by another unit that depends on it. If you want to prevent any start of a service, including manual attempts, you can mask it.
To mask a service:
sudo systemctl mask bluetooth
Masking replaces the unit file with a symbolic link to /dev/null, which makes it impossible for systemd to start it.
If someone later tries to start this service, the command fails with a clear error that the unit is masked:
sudo systemctl start bluetoothTo allow the service to be started again, you must unmask it:
sudo systemctl unmask bluetoothUnmasking restores the link to the original unit file. After unmasking, you may still need to enable or start the service depending on your needs.
Use masking for services that you explicitly want to forbid, for example if they conflict with security policies or with other software. Do not mask services casually, because it overrides dependency based startup and can cause unexpected failures for other units.
Managing Services by Patterns and Groups
systemctl can operate on more than one unit at once. When you want to start, stop, enable, or disable several related services, you can give multiple units in a single command:
sudo systemctl restart nginx php-fpmYou can also manage many units using shell globbing, for example:
sudo systemctl restart "nginx*" "php*"
Be careful when using globs, and always quote them to let the shell expand them, not systemctl itself. Listing units first with systemctl list-units or list-unit-files helps confirm the scope of your actions.
Reloading systemd After Changes
When you modify or add service unit files, systemd needs to be told to rescan them. This does not restart services by itself, it only updates systemd internal view of the available units.
To reload unit files:
sudo systemctl daemon-reload
You use this after placing a new service file under /etc/systemd/system or after editing an existing custom unit. Once reloaded, you can use systemctl start, enable, or other subcommands with the updated unit.
After daemon-reload, running services keep their current state. If you changed important execution settings, for example binary paths or environment, you usually must follow with systemctl restart your-service to apply those changes.
Using `systemctl` with User Services
Most examples so far refer to system wide services, which run under PID 1 and affect the whole machine. systemd also supports user level instances that can manage services in the context of a single user, without system wide privileges.
To manage user services, you add the --user flag and generally omit sudo:
systemctl --user statusThis lists user services for your current user. To start or stop a user service:
systemctl --user start my-app.service
systemctl --user stop my-app.service
User services typically have unit files under ~/.config/systemd/user/ or in system wide directories designed for user instances. Boot behavior for user services depends on user logins or lingering settings, which is outside the scope of this chapter, but operational commands behave similarly to system services.
Practical Troubleshooting Patterns
When a service behaves unexpectedly, systemctl is central to the first troubleshooting steps.
You might follow a pattern like this:
- Check whether the service is active:
systemctl is-active httpd- If not active, inspect detailed status:
systemctl status httpdFocus on the last log lines and the exit code.
- If you recently changed configuration files, test and then restart:
sudo systemctl restart httpd- If the service fails again, confirm whether it is enabled or accidentally disabled:
systemctl is-enabled httpd- Make temporary changes by starting or stopping the service, and permanent changes by enabling or disabling it at boot.
For more complex failures, you will use specialized logging tools that integrate with systemd logging, but systemctl status already gives you a fast snapshot.
When working on remote servers, always be careful with commands such as stop or restart for network related services like sshd or network. An incorrect change followed by a restart can disconnect your only access path, leaving the system unreachable.
Summary
In this chapter you used systemctl as your main interface to systemd services. You learned to check service status, start and stop services in the current session, manage boot startup with enable and disable, combine actions with --now, and fully block services by masking them. You also saw how to reload unit definitions, work with user services, and apply simple troubleshooting routines.
These service management commands are part of daily Linux administration work and form a practical foundation before you dive into targets, logging with journalctl, and creating custom systemd units in later chapters.