Jump to content

Sending termination signals to systemd services

Publication Date: 09/24/2021

1 Environment

  • File Name: task-send-termination-signals-systemd.xml
  • ID: environment-send-termination-signals-systemd

This document applies to the following products and product versions:

  • SUSE Linux Enterprise Server 15 SP3, 15 SP2, 15 SP1, 15 GA, 12 SP5, 12 SP4, 12 SP3

  • SUSE Linux Enterprise Server for SAP Applications 15 SP3, 15 SP2, 15 SP1, 15 GA, 12 SP5, 12 SP4, 12 SP3

  • SUSE Linux Enterprise High Availability Extension 15 SP3, 15 SP2, 15 SP1, 15 GA, 12 SP5, 12 SP4, 12 SP3

  • SUSE Linux Enterprise High Performance Computing 15 SP3, 15 SP2, 15 SP1, 15 GA

  • SUSE Linux Enterprise Desktop 15 SP3, 15 SP2, 15 SP1, 15 GA, 12 SP5, 12 SP4, 12 SP3

  • SUSE Linux Enterprise Real Time 15 SP3, 15 SP2, 15 SP1, 15 GA, 12 SP5, 12 SP4, 12 SP3

2 Introduction

  • File Name: task-send-termination-signals-systemd.xml
  • ID: introduction-send-termination-signals-systemd

systemd's organization of confining each service into a cgroup makes it possible to clearly identify all parent and child processes of a service, and therefore allows you to send a signal to each of these processes. You may send a signal to a systemd service, or to individual processes that belong to a service.

3 Requirements

  • File Name: task-send-termination-signals-systemd.xml
  • ID: requirements-send-termination-signals-systemd
  • The systemctl command.

  • The systemd-cgls command.

  • Knowledge of how processes work in Linux.

The following examples demonstrate how to identify processes that belong to a systemd service, and how to stop processes with native systemd commands.

4 Identifying and stopping processes in systemd services

  • File Name: task-send-termination-signals-systemd.xml
  • ID: send-termination-signals-systemd

The systemd-cgls command displays all processes that belong to a systemd service, and systemctl SIGNAL PROCESS stops them.

Note
Note: Important notes on the D-Bus service

The D-Bus service is the message bus for communication between systemd clients and the systemd manager that is running as pid 1. Even though dbus is a stand-alone daemon, it is an integral part of the init infrastructure.

Terminating dbus or restarting it in the running system is similar to an attempt to terminate or restart pid 1. It will break systemd client/server communication and make most systemd functions unusable.

Therefore, terminating or restarting dbus is neither recommended nor supported.

Updating the dbus or dbus-related packages requires a reboot. When in doubt whether a reboot is necessary, run the sudo zypper ps -s. If dbus appears among the listed services, you need to reboot the system.

Keep in mind that dbus is updated even when automatic updates are configured to skip the packages that require reboot.

  • List all cgroups and their processes:

    tux > systemd-cgls
  • Display all processes that belong to a particular service, for example,: the libvirtd.service service:

    tux > systemd-cgls -u libvirtd.service
  • Send a termination signal to the service. SIGTERM (15) is the default:

    tux > sudo systemctl kill SERVICE_NAME
  • Send a different signal to a service with the -s option, such as SIGKILL (9):

    tux > sudo systemctl kill -s 9 SERVICE_NAME
  • By default the kill command sends the signal to all processes of the specified cgroup. 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:

    tux > sudo systemctl kill -s SIGHUP --kill-who=main SERVICE_NAME

5 Summary

  • File Name: task-send-termination-signals-systemd.xml
  • ID: summary-termination-signals-systemd

This article details how to find all processes that belong to a systemd service, and how to stop them with native systemd commands.

6 Troubleshooting

  • File Name: task-send-termination-signals-systemd.xml
  • ID: troubleshooting-termination-signals-systemd

If anything goes wrong, the answers are most likely in the systemd logging journal, journalctl.

How to find answers in journalctl?

By default, the journalctl command displays oldest entries first. View the most recent entries:

tux > journalctl -r
How to filter the journal to find the entries you want to see?

A quick way is with grep, for example:

tux > journalctl -r | grep SERVICE_NAME
Print this page