systemd Service Management: Start, Stop, Enable and Create Services

Overview

This tutorial covers systemd service management on Red Hat Enterprise Linux (RHEL) and compatible distributions such as CentOS Stream, AlmaLinux, and Rocky Linux. You will learn how to control services with systemctl, inspect service states, configure services to persist across reboots, and author custom systemd unit files from scratch.

Prerequisites:

A running RHEL 8/9, AlmaLinux 8/9, or Rocky Linux instance (physical, VM, or cloud)
A user account with sudo or root access
Basic familiarity with the Linux command line

Why this matters for RHCSA: The Red Hat Certified System Administrator exam explicitly tests your ability to start and stop services, configure them to start at boot, and create simple unit files. These tasks appear in nearly every RHCSA exam attempt and are foundational to day-to-day Linux operations.

Getting Started

Verify that systemd is your init system and check its version before proceeding.

# Confirm systemd is PID 1
ps -p 1 -o comm=

# Check systemd version
systemctl --version

Install a sample service to practice with. The httpd (Apache) package is commonly used in RHCSA lab exercises.

# Install Apache HTTP Server
sudo dnf install -y httpd

# Confirm the unit file was registered
systemctl cat httpd.service

The systemctl cat command is invaluable — it prints the full unit file and any drop-in overrides so you can see exactly how a service is configured.

Controlling Services with systemctl

The systemctl command is the single interface for interacting with the systemd manager. Every service operation flows through it.

# Start a service (current session only)
sudo systemctl start httpd

# Stop a running service
sudo systemctl stop httpd

# Restart a service (stop then start)
sudo systemctl restart httpd

# Reload configuration without dropping connections
sudo systemctl reload httpd

# Check the live status of a service
systemctl status httpd

The status output shows the Active state, the PID, memory usage, and the most recent journal entries — read it carefully before escalating a problem.

Enabling and disabling services controls behaviour at boot time and is separate from starting or stopping them right now.

# Enable a service to start automatically at boot
sudo systemctl enable httpd

# Enable AND start immediately in one command (RHCSA favourite)
sudo systemctl enable --now httpd

# Disable a service from starting at boot
sudo systemctl disable httpd

# Disable AND stop immediately
sudo systemctl disable --now httpd

# Prevent a service from ever being started (mask it)
sudo systemctl mask httpd

# Reverse a mask
sudo systemctl unmask httpd

Common pitfall: Candidates confuse started with enabled. A service can be running right now but disabled at boot, or enabled but currently stopped. Always check both states:

# Shows both the runtime state and the boot-time preset
systemctl is-active httpd
systemctl is-enabled httpd

Creating Custom systemd Unit Files

Understanding unit file structure is essential for the RHCSA and for real production environments where you deploy custom applications.

Place user-created unit files in /etc/systemd/system/ — files here override anything in /usr/lib/systemd/system/. Never edit files under /usr/lib/ directly; they are owned by the package manager and will be overwritten on upgrades.

The following example creates a simple service that runs a Python HTTP server, which is a realistic stand-in for any long-running application daemon.

# Create a dedicated system user for the service (security best practice)
sudo useradd -r -s /sbin/nologin pyserve

# Create the working directory
sudo mkdir -p /opt/pyserve
sudo chown pyserve:pyserve /opt/pyserve

Now write the unit file:

sudo tee /etc/systemd/system/pyserve.service <<'EOF'
[Unit]
Description=Python Static File Server
Documentation=https://cloudninjas.ca
After=network.target

[Service]
Type=simple
User=pyserve
Group=pyserve
WorkingDirectory=/opt/pyserve
ExecStart=/usr/bin/python3 -m http.server 8080
Restart=on-failure
RestartSec=5s
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF

Key sections explained:

[Unit] — Metadata and ordering. After=network.target ensures the service starts only after networking is up.
[Service] — How systemd launches and monitors the process. Type=simple means the main process is the one launched by ExecStart.
[Install] — Defines the target that activates this service. multi-user.target is the standard non-graphical runlevel equivalent.

After writing any new or modified unit file you must reload the systemd daemon:

# Reload systemd manager configuration
sudo systemctl daemon-reload

# Enable and start the new service
sudo systemctl enable --now pyserve

# Verify it is running
systemctl status pyserve

# Confirm it is listening
ss -tlnp | grep 8080

# View logs for the service
journalctl -u pyserve -f

Common pitfall: Forgetting daemon-reload after editing a unit file. systemd will continue using the cached version of the file and your changes will have no effect. Always reload after any unit file modification.

Overriding vendor unit files with drop-ins is safer than editing the originals:

# Create a drop-in directory for httpd
sudo mkdir -p /etc/systemd/system/httpd.service.d/

# Add a custom environment variable override
sudo tee /etc/systemd/system/httpd.service.d/custom-env.conf <<'EOF'
[Service]
Environment="MY_VAR=cloudninjas"
EOF

sudo systemctl daemon-reload
sudo systemctl restart httpd

Exam Tips for Red Hat Certified System Administrator (RHCSA)

Key concepts that appear on the exam:

The difference between start/stop (runtime) and enable/disable (boot persistence)
Using enable --now to satisfy both requirements in a single command
Writing a functional unit file from scratch with correct [Unit], [Service], and [Install] sections
Running daemon-reload after any unit file change
Using journalctl -u <service> to diagnose failures
Understanding mask vs disable

Common exam scenarios:

You are told a service must be running and enabled after reboot — use systemctl enable --now <service>.
You must create a service that runs a script at boot — write a unit file in /etc/systemd/system/ with ExecStart pointing to the script.
A service is masked and you need to start it — run systemctl unmask first, then enable --now.

Quick reference commands:

# Most commonly tested commands — memorise these
systemctl start|stop|restart|reload <service>
systemctl enable --now <service>
systemctl disable --now <service>
systemctl status <service>
systemctl is-active <service>
systemctl is-enabled <service>
systemctl mask|unmask <service>
systemctl daemon-reload
systemctl list-units --type=service --state=running
journalctl -u <service> --since today
journalctl -xe

Summary

You have covered the complete systemd service management workflow required for the RHCSA exam and production Linux environments:

Controlling service runtime state with start, stop, restart, and reload
Persisting services across reboots with enable and the powerful enable --now shortcut
Preventing services from running with mask and reversing that with unmask
Authoring custom systemd unit files in /etc/systemd/system/ with correct section structure
Using daemon-reload after every unit file modification
Diagnosing failures with journalctl -u

Next steps: Practice writing unit files for different Type= values (forking, oneshot, notify) and explore systemd timers as a modern replacement for cron jobs. Both topics extend naturally from what you have learned here.

For a complete RHCSA study path including storage, SELinux, and networking labs, visit the CloudNinjas.ca Certification Guide.