Systemd (linux command)

Word Count: 796
  • Post category:Servers
  • Post last modified:2023-09-09

Introduction

This article is an extract and simplified version of the Source:

Systemd is a system and service manager for Linux. It is the default init system for Debian since Debian 8 (“jessie”).

Systemd runs as a daemon with PID 1.

Units

Units are resources that they are able to be managed.

The most common units are services (.service), mount points (.mount), devices (.device), sockets (.socket), or timers (.timer). For instance, starting the secure shell daemon is done by the unit ssh.service. In here, we focus mainly on the service unit.

A service file has an extenson .service and is located in one of these directories:

  • /etc/systemd/system – Units here have highest priority than the units in the other 2 directories
  • /run/systemd/system – for run time systemd Units and they have higher priortiy than those in /lib/…
  • /lib/systemd/system – for Unit files created during package installations

A service file consistes of 3 sections in the file:

  • [Unit] contains info of the Unit.
    • Description of the Unit
    • Wants – Pre-requisite to start the service
    • After – Only after these services are available, then this service will start.
    • Documentation – where to find the doc
  • [Service]
    • Type = notify | forking | etc…
    • ExecStart – to start the specified program when the service starts.
    • ExecReload – to reload the specified program when the service reloads.
  • [Install] section is optiona. If it is there, it controls what happens when a unit file is enabled or disabled.
    • e.g. WantedBy = multi-user.target would mean the prerequisite for the service to start is when the system is at the multi-user run level.

Systemd puts every service into a dedicated control group (cgroup) named after the service. Modern kernels support process isolation and resource allocation based on cgroups.

Targets

Targets are groups of units. Targets call units to put the system together. For instance, graphical.target calls all units that are necessary to start a workstation with graphical user interface. Targets can build on top of another or depend on other targets. At boot time, systemd activates the target default.target which is an alias for another target such as graphical.target.

Systemd creates and manages the sockets used for communication between system components. For instance, it first creates the socket /dev/log and then starts the syslog daemon.

Basic Usage

systemctl is the tool used to  introspect and control the state of the “systemd” system and service manager. You can use systemctl to enable/disable services permanently or only for the current session. Refer to the systemctl(1) manpage for more details.

Get system status

  • Show system status: $ systemctl status
  • List failed units: $ systemctl --failed

Manage services

  • List all running servicess: $ systemctl
  • Activate a service immediately: # systemctl start example1
  • Deactivate a service immediately: # systemctl stop example1
  • Restarts a service immediately: # systemctl restart example1
  • Shows status : # systemctl status example1
  • Enables a service to be started on bootup: # systemctl enable example1
  • Disables a service to not start during bootup: # systemctl disable example1

Creating or altering services

Units are defined by individual configuration files, called unit files. The type of the unit is recognized by the file name suffix, .mount in case of a mount point.

Unit files provided by Debian are located in the /lib/systemd/system directory. If an identically named local unit file exists in the directory /etc/systemd/system, it will take precedence and systemd will ignore the file in the /lib/systemd/system directory.

Some units are created by systemd without a unit file existing in the file system.

System administrators should put new or heavily-customized unit files in /etc/systemd/system.

For small tweaks to a unit file, system administrators should use the “drop-in directory” feature (documented in systemd.unit(5)).

  • Start by determining the canonical systemd service name (e.g. ssh.service, not an alias like sshd.service). We’ll use “name.service” for this example.
  • Create the directory /etc/systemd/system/name.service.d
  • Create files inside this directory ending with a “.conf” suffix. For example, /etc/systemd/system/name.service.d/local.conf
  • Each file should contain the section headers and section options to be overridden, using the same format as unit files.
  • If you’re overriding ExecStart=, you need to put an empty ExecStart= line in the override file, to “clear out” the existing command list. Otherwise, all non-empty ExecStart= lines append a new command to the list.

Here’s an example:

# cat /etc/systemd/system/name.service.d/local.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/name-service --my-options

Debugging

Failed units

  • In some cases units enter a failed state. The status command can be used to find out some details: $ systemctl status <UNIT_NAME>
  • Failed units can be manually cleared out: # systemctl reset-failed
Tags: ,