Service Management in Systemd

Shows the basic systemctl start and systemctl stop commands and explains how state changes persist.

To start a service, use the systemctl start command:

sudo systemctl start sshd

To stop a service, use the systemctl stop command:

sudo systemctl stop sshd

Changing the state of a service only lasts while the system remains at the same state.

If you stop a service and then change the system-state target to one in which the service is configured to run (for example, by rebooting the system), the service restarts. Similarly, starting a service doesn't enable the service to start following a reboot. See Enabling and Disabling Services.

Explains how to enable, disable, mask, and unmask services so they start (or stay stopped) across reboots.

You can use the systemctl command to enable or disable a service from starting when the system boots, for example:

sudo systemctl enable httpd

Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.

The enable command activates a service by creating a symbolic link for the lowest-level system-state target at which the service starts. In the previous example, the command creates the symbolic link httpd.service for the multi-user target.

Disabling a service removes the symbolic link:

sudo systemctl disable httpd

Removed /etc/systemd/system/multi-user.target.wants/httpd.service.

To check whether a service is enabled, use is-enabled subcommand as shown in the following examples:

systemctl is-enabled httpd

disabled

systemctl is-enabled sshd

enabled

After running the systemctl disable command, the service can still be started or stopped by user accounts, scripts, and other processes.

However, if you need to ensure that the service can't be started inadvertently, for example, by a conflicting service, then use the systemctl mask command as follows:

sudo systemctl mask httpd

Created symlink from '/etc/systemd/system/multi-user.target.wants/httpd.service' to '/dev/null'

The mask command sets the service reference to /dev/null. If you try to start a service that has been masked, you will receive an error as shown in the following example:

sudo systemctl start httpd

Failed to start httpd.service: Unit is masked.

To relink the service reference back to the matching service unit configuration file, use the systemctl unmask command:

sudo systemctl unmask httpd

For more information, see the systemctl(1) manual page.

Details the systemctl is-active and status commands for checking service health and control groups.

To check whether a service is running, use the is-active subcommand. The output would either be active or inactive, as shown in the following examples:

systemctl is-active httpd

active

systemctl is-active sshd

inactive

The status subcommand provides a detailed summary of the status of a service, including a tree that displays the tasks in the control group (CGroup) that the service implements:

systemctl status httpd

httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since ...
     Docs: man:httpd.service(8)
 Main PID: 11832 (httpd)
   Status: "Started, listening on: port 80"
    Tasks: 213 (limit: 26213)
   Memory: 32.5M
   CGroup: /system.slice/httpd.service
           ├─11832 /usr/sbin/httpd -DFOREGROUND
           ├─11833 /usr/sbin/httpd -DFOREGROUND
           ├─11834 /usr/sbin/httpd -DFOREGROUND
           ├─11835 /usr/sbin/httpd -DFOREGROUND
           └─11836 /usr/sbin/httpd -DFOREGROUND

Jul 17 00:14:32 Unknown systemd[1]: Starting The Apache HTTP Server...
Jul 17 00:14:32 Unknown httpd[11832]: Server configured, listening on: port 80
Jul 17 00:14:32 Unknown systemd[1]: Started The Apache HTTP Server.

A cgroup is a collection of processes that are bound together so that you can control their access to system resources. In the example, the cgroup for the httpd service is httpd.service, which is in the system slice.

Slices divide the cgroups on a system into different categories. To display the slice and cgroup hierarchy, use the systemd-cgls command:

systemd-cgls

Control group /:
-.slice
├─user.slice
│ └─user-1000.slice
│   ├─user@1000.service
│   │ └─init.scope
│   │   ├─6488 /usr/lib/systemd/systemd --user
│   │   └─6492 (sd-pam)
│   └─session-7.scope
│     ├─6484 sshd: root [priv]
│     ├─6498 sshd: root@pts/0
│     ├─6499 -bash
│     ├─6524 sudo systemd-cgls
│     ├─6526 systemd-cgls
│     └─6527 less
├─init.scope
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 16
└─system.slice
  ├─rngd.service
  │ └─1266 /sbin/rngd -f --fill-watermark=0
  ├─irqbalance.service
  │ └─1247 /usr/sbin/irqbalance --foreground
  ├─libstoragemgmt.service
  │ └─1201 /usr/bin/lsmd -d
  ├─systemd-udevd.service
  │ └─1060 /usr/lib/systemd/systemd-udevd
  ├─polkit.service
  │ └─1241 /usr/lib/polkit-1/polkitd --no-debug
  ├─chronyd.service
  │ └─1249 /usr/sbin/chronyd
  ├─auditd.service
  │ ├─1152 /sbin/auditd
  │ └─1154 /usr/sbin/sedispatch
  ├─tuned.service
  │ └─1382 /usr/libexec/platform-python -Es /usr/sbin/tuned -l -P
  ├─systemd-journald.service
  │ └─1027 /usr/lib/systemd/systemd-journald
  ├─atd.service
  │ └─1812 /usr/sbin/atd -f
  ├─sshd.service
  │ └─1781 /usr/sbin/sshd

The system.slice contains services and other system processes. user.slice contains user processes, which run within transient cgroups called scopes.

In the example, the processes for the user with ID 1000 are running in the scope session-7.scope under the slice /user.slice/user-1000.slice.

You can use the systemctl command to limit the CPU, I/O, memory, and other resources that are available to the processes in service and scope cgroups. See Controlling Access to System Resources.

For more information, see the systemctl(1) and systemd-cgls(1) manual pages. Also see Using Systemd to Manage Control Groups.

Shows how to use systemctl set-property and systemd-run to assign CPU and memory limits to services and scopes.

Use the systemctl command to control a cgroup's access to system resources, for example:

sudo systemctl [--runtime] set-property httpd CPUShares=512 MemoryLimit=1G

CPUShare controls access to CPU resources. As the default value is 1024, a value of 512 halves the access to CPU time that the processes in the cgroup have. Similarly, MemoryLimit controls the maximum amount of memory that the cgroup can use.

Alternatively, you can change the resource settings for a service under the [Service] heading in the service's configuration file in /usr/lib/systemd/system. After editing the file, make systemd reload its configuration files and then restart the service:

sudo systemctl daemon-reload
sudo systemctl restart service

You can run general commands within scopes and use systemctl to control the access that these transient cgroups have to system resources. To run a command within in a scope, use the systemd-run command:

sudo systemd-run --scope --unit=group_name.scope [--slice=slice_name]

If you don't want to create the group under the default system slice, you can specify another slice or the name of a new slice. The following example runs a command named mymonitor in mymon.scope under myslice.slice:

sudo systemd-run --scope --unit=mymon.scope --slice=myslice mymonitor

Running as unit mymon.scope.

You can then use systemctl to control the access that a scope has to system resources in the same way as for a service. However, unlike a service, you must specify the .scope extension, for example:

sudo systemctl --runtime set-property mymon.scope CPUShares=256

For more information see Using Systemd to Manage Control Groups and the systemctl(1), systemd-cgls(1), and systemd.resource-control(5) manual pages.

Describes how to override packaged unit files and create drop-in snippets under /etc/systemd/system.

To change the configuration of systemd services, copy the files with .service, .target, .mount and .socket extensions from /usr/lib/systemd/system to /etc/systemd/system.

After you have copied the files, you can edit the versions in /etc/systemd/system.

The files in /etc/systemd/system take precedence over the versions in /usr/lib/systemd/system. Files in /etc/systemd/system aren't overwritten when you update a package that touches files in /usr/lib/systemd/system.

To revert to the default systemd configuration for a particular service, you can either rename or delete the copies in /etc/systemd/system.

Another approach for changing the configuration of a service is to create a drop-in file. With this approach, you can preserve the original unit while changing specific parameters of the unit.

Create drop-in files in /etc/systemd/system/unit_name.d/, where the unit_name.d directory is an existing unit, then give the drop-in files a .conf file extension.

For example: /etc/systemd/system/unit_name.d/name_of_drop-in.conf. systemd reads the .conf file and applies the settings to the original unit.

The following sections describe the different parts of a service unit file that you can edit and customize for a system.