Managing systemd Services
- WHAT?
systemdis used to manage system settings and services.systemdorganizes tasks into components called units and groups of units into targets.- WHY?
Learn how to manage your system services by using
systemdto start,stop, enable and disable a service, send termination signals, use thesystemctlcommand and managesystemdtargets. The article also includes troubleshooting and best practices.- EFFORT
20 minutes of reading time.
- REQUIREMENTS
Basic understanding of Linux commands
Basic understanding of Linux processes, daemons and control groups
1 What is systemd? #
systemd is a system and service manager for Linux operating systems. It is the default initialization system for major Linux distributions.
systemd is not directly initiated by the user, but installed through the /sbin/init and started during the early boot.
systemd acts as the init system that brings up and maintains user space services when run as the first process on boot (PID 1).
PID 1 is known as init and is the first Linux user-mode process created.
It runs until the system shutdown.
systemd owns PID 1, and is started directly by the kernel. All other processes are started directly
by systemd or one of its child processes. systemd mounts the host's file system and manages temporary files.
It is backward compatible with the SysV init scripts. SysV is an initialization system that predates systemd.
In systemd, a unit is a resource that the system knows how to operate on and manage. This is
the primary object that the systemd tools use. These resources are defined with configuration files called unit files.
systemctl is the central management tool for controlling the init system. It is used to
examine and control the state of the systemd system and service manager.
Targets in systemd are groups of related units that act as synchronization points during a system boot.
Target unit files have a .target file extension. Target units group together various systemd
units through a chain of dependencies.
For troubleshooting, you can use journalctl, which is
used to query and display log messages from the systemd journal.
For more information on systemd, you can refer to https://systemd.io and man 1 systemd.
2 Starting and stopping systemd services #
You can start and stop systemd services by using units which are resources.
The target units are service units, which have a .service suffix. For service management tasks, you do
not have to add the .service because systemd knows that you want to execute a service.
To start and stop systemd services, use the following commands:
To start a
systemdservice:>sudosystemctl start SERVICETo check the status of a
systemdservice:>sudosystemctl status SERVICETo stop a currently running
systemdservice:>sudosystemctl stop SERVICE
You can also use the following systemctl commands:
Stops the service and then starts it. If the service is not running, it is started.
>sudosystemctl restart SERVICEReloads the
systemdservice's configuration file without interrupting operations.>systemctl reload SERVICEReloads the service if it supports reloading, otherwise it restarts the service. If the service is not running, it is started.
>sudosystemctl reload-or-restart SERVICE
3 Enabling and disabling systemd services #
You can enable and disable systemd services by using units which are resources.
To enable and disable systemd services, follow:
To enable a service at boot:
>sudosystemctl enable SERVICEA symbolic link is created usually in
/lib/systemd/systemoretc/systemd/systempointing into the location on disk wheresystemdlooks for autostart files. This is either in/lib/systemd/systemor/etc/systemd/system, which is usually/etc/systemd/system/EXAMPLE_TARGET.target.For example:
>sudosystemctl enable firewalld.service Created symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service \u2192 /usr/lib/systemd/system/firewalld.service. Created symlink /etc/systemd/system/multi-user.target.wants/firewalld.service \u2192 /usr/lib/systemd/system/firewalld.service.To disable a service from starting automatically:
>sudosystemctl disable SERVICEThis removes the symbolic link that indicates that the service should be started automatically.
For example:
>sudosystemctl disable firewalld.service Removed /etc/systemd/system/multi-user.target.wants/firewalld.service. Removed /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.To check the status of a service:
>sudosystemctl status SERVICEFor example:
>sudosystemctl status firewalld.service \u25cf firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor p> Active: active (running) since Wed 2024-01-31 01:36:36 EST; 1h 5min ago Docs: man:firewalld(1) Main PID: 965 (firewalld) Tasks: 2 CGroup: /system.slice/firewalld.service \u2514\u2500965 /usr/bin/python3 -Es /usr/sbin/firewalld --nofork --nopid
Enabling or disabling a service does not start it in the current session. You can use
start or stop to start or stop the service and enable or disable it at boot.
4 Sending termination signals to systemd services #
Each service in systemd is categorized into a control group which makes it easy to identify
all parent and child processes of a service. This enables you to send a signal to each of these processes.
You can send a signal to a systemd service or to the individual processes that belong to a service.
The D-Bus service is the message bus for communication between systemd clients and the systemd manager that is running as PID 1.
D-Bus is a stand-alone daemon and an integral part of the init infrastructure.
Terminating or restarting the D-Bus service is neither recommended nor supported. This breaks the systemd client
and server communication and makes most of the systemd functions unusable.
The systemd-cgls command displays all processes that belong to a systemd service.
It recursively shows the contents of the specific Linux control group hierarchy in a tree.
Lists all control groups and their processes:
>systemd-cglsDisplays all processes that belong to a particular service, for example: the
libvirtd.serviceservice:>systemd-cgls -u libvirtd.serviceSends a termination signal to the service:
>sudosystemctl kill SERVICEBy default, the
killcommand sends the signal toallprocesses of the specified control group. You can restrict it to thecontrolor themainprocess. The latter is, for example, useful to force a service to reload its configuration by sendingSIGHUP:>sudosystemctl kill -s SIGHUP --kill-who=main SERVICESends a different signal to a service with the
-soption, such asSIGKILL(9):>sudosystemctl kill -s 9 SERVICE
5 Managing systemd targets with the systemctl command #
systemd targets are special unit files that describe a system or synchronization state.
They are used to group units together in order or bring the system to a certain state, just like other init systems use runlevels.
You can use the systemctl command to manage systemd targets.
- Getting and setting the default target
systemdhas a default target that is used when booting the system. To find the default target for your system:>sudosystemctl get-default multi-user.targetYou can also change the default target:
>sudosystemctl set-default graphical.target- Listing the available targets
To get the available targets on your system:
>sudosystemctl list-unit-files --type=target STATE VENDOR PRESET basic.target static - blockdev@.target static - bluetooth.target static - boot-complete.target static - cryptsetup-pre.target static - cryptsetup.target static - ctrl-alt-del.target alias - cvs.target static - default.target alias - emergency.target static - exit.target disabled disabled final.target static - first-boot-complete.target static - getty-pre.target static - getty.target static - .....Multiple targets can be active at the same time. An active target is when
systemdattempts to start all the units in a specific target. To see a list of the active targets:>sudosystemctl list-units --type=target UNIT LOAD ACTIE SUB DESCRIPTION > basic.target loaded active active Basic System bluetooth.target loaded active active Bluetooth Support cryptsetup.target loaded active active Local Encrypted Volumes getty.target loaded active active Login Prompts graphical.target loaded active active Graphical Interface local-fs-pre.target loaded active active Preparation for Local File Syste> local-fs.target loaded active active Local File Systems multi-user.target loaded active active Multi-User System network-online.target loaded active active Network is Online network-pre.target loaded active active Preparation for Network network.target loaded active active Network nss-lookup.target loaded active active Host and Network Name Lookups nss-user-lookup.target loaded active active User and Group Name Lookups paths.target loaded active active Path Units remote-fs.target loaded active active Remote File Systems slices.target loaded active active Slice Units snapd.mounts-pre.target loaded active active Mounting snaps .....- Isolating targets
You can start all the units associated with a target and stop all units that are not part of the dependency tree. For example, if you are using a graphical environment with an active
graphical.targettarget, you can stop the graphical system and enable a multiuser command-line system by isolating themulti-user.targettarget. Since thegraphical.targettarget depends on themulti-user.targettarget, all the graphical units are stopped.To take a look at the dependencies of the target you are isolating:
>sudosystemctl list-dependencies multi-user.targetOutput:
multi-user.target ○ ├─after-local.service ● ├─apparmor.service ○ ├─appstream-sync-cache.service ● ├─auditd.service ● ├─avahi-daemon.service ● ├─btrfsmaintenance-refresh.path ● ├─chronyd.service ● ├─cron.service ● ├─cups.path ● ├─dbus.service ● ├─fail2ban.service ● ├─firewalld.service ● ├─irqbalance.service ● ├─kbdsettings.service ● ├─libvirtd.service ● ├─mcelog.service ● ├─ModemManager.service ● ├─NetworkManager.service ● ├─nscd.service ● ├─plymouth-quit-wait.service ○ ├─plymouth-quit.service ● ├─postfix.service
You can isolate the specific target:
>sudosudo systemctl isolate multi-user.target
6 Troubleshooting systemd management #
If you are experiencing problems with systemd, try the following troubleshooting tips to identify and resolve issues:
- Check the runtime status of a service
To find out the current runtime status of a service:
>sudosystemctl status SERVICE- Display all processes that belong to a particular service, for example:
the
libvirtd.serviceservice: >systemd-cgls -u libvirtd.service- Check the logs for your service with the
journalctl -u SERVICEcommand If you experience any issue with a
systemdservice, check the service's log. For example:>sudojournalctl -u my-custom-service.serviceThe command displays logs for the specified service, including any error messages, warnings or other relevant information. You can use these logs to identify and fix issues with the service.
7 Best practices for systemd management #
To manage systemd services, try certain best practices that are equipped to handle different situations:
- Check the runtime status of a service
To find out the current runtime status of a service:
>sudosystemctl status SERVICE- Use absolute path in your
systemdunit file Use an absolute path for executable files and required files, such as configuration files or scripts in your
systemdunit file.systemddoes not rely on the user's environment variables like$PATHto locate files. Use the ExecSearchPath directive in the[SERVICE]section.[Service] ExecSearchPath=ABSOLUTE_PATH- Use the ExecReload directive
Use the ExecReload directive in the
[SERVICE]section when you want to define a specific command that should be executed when you reload a service with thesystemctl reloadcommand. This is useful for services that can dynamically reload their configuration without a restart.[Service] ExecStart=PATH_TO_EXECUTABLE ExecReload=PATH_TO_RELOAD_SCRIPT- Use the RestartSec directive
Use the RestartSec directive in the
[SERVICE]section when you want to define a delay (in seconds) before the service is restarted after a failure. This is useful for services that require a specified time to release resources or prevent rapid restart loops that can cause high system load.[Service] ExecStart=PATH_TO_EXECUTABLE Restart=on-failure RestartSec=5
- Disable emergency mode on a remote machine
You can disable emergency mode on a remote machine, for example, a virtual machine hosted on Google Cloud. If this mode is enabled, the machine is blocked from connecting to the network. For example:
>sudosystemctl mask emergency.service>sudosystemctl mask emergency.target
8 systemctl commands overview #
The systemctl command is used to examine and control
the state of systemd and service manager.
You can use the following common systemctl commands and
refer to the man systemctl page.
8.1 Viewing systemd information #
To view information about systemd components, you can use the following
commands:
- systemctl list-units
Lists the
systemdunits. You can use the optional arguments:--state=runningto show the active units and--type=serviceto show the exited and active units.- systemctl list-unit-files
Lists the
systemdunits and the status, such as static, generated, disabled, alias, masked, and enabled.- systemctl list-dependencies
Lists the dependency tree.
- systemctl list-dependencies UNIT_FILE
Lists the dependencies of a unit file.
8.2 Managing systemd services #
The systemctl command enables you to perform the
following tasks with services.
- systemctl status SERVICE
Checks the status of the specific service.
- systemctl show SERVICE
Displays the service information.
- systemctl start SERVICE
Instead of manually starting the service, use the
startcommand. When a change is made to the configuration file, the related service must be started again.- systemctl stop SERVICE
Stops a specific running service.
- systemctl restart SERVICE
Instead of manually restarting the service, use the
restartcommand. When a change is made to the configuration file, the related service must be restarted again.- systemctl enable SERVICE
Enables the service on boot.
- systemctl disable SERVICE
Disables the service on boot.
- systemctl reload-or-restart SERVICE
Reload the service if it supports reloading, otherwise it restarts the service. If the service is not running, it is restarted.
- systemctl mask SERVICE
When a service is masked, this means the unit file is symlinked to
/dev/null. A symlink for a masked service is created from/etc/systemd/systemto point to/dev/null. This makes it impossible to load the service even if another enabled service requires it. It must be stopped manually, or it continues to run in the background. You can use--runtimeoption to only mask temporarily until the next reboot of the system.Created symlink /etc/systemd/system/FOSSLinux.service → /dev/null.
- systemctl unmask SERVICE
Unmasks the service. It is effective when the system is started or restarted manually.
8.3 Managing system states #
The systemctl command enables you to perform power
management processes on your system, like restarting, shutting down and
so on, as described below.
- systemctl reboot
Reboots the system
reboot.target.- systemctl poweroff
Powers off the system
poweroff.target.- systemctl emergency
Goes into the emergency mode
emergency.target.- systemctl default
Goes back to default target
multi-user.target.
9 More information #
10 Legal Notice #
Copyright© 2006–2025 SUSE LLC and contributors. All rights reserved.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.
For SUSE trademarks, see https://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.
All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.