systemd — Service Management, Units, and Targets

Overview

systemd is PID 1 on RHEL 9. It is the first userspace process started by the kernel at boot, and it is responsible for initialising the system, starting and managing services throughout the system’s operational life, and coordinating the shutdown sequence. It replaces the traditional SysV init system and Upstart that were used on older RHEL versions.

The core advantage of systemd over SysV init is parallel service startup. SysV init started services sequentially using numbered shell scripts in /etc/rc.d/ — each service had to complete before the next could begin. systemd tracks dependencies between services and starts independent services simultaneously, dramatically reducing boot time on modern systems with multiple CPU cores.

Beyond faster boot, systemd provides socket activation (services started on-demand when a connection arrives on their socket), D-Bus activation, on-demand mounting of filesystems, and tight integration with cgroups (control groups) for resource accounting and limiting. All logs produced by systemd-managed services are captured by systemd-journald, which stores them in a structured binary format queryable with journalctl.

Units

systemd organises everything it manages as a unit. A unit is a configuration file that describes a resource, service, or relationship. Units are identified by their filename, which ends in a suffix indicating the unit type.

When you refer to a unit without a suffix, systemd assumes .service. So systemctl start nginx and systemctl start nginx.service are equivalent.

Unit File Locations

Unit files exist in three locations with a defined precedence order (highest to lowest):

When a package installs a service (for example, nginx or sshd), its unit file goes into /usr/lib/systemd/system/. To customise a vendor unit without modifying the original, create an override in /etc/systemd/system/ — either a complete replacement or a drop-in directory (/etc/systemd/system/nginx.service.d/override.conf) containing only the settings you want to change.

Controlling Services with systemctl

The systemctl command is the primary interface for managing units:

Enabling a unit makes it start automatically at boot by creating a symbolic link in the appropriate .wants/ or .requires/ directory of the default target. It does not start the unit immediately. Use systemctl enable --now unit to enable and start in one step.

Masking is stronger than disabling. A masked unit cannot be started manually or as a dependency. It is used when you want to guarantee that a unit never runs — for example, masking firewalld.service if a different firewall tool is deployed.

systemctl daemon-reload must be run after creating or modifying unit files in /etc/systemd/system/. Without it, systemd continues using the version of the unit it loaded at startup and ignores your changes.

Service Unit File Structure

A .service unit file has three sections:

[Unit]
Description=My Application Server
Documentation=https://example.com/docs
After=network.target
Requires=postgresql.service
Wants=redis.service

[Service]
Type=simple
User=appuser
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/bin/server --config /etc/myapp/config.toml
ExecStop=/opt/myapp/bin/server --stop
Restart=on-failure
RestartSec=5
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

[Unit] section — metadata and dependency declarations:

• After= — this unit starts after the listed units, but does not require them to be present
• Requires= — hard dependency; if the required unit fails, this unit fails too
• Wants= — soft dependency; the required unit is started alongside this one, but failure of the dependency does not cause this unit to fail

[Service] section — how the process runs:

• Type=simple — the ExecStart process is the main process; systemd considers the service started once that process is running. Other types: forking (service daemonises itself), oneshot (runs to completion then stops), notify (service sends a notification via sd_notify when ready)
• Restart=on-failure — automatically restart if the process exits with a non-zero exit code

[Install] section — where to hook this unit when enabled:

• WantedBy=multi-user.target — enabling this service creates a symlink in /etc/systemd/system/multi-user.target.wants/

Targets

A target is a synchronisation point that groups related units. When systemd activates a target, it activates all units that the target requires or wants. Targets replaced SysV runlevels.

systemctl get-default                    # Show the default target (boots into this)
systemctl set-default graphical.target   # Change default target
systemctl isolate rescue.target          # Switch to target immediately (like changing runlevel)
systemctl isolate multi-user.target      # Drop to text mode without rebooting

systemctl isolate activates the specified target and stops all units not required by it. This allows switching between graphical and text modes on a live system, or entering rescue mode without a reboot.

Practical Workflow

A typical workflow for deploying a custom service unit:

1. Create the unit file at /etc/systemd/system/myapp.service
2. Run systemctl daemon-reload to make systemd aware of the new file
3. Run systemctl start myapp to test it
4. Check systemctl status myapp and journalctl -u myapp -f for errors
5. Run systemctl enable myapp to make it persistent across reboots
6. Verify with systemctl is-enabled myapp

Summary

systemd is PID 1 on RHEL 9 and manages all system resources through a unit file model. Service units define how daemons run; socket and timer units enable on-demand and scheduled activation; target units group units into dependency-based boot milestones that replace SysV runlevels. The systemctl command is the single interface for starting, stopping, enabling, disabling, and inspecting all units. Always run systemctl daemon-reload after modifying unit files in /etc/systemd/system/ — without it, systemd will silently continue using the old configuration.