Learn Rocky Linux - Systemd & Service Management

#Introduction

In the previous episode 6, you learned to manage who can access the system. Now it's time to understand who runs the system itself — the services running continuously in the background, from SSH to web servers and databases. They're all coordinated by a single entity: systemd.

Systemd is the init system that is the first process the kernel runs at boot. It doesn't just start services; it also manages processes, devices, mount points, logs, timers, and system state. On Rocky Linux, almost no aspect of the system escapes systemd. This episode will make you comfortable with systemctl, unit files, and journalctl — three tools that will accompany you every day.

#Service Management with Systemctl

#Basic Operations

The core commands for managing services are intuitive:

systemctl start httpd
systemctl stop httpd
systemctl restart httpd
systemctl status httpd

systemctl enable httpd
systemctl disable httpd

It's important to understand the difference between start vs enable: start runs the service now, enable makes it run automatically at boot. The correct practice usually combines both:

systemctl enable --now httpd

#Status and IsSystemRunning

To see the overall condition of the system:

systemctl is-system-running

systemctl list-units --type=service --state=running

The systemctl is-system-running output gives a quick overview: running means everything is normal, degraded indicates a failed unit — and your first investigation candidate.

#Targets

#The Target Concept

Systemd replaces traditional runlevels with targets — collections of units representing a particular system state. Instead of "runlevel 3", you'll encounter multi-user.target.

systemctl get-default

systemctl set-default multi-user.target

A Rocky Linux server boots to multi-user.target by default. Targets like rescue and emergency will be very useful when troubleshooting boot in episode 10.

#Unit Files and Journald

#Anatomy of a Service Unit File

A .service unit file defines how systemd runs a service. You can place them in /etc/systemd/system/ for custom services:

cat > /etc/systemd/system/myapp.service <<'EOF'
[Unit]
Description=My Application Service
After=network-online.target
 
[Service]
Type=simple
ExecStart=/usr/local/bin/myapp --config /etc/myapp.conf
Restart=on-failure
User=myapp
Environment=APP_ENV=production
 
[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now myapp

Key parts of this unit file:

• Type=simple — systemd considers the directly-running process as the service.
• ExecStart — the command to run; must use an absolute path.
• Restart=on-failure — automatic restart when the process fails; the key to service resilience.
• User=myapp — the service runs as a non-root user, following the least privilege principle from episode 6.
• Environment — environment variables passed to the process.

#Configuration Overrides

Instead of modifying unit files from vendor packages (which will be overwritten on update), systemd provides a clean override mechanism:

systemctl edit httpd

mkdir -p /etc/systemd/system/httpd.service.d
echo -e '[Service]\nEnvironment=TZ=Asia/Jakarta' \
  > /etc/systemd/system/httpd.service.d/timezone.conf
systemctl daemon-reload
systemctl restart httpd

Overrides placed in /etc/systemd/system/ take precedence over the default unit from /usr/lib/systemd/system/ without touching the original file — your changes are safe from package updates.

#Journalctl for Centralized Logs

Journald collects logs from all services centrally, and journalctl is its gateway:

journalctl -u httpd

journalctl -b -p err

journalctl -u httpd --since "2026-08-03 08:00" --until "2026-08-03 10:00"

journalctl -u httpd -f

Combining -b (last boot), -p (priority: err, warning, info), and -u (unit) makes problem investigation focused. journalctl -u httpd -f follows logs live — the best way to watch a service when a problem occurs in real time.

#Service Troubleshooting

If a service won't start, a structured debugging flow saves time:

systemctl status myapp
systemctl status myapp --no-pager

journalctl -u myapp --no-pager -n 50

Check these things in order: whether the unit file is valid and has been reloaded, whether ExecStart points to the correct executable path, whether the specified user has permissions, and whether the target dependencies are met. Most service failures come from one of these four points.

#Closing

In this episode 7, you mastered service management on Rocky Linux: systemctl operations for start, stop, restart, and enable, the concept of targets like multi-user and rescue, creating service unit files with Type, ExecStart, Restart, User, and Environment, update-safe configuration overrides, and reading and filtering logs with journalctl.

Key takeaways:

• start runs a service now; enable sets up auto-start; combine them with enable --now.
• Targets replace runlevels: multi-user, graphical, rescue, and emergency.
• Custom unit files go in /etc/systemd/system/ with daemon-reload after changes.
• Override with systemctl edit protects your changes from vendor package updates.
• journalctl -u <service> -b -p err is the fast path for investigating service failures.

In the next episode 8, we will discuss storage, LVM, and filesystems — disk management with lsblk, parted, and mkfs, mount points and fstab, the Logical Volume Manager with PV/VG/LV and snapshots, and modern filesystems like XFS, Btrfs, and Stratis. Services are running; now it's time to make sure the data is stored correctly!