# 08-C.8: Managing Linux Services


EXAM OBJECTIVES COVERED
2.4 Given a scenario, manage services.
4.1 Given a scenario, analyze system properties and remediate accordingly.

## Daemons and Services

Services are essential processes that usually run in the background, rather than being under the direct control of an interactive user, waiting for requests from other software programs, or to carry out essential tasks at the appropriate time. Many services are implemented as daemons.

The video talks about the Linux systemctl command and how to control system services.

In Linux, a daemon is a program that runs as a background process. Traditionally, the process names of a daemon end with the letter d, for clarification that the process is in fact a daemon, and for differentiation between a daemon and a normal computer program. For example, syslogd is a daemon that implements system logging facility, and sshd is a daemon that serves incoming SSH connections.

pbmac@ubuntu $systemctl list-unit-files --type service -all UNIT FILE STATE VENDOR PRESET accounts-daemon.service enabled enabled alsa-restore.service static enabled alsa-state.service static enabled alsa-utils.service masked enabled anacron.service enabled enabled apparmor.service enabled enabled apport-autoreport.service static enabled apport-forward@.service static enabled apport.service generated enabled This example shows some of the services running on a Linux system. Services can be listed by using the systemctl command. There are numerous options that provide a variety of output formats In a Linux environment, the parent process of a daemon is often, but not always, the init process. A daemon is usually created either by a process forking a child process and then immediately exiting, thus causing init to adopt the child process, or by the init process directly launching the daemon. In addition, a daemon launched by forking and exiting typically must perform other operations, such as dissociating the process from any controlling terminal (tty). Such procedures are often implemented in various convenience routines such as daemon(3) in Unix. Since 2015, the majority of Linux distributions have adopted systemd, having replaced other systems such as the UNIX System V and BSD init systems. systemd has faced mixed reception from Linux users over a variety of concerns. Systems often start daemons at boot time which will respond to network requests, hardware activity, or other programs by performing some task. ## Managing Daemons and Services As a Linux administrator it is important to understand services. There is an entire lifecycle that services, and actually all Linux processes, go through. Many services get started at boot time, while others are initiated at specific times or days to perform a necessary task. We will take a look at configuring and managing these services and daemons through the use of a couple of important Linux commands. In the Linux realm there are two methods that are used to initialize Linux. One is named SysVinit, the other is systemd. As was mentioned in the previous module, Linux Boot Process, towards the end of Stage 2 GRUB2 loads the selected kernel into memory and turns control of the computer over to the kernel. All of the kernels are in a self-extracting, compressed format to save space. The kernels are located in the /boot directory, along with an initial RAM disk image, and device maps of the hard drives. After the selected kernel is loaded into memory and begins executing, it must first extract itself from the compressed version of the file before it can perform any useful work. Once the kernel has extracted itself, it loads one of the initialization methods, and turns control over to it. The startup process follows the boot process and brings the Linux computer up to an operational state in which it is usable for productive work. ## systemd systemd is a software suite that provides an array of system components for Linux, and is the mother of all processes. It is responsible for bringing the Linux host up to a state in which productive work can be done. Some of its functions, which are far more extensive than the old init program, are to manage many aspects of a running Linux host, including mounting filesystems, and starting and managing system services required to have a productive Linux host. Its main aim is to unify service configuration and behavior across Linux distributions; systemd's primary component is a "system and service manager"—an init system used to bootstrap user space and manage user processes. It also provides replacements for various daemons and utilities, including device management, login management, network connection management, and event logging. The name systemd adheres to the Unix convention of naming daemons by appending the letter d. systemd daemons make it is easier to supervise and control processes and parallelized job execution. systemd also provides the systemctl mmand and cgroups to make system administration easier: 1) systemctl provides the administrator with more detailed error messages including runtime and start-up errors; and cgroups - "control groups" -allow for the grouping of processes into a hierarchy for easier management. ## Unit files: What are They? The unit files on your system determine how systemd will start and run. Each corresponds to a single activity or component — or unit in systemd terms. Each unit file is a simple text file describing a unit, what it does, what needs to run before or afterward, and other details. Unit files can be stored in a few different places on your system. systemd looks for system unit files in this order: 1. /etc/systemd/system 2. /run/systemd/system 3. /usr/lib/systemd/system Unit files in the earlier directories override later ones. This is a useful scheme, because it lets you make changes in the /etc directory, where configuration is expected. You should avoid making changes in /usr. Your system installs package data there that’s not expected to change. systemd can also run in a user context, and manage resources per user in addition to system-side. Unit files for user units are stored similarly in /etc/systemd/user, /run/systemd/user, and /usr/lib/systemd/user. The order of precedence works similarly. You can examine some details about these unit files using the systemctl command. If you want to see a list of all the unit files installed on the system, run this command: systemctl list-unit-files Each unit file contains options in the form OptionName=value, separated into sections marked like [SectionName]. These options describe how the unit works, and how systemd deals with it. There are numerous types of units systemd understands. The two most common for system owners to deal with are service units and target units. To list unit files on your system of each of these types, use the systemctl command: systemctl list-unit-files --type service systemctl list-unit-files --type target ## Service units These are the units that describe a process systemd can start and monitor. Service units are the most common units you’ll use daily. They are controlled using systemctl as root: systemctl [command] NAME.service Typical commands include: • start: starts a systemd unit • stop: attempts to “nicely” end a service • status: provides detailed information on a service • restart: restarts (stops and then starts) the specified service • enable: hooks (links) a unit to various places, for instance to run at boot • disable: unhooks (unlinks) a unit, so it is not activated The following example is the sshd.service unit file. It allows systemd to control the sshd daemon that allows remote access to your system via SSH (Secure Shell). [Unit] Description=OpenSSH server daemon Documentation=man:sshd(8) man:sshd_config(5) After=network.target sshd-keygen.service Wants=sshd-keygen.service [Service] EnvironmentFile=/etc/sysconfig/sshd ExecStart=/usr/sbin/sshd -D$OPTIONS
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

This unit features both some common unit file options, and service unit-specific options. Common options seen here include a description and where to find documentation. There is obviously more in this unit file than this article can explain. But as you can probably guess from the ExecStart option, this unit runs the sshd daemon when started.

## Service Owned Processes

One interesting feature of systemd is that it monitors processes it starts with service units. To find out what processes are being monitored, use the systemctl status command. For instance, here is output from that command checking the status of the sshd.service unit:

● sshd.service - OpenSSH server daemon
Active: active (running) since Tue 2015-10-20 14:51:24 EDT; 1 weeks 0 days ago
Docs: man:sshd(8)
man:sshd_config(5)
Main PID: 1090 (sshd)
CGroup: /system.slice/sshd.service
└─1090 /usr/sbin/sshd -D

We can see that the process started by this service has process ID (PID) 1090. This process will continue to be monitored by systemd.

Notice also that the service has placed this process in a specially named control group. The control group (or “cgroup”) allows systemd to manage associated processes together. In future articles in the series, we’ll explore how this feature allows you to tune performance and resource limits.

Thanks to knowing the processes owned by this service, systemd can also help you manage errant services. Normally when you stop a service, you’ll use the systemctl command as mentioned earlier. For example, to stop the web server service:

systemctl stop httpd.service

But what if the service doesn’t respond or cooperate? In this case, systemctl has a built in kill switch:

systemctl kill httpd.service

## Target Units

Target units are used to link and group other units together to describe a desired system state. Some of these units may be services. Others may be additional target units with their own groups of units.

Here’s an example, the multi-user.target unit file:

[Unit]
Description=Multi-User System
Documentation=man:systemd.special(7)
Requires=basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes

Notice that this target unit file doesn’t contain a command to execute. Instead, it functions purely as a way to connect other units (in this case, mostly targets) together. In this case:

• The multi-user.target requires that basic.target run successfully when multi-user.target is run.
• If the rescue.service or rescue.target units run, they will cause this unit to stop, and vice versa.
• The multi-user.target unit starts after basic.target starts, and after rescue.service and rescue.target are run, if those are started.

Additionally this target unit includes the AllowIsolate option. This option allows your system to treat the multi-user.target unit as a boot target, using the systemctl isolate command.

Target units group other units together not just with their unit file contents. A target can also have a .wants directory that links to units which will be started along with the target. For instance, the /usr/lib/systemd/system/multi-user.target file has an associated folder /usr/lib/systemd/system/multi-user.target.wants. This directory contains links to units (not just services but other targets as well) that will run when this target is run. Each of those may have its own dependencies, or unit file options like Requires above, as well.