RED HAT ENTERPRISE LINUX

Controlling Services and Daemons

Managing System Services with systemd

CIS126RH | RHEL System Administration 1
Mesa Community College

Welcome to this essential module on controlling services and daemons in Red Hat Enterprise Linux. systemd is the init system and service manager that has been the standard in RHEL since version 7. It's responsible for starting the system, managing services, handling dependencies, and much more. Understanding systemd is absolutely critical for any Linux administrator. Every server runs services - web servers, databases, SSH, DNS, and dozens of others. You need to know how to start, stop, restart, and check the status of these services. You need to configure which services start at boot. You need to troubleshoot when services fail. This module covers the systemctl command for service management, understanding unit files, working with targets (systemd's replacement for runlevels), and viewing logs with journalctl. These are essential skills for daily administration and required for the RHCSA exam.

Learning Objectives

Control services with systemctl

Start, stop, restart, and check status of system services

Understand systemd units

Work with service, target, socket, and other unit types

Manage boot targets

Configure default boot target and switch between targets

View service logs

Use journalctl to examine systemd journal entries

We have four main learning objectives for this module. First, we'll master controlling services with systemctl - the primary command for interacting with systemd. You'll learn to start, stop, restart, and reload services, check their status, and enable or disable them at boot. Second, we'll understand systemd units. A unit is anything systemd knows how to manage - services are the most common, but there are also targets, sockets, mounts, timers, and more. Understanding unit types and unit files is essential for advanced administration. Third, we'll work with boot targets. Targets are systemd's replacement for traditional runlevels. They define system states like multi-user mode or graphical mode. You'll learn to check and change the default target and switch between targets. Fourth, we'll use journalctl to view the systemd journal. This is where systemd logs everything - service output, boot messages, and system events. Effective log analysis is crucial for troubleshooting.

What is systemd?

systemd is the system and service manager for Linux. It's the first process started by the kernel (PID 1) and is responsible for bringing up the rest of the system.

Service Manager

Starts, stops, and monitors system services and daemons

Dependency Handling

Manages service dependencies and ordering automatically

Parallel Startup

Starts services in parallel for faster boot times

Logging (Journal)

Captures and stores logs from services and the kernel

PID 1: systemd is always PID 1. If it crashes, the kernel panics. It's the ancestor of all other processes.

systemd has become the standard init system for most major Linux distributions, including RHEL since version 7. It replaces the older SysVinit system and provides many advanced features. As PID 1, systemd is the first user-space process started by the kernel after boot. It's responsible for starting everything else - mounting filesystems, starting services, setting up the network. If systemd crashes, the whole system goes down. As a service manager, systemd starts, stops, and monitors daemons. A daemon is a background process that provides some service - like httpd for web serving or sshd for remote access. systemd tracks their status and can restart them if they crash. Dependency handling means systemd understands that some services need others to start first. It builds a dependency tree and starts services in the correct order, or in parallel when dependencies allow. Speaking of parallel startup, systemd can start many services simultaneously rather than one at a time. This significantly reduces boot time compared to the sequential startup of older init systems. The journal is systemd's logging system. It captures output from all services, kernel messages, and more, stored in a binary format for efficient querying with journalctl.

systemd Units

A unit is a resource that systemd knows how to manage. Units are defined by unit files and identified by their name and type suffix.

.service

System services
(daemons)

.target

Group of units
(like runlevels)

.socket

Socket activation
(on-demand start)

.mount

Filesystem
mount points

.timer

Scheduled tasks
(like cron)

.path

Path monitoring
(file triggers)

# List all unit types
[student@server ~]$ systemctl -t help
Available unit types:
service  socket  target  device  mount  automount  swap
snapshot  timer  path  slice  scope

Everything systemd manages is a unit. While services are the most common and what we'll focus on, understanding other unit types helps you see the full picture. Service units (.service) are the most common - they manage daemons like httpd, sshd, or crond. When we talk about "starting a service" we mean activating a service unit. Target units (.target) are groups of units that represent a system state. Multi-user.target means the system is ready for multiple users but without a graphical interface. Graphical.target adds the GUI. Targets replaced the old runlevel concept. Socket units (.socket) enable socket activation. Instead of starting a service immediately, systemd can listen on a socket and start the service only when a connection arrives. This saves resources for rarely-used services. Mount units (.mount) manage filesystem mount points. They're often generated automatically from /etc/fstab but can also be defined explicitly for more control. Timer units (.timer) are systemd's alternative to cron. They can trigger service units on a schedule or after certain time intervals. Path units (.path) monitor filesystem paths and can start services when files change or appear. The systemctl -t help command lists all available unit types on your system.

Unit File Locations

Directory	Purpose	Priority
/usr/lib/systemd/system/	Installed by packages (RPM)	Lowest
/etc/systemd/system/	Local administrator customizations	Highest
/run/systemd/system/	Runtime units (temporary)	Medium

# View where a unit file is located
[student@server ~]$ systemctl cat sshd.service
# /usr/lib/systemd/system/sshd.service
[Unit]
Description=OpenSSH server daemon
...

# List all unit files and their states
[student@server ~]$ systemctl list-unit-files
UNIT FILE                  STATE    VENDOR PRESET
sshd.service               enabled  enabled
httpd.service              disabled disabled
...

# Show the actual file path
[student@server ~]$ systemctl show -p FragmentPath sshd.service
FragmentPath=/usr/lib/systemd/system/sshd.service

Unit files can exist in multiple locations, and the location determines priority when the same unit name exists in multiple places. /usr/lib/systemd/system/ is where RPM packages install their unit files. These are vendor-provided defaults and should not be edited directly - package updates will overwrite your changes. /etc/systemd/system/ is for local administrator customizations. Files here override those in /usr/lib/systemd/system/. This is where you put custom units or modifications to existing units. /run/systemd/system/ is for runtime units that don't persist across reboots. Systemd itself creates units here for certain purposes. The priority from lowest to highest is: /usr/lib → /run → /etc. So if sshd.service exists in both /usr/lib/systemd/system/ and /etc/systemd/system/, the one in /etc takes precedence. The "systemctl cat" command shows a unit file's contents and tells you which file it's reading. "systemctl list-unit-files" shows all installed units and their enabled/disabled state. "systemctl show -p FragmentPath" reveals the exact filesystem path. Understanding these locations is crucial for properly customizing services without losing changes during updates.

The systemctl Command

# Basic syntax
systemctl [command] [unit]

# Common service control commands
[root@server ~]# systemctl start httpd.service    # Start now
[root@server ~]# systemctl stop httpd.service     # Stop now
[root@server ~]# systemctl restart httpd.service  # Stop then start
[root@server ~]# systemctl reload httpd.service   # Reload config

# Check status
[student@server ~]$ systemctl status httpd.service
[student@server ~]$ systemctl is-active httpd.service
[student@server ~]$ systemctl is-enabled httpd.service

# Boot-time configuration
[root@server ~]# systemctl enable httpd.service   # Start at boot
[root@server ~]# systemctl disable httpd.service  # Don't start at boot

# Combined: enable and start in one command
[root@server ~]# systemctl enable --now httpd.service

Tip: The .service suffix is optional for service units. systemctl start httpd works the same as systemctl start httpd.service.

systemctl is your primary command for interacting with systemd. Almost everything you do with services goes through this command. The basic pattern is "systemctl command unit". Let's cover the essential commands. "start" immediately starts a service. The service must exist and not already be running. "stop" immediately stops a running service. "restart" stops then starts a service - useful after configuration changes that require a full restart. "reload" tells the service to reread its configuration without fully stopping. Not all services support reload - check the documentation. The difference between restart and reload matters: restart briefly interrupts the service (connections may drop), while reload keeps it running (typically no interruption). "status" shows detailed information about a service - we'll look at this output in detail shortly. "is-active" returns whether the service is currently running (useful in scripts). "is-enabled" returns whether the service is configured to start at boot. "enable" creates the symlinks needed for a service to start at boot. It doesn't start the service now. "disable" removes those symlinks - the service won't start at boot but isn't stopped if currently running. The --now flag combines enabling/disabling with starting/stopping. "enable --now" enables AND starts. "disable --now" disables AND stops. Very convenient.

Service Status Deep Dive

● sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: enabled) Active: active (running) since Mon 2025-12-08 09:00:00 EST; 2h ago Docs: man:sshd(8) man:sshd_config(5) Main PID: 1234 (sshd) Tasks: 1 (limit: 23456) Memory: 5.2M CPU: 125ms CGroup: /system.slice/sshd.service └─1234 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups" Dec 08 09:00:00 server systemd[1]: Starting OpenSSH server daemon... Dec 08 09:00:00 server sshd[1234]: Server listening on 0.0.0.0 port 22. Dec 08 09:00:00 server systemd[1]: Started OpenSSH server daemon.

Loaded: Unit file path, enabled status

Active: Current state and duration

Main PID: Process ID of main daemon

Tasks/Memory/CPU: Resource usage

CGroup: Control group containing the service

Log entries: Recent journal messages

The systemctl status output is information-rich. Let's break it down piece by piece. The first line shows the unit name and description. The colored dot indicates state: green for running, red for failed, white for inactive. "Loaded" shows where the unit file is located and whether the service is enabled for boot. "preset: enabled" means the vendor default is to enable this service. "Active" is the current state - here it's "active (running)" with how long it's been in this state. Other states include "inactive (dead)", "failed", "activating", "deactivating". "Docs" points to manual pages for more information about configuring the service. "Main PID" is the process ID of the main service process. This is what you'd use with kill if needed (though systemctl stop is preferred). "Tasks" shows how many processes/threads belong to this service. Memory and CPU show current resource consumption. "CGroup" shows the control group - systemd uses cgroups to track all processes belonging to a service, even if they fork. The bottom section shows recent log entries from the journal for this service. This is often the first place to look when troubleshooting - you'll see startup messages, errors, and other service output.

Service States

State	Meaning
active (running)	Service is running normally
active (exited)	Service ran successfully and exited (one-shot)
active (waiting)	Service is running but waiting for an event
inactive (dead)	Service is not running
activating	Service is starting up
deactivating	Service is shutting down
failed	Service crashed or failed to start

# Quick state checks (useful in script