Skip to main content
When a Linux server is failing or a feature is unavailable, the underlying cause is often straightforward: the service is not running, not enabled at boot, or failing repeatedly. This guide explains how to manage services with systemd and the systemctl command so you can diagnose problems quickly and restore system functionality. In this article you will learn:
  • What systemd is and how it manages units and services.
  • The core systemctl commands you will use every day.
  • How to control boot-time behavior and apply unit overrides safely.
  • A practical troubleshooting workflow with journalctl.
A dark-themed presentation slide titled "Overview" showing two bullet points about understanding systemd and managing services with systemctl. The points mention learning how services are managed and exploring commonly used systemctl commands for daily administration.
Conceptually, think of a Linux host as a large office building. Each morning multiple subsystems must start in the correct order: electricity, elevators, HVAC, security, and office equipment. systemd is the building operations manager: it brings subsystems up in dependency order, supervises them, and restarts them if they fail.
A dark-themed infographic titled "systemd" showing a building at the top and a central technician icon labeled "systemd." Lines connect the technician to icons and labels for Electricity, Elevators, Security Systems, and Office Equipment.
systemd replaced the older System V init on modern RHEL-based systems. Historically PID 1 belonged to init; today PID 1 is the systemd process which coordinates units. A unit is a configuration object describing how systemd should manage a resource: services, mount points, sockets, timers, and so on.
A dark presentation slide titled "systemd Basics" showing a neon-outlined stack of server boxes labeled "init." The slide also notes "RHEL used system V init" and "Process ID 1: init process."
Common unit types
A dark infographic titled "systemd Units" showing six unit types and their roles. The tiles list .service, .target, .socket, .path, .timer and .mount with brief descriptions (manage background processes, group boot stages, start on connection, trigger on file changes, schedule tasks, manage mount points).
Unit file locations
  • /etc/systemd/system — administrator-managed units and overrides
  • /run/systemd/system — runtime units (ephemeral)
  • /usr/lib/systemd/system — packaged unit files (do not edit directly)
Core systemctl commands Below are the fundamental systemctl operations you will use most often. Use the exact unit name (including .service) to avoid ambiguity.
Use reload when the service supports it to avoid downtime. If reload is unsupported or the process is unhealthy, use restart to perform a clean stop-and-start.
Controlling boot-time behavior To control whether a service starts automatically on boot:
  • Enable on boot:
  • Disable on boot:
  • Check enablement state:
Other useful systemctl operations
  • List loaded and active units (filter by type):
  • Prevent a service from being started (mask):
  • Remove mask:
  • After adding or modifying unit files, notify systemd of changes:
Editing or overriding unit files Never edit packaged unit files directly under /usr/lib/systemd/system. Use systemctl edit to create drop-in override files under /etc/systemd/system/<unit>.service.d/. This preserves package updates while allowing safe customization. Example: open an override editor for the httpd service:
After saving overrides, reload and restart:
Do not modify files under /usr/lib/systemd/system directly—package updates will overwrite your changes. Use systemctl edit or drop-in files under /etc/systemd/system instead.
Minimal example of a service unit file
Troubleshooting workflow When a service fails or behaves unexpectedly, follow this step-by-step process:
  1. Check the unit status and immediate error hints:
  1. Read the unit’s journal output for detailed logs:
  1. If you modified the unit or drop-ins, reload systemd and restart:
  1. If a service must be prevented from starting (for recovery or to avoid cascading failures), mask it:
Quick reference links and resources
  • systemd manual pages
  • man systemctl and man journalctl on your system for local documentation
  • RHEL / CentOS systemd guides and administrative references
Summary systemd unifies process supervision, sockets, timers, mounts, and more through unit files. systemctl is the primary tool to start, stop, reload, restart, enable, disable, mask, and inspect units. Mastering the core commands and using the journal effectively lets you quickly diagnose failures and restore services with confidence.

Watch Video