Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / Managing systemd Services

Managing systemd Services

Publication Date: 27 Sep 2024
WHAT?

systemd is used to manage system settings and services. systemd organizes tasks into components called units and groups of units into targets.

WHY?

Learn how to manage your system services by using systemd to start,stop, enable and disable a service, send termination signals, use the systemctl command and manage systemd targets. 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 systemd service: 

    > sudo  systemctl start SERVICE

  • To check the status of a systemd service: 

    > sudo  systemctl status  SERVICE

  • To stop a currently running systemd service: 

    > sudo  systemctl 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.

    > sudo  systemctl restart SERVICE

  • Reloads the systemd service's configuration file without interrupting operations.

    >  systemctl reload SERVICE

  • Reloads the service if it supports reloading, otherwise it restarts the service. If the service is not running, it is started.

    > sudo  systemctl 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:

  1. To enable a service at boot: 

    > sudo  systemctl enable SERVICE

    A symbolic link is created usually in /lib/systemd/system or etc/systemd/system pointing into the location on disk where systemdlooks for autostart files. This is either in /lib/systemd/system or /etc/systemd/system, which is usually /etc/systemd/system/EXAMPLE_TARGET.target.

    For example:

    > sudo  systemctl 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.

  2. To disable a service from starting automatically: 

    > sudo  systemctl disable SERVICE

    This removes the symbolic link that indicates that the service should be started automatically.

    For example:

    > sudo  systemctl disable firewalld.service
      Removed /etc/systemd/system/multi-user.target.wants/firewalld.service.
      Removed /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.

  3. To check the status of a service: 

    > sudo  systemctl status SERVICE

    For example:

    > sudo  systemctl 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.

Warning
Warning: Do not cancel the D-Bus service in a running system

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-cgls

  • Displays all processes that belong to a particular service, for example: the libvirtd.service service:

    > systemd-cgls -u libvirtd.service

  • Sends a termination signal to the service:

    > sudo systemctl kill SERVICE

  • By default, the kill command sends the signal to all processes of the specified control group. You can restrict it to the control or the main process. The latter is, for example, useful to force a service to reload its configuration by sending SIGHUP:

    > sudo systemctl kill -s SIGHUP --kill-who=main SERVICE

  • Sends a different signal to a service with the -s option, such as SIGKILL (9):

    > sudo systemctl 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

systemd has a default target that is used when booting the system. To find the default target for your system: 

> sudo systemctl get-default
  multi-user.target

You can also change the default target:

> sudo systemctl set-default graphical.target
Listing the available targets

To get the available targets on your system: 

> sudo systemctl 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 systemd attempts to start all the units in a specific target. To see a list of the active targets:

> sudo systemctl 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.target target, you can stop the graphical system and enable a multiuser command-line system by isolating the multi-user.target target. Since the graphical.target target depends on the multi-user.target target, all the graphical units are stopped.

To take a look at the dependencies of the target you are isolating:

> sudo systemctl list-dependencies multi-user.target

Output:

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:

> sudo sudo 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:

> sudo systemctl status SERVICE
Display all processes that belong to a particular service, for example: the libvirtd.service service:
> systemd-cgls -u libvirtd.service
Check the logs for your service with the journalctl -u SERVICE command

If you experience any issue with a systemd service, check the service's log. For example: 

> sudo  journalctl -u my-custom-service.service

The 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:

> sudo systemctl status SERVICE
Use absolute path in your systemd unit file

Use an absolute path for executable files and required files, such as configuration files or scripts in your systemd unit file. systemd does not rely on the user's environment variables like $PATH to 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 the systemctl reload command. 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: 

> sudo systemctl mask emergency.service
> sudo systemctl 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 systemd units. You can use the optional arguments: --state=running to show the active units and --type=service to show the exited and active units.

systemctl list-unit-files

Lists the systemd units 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 start command. 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 restart command. 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/system to 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 --runtime option 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

 

  • Man 1 systemd

  • Man 1 journalctl

  • Man 1 systemd-cgls

  • Man 1 systemctl

  • Man 5 systemd.service

  • Man 5 systemd.kill

  • Man 7 systemd.boot

  • Introduction to systemd basics

  • System and Service Manager