Manage services
In modern Linux® systems, services are controlled centrally via systemd. This chapter shows how to start, stop, restart and configure services for automatic system startup, as well as where systemd manages the associated unit files.
Starting a systemd unit
A service can be started manually. The associated process is executed directly and monitored by systemd. The start is independent of whether the service is configured for automatic system start.
sudo systemctl start <service-name>Stop a unit with systemd
When a unit is stopped, systemd terminates the associated process in a controlled manner. The service is then no longer available, but remains registered in the system and can be restarted.
sudo systemctl stop <service-name>Restarting a unit
A restart combines stopping and restarting a service. This is typically used to make configuration changes take effect. The restart is usually very fast and is fully coordinated by systemd.
sudo systemctl restart <service-name>Activate and deactivate systemd units
Activating a unit specifies that the service is started automatically at system startup.
sudo systemctl enable <service-name>Deactivating prevents the automatic start without removing the service.
sudo systemctl disable <service-name>Activation takes place by creating internal links, not by copying or changing the actual unit file.
Storage locations of systemd unit files
Systemd manages unit files in several directories with different meanings:
- /lib/systemd/system/
Contains unit files that are provided by installed software packages. - /run/systemd/system/
Contains temporary units created at runtime. - /etc/systemd/system/
Contains user-defined units and customizations of existing services.
Priority of the systemd unit directories
Systemd evaluates the unit directories according to a fixed priority:
- /etc/systemd/system/ (highest priority)
- /run/systemd/system/
- /lib/systemd/system/ (lowest priority)
Entries in a directory with higher priority override units with the same name from lower directories. For this reason, custom services and adaptations are always stored under /etc/systemd/system/. As a result, they remain stable against package updates and are clearly separated from the distribution standard.