RED HAT ENTERPRISE LINUX

systemd Services

Control and Monitor System Services and Daemons

College-Level Course Module | RHEL System Administration

Welcome to this essential module on managing system services with systemd. systemd is the init system and service manager for RHEL and most modern Linux distributions. It controls what services start at boot, manages their lifecycle during operation, and provides tools for monitoring their status. As a system administrator, you will constantly work with services - starting web servers, stopping databases for maintenance, checking why a service failed, configuring services to start automatically. Understanding systemd is essential for managing any RHEL system. In this module, you will learn what systemd is and how it works, how to control services with systemctl, how to check service status and troubleshoot failures, how to configure services to start at boot, and how systemd targets organize the boot process. These skills are fundamental for RHEL system administration.

Learning Objectives

Understand systemd architecture

Units, services, daemons, and the systemd ecosystem

Control services with systemctl

Start, stop, restart, and reload services

Monitor service status

Check status, view logs, and troubleshoot failures

Configure boot behavior

Enable and disable services for automatic startup

Work with systemd targets

Understand boot targets and system states

What is systemd?

systemd is the system and service manager for Linux. It is the first process started at boot (PID 1) and is responsible for starting all other services and managing them throughout the system's operation.

systemd Responsibilities:

Boot the system (init process)
Start/stop services on demand
Track service dependencies
Manage system logging (journald)
Mount filesystems
Manage network, time, login

Key Components:

systemd - Main daemon (PID 1)
systemctl - Control command
journald - Logging system
journalctl - Log viewer
Unit files - Service definitions

History: systemd replaced SysVinit in RHEL 7. It provides parallel startup, on-demand activation, and unified configuration.

systemd is the init system and service manager for RHEL and most modern Linux distributions. When your system boots, the kernel starts systemd as PID 1 - the first process. systemd then starts everything else according to its configuration. systemd handles much more than just starting services. It manages the entire boot process, tracks dependencies between services so they start in the correct order, provides logging through journald, mounts filesystems, manages network configuration, handles user logins, and more. The main components you work with are systemctl for controlling services, journalctl for viewing logs, and unit files that define services. systemd replaced the older SysVinit system starting with RHEL 7. The key improvements include parallel startup (multiple services start simultaneously), on-demand activation (services start when needed), dependency tracking (services wait for their requirements), and unified configuration (one system for services, mounts, timers, etc.).

Services and Daemons

A daemon is a background process that runs continuously. A service in systemd context is a unit that manages a daemon or other background task.

# Common system services (daemons)
sshd.service      - OpenSSH server daemon
httpd.service     - Apache HTTP Server
mariadb.service   - MariaDB database server
crond.service     - Command scheduler
firewalld.service - Dynamic firewall daemon
NetworkManager.service - Network management
chronyd.service   - NTP time synchronization

# List running services
[root@host ~]# systemctl list-units --type=service --state=running
UNIT                      LOAD   ACTIVE SUB     DESCRIPTION
chronyd.service           loaded active running NTP client/server
crond.service             loaded active running Command Scheduler
firewalld.service         loaded active running firewalld
NetworkManager.service    loaded active running Network Manager
sshd.service              loaded active running OpenSSH server daemon

Let me clarify the terminology. A daemon is a background process that runs continuously, waiting to handle requests or perform scheduled tasks. The name comes from Greek mythology - helpful spirits that work in the background. In Unix tradition, daemon names often end in 'd' - sshd, httpd, crond. A service in systemd context is a unit that manages a process, typically a daemon. The service unit file tells systemd how to start the daemon, when to restart it if it fails, what dependencies it has, and more. When you start sshd.service, systemd reads the unit file and starts the sshd daemon according to those instructions. Common services include sshd for remote access, httpd or nginx for web serving, mariadb or postgresql for databases, crond for scheduled tasks, firewalld for the firewall, and NetworkManager for network configuration. The systemctl list-units command shows services that systemd is managing, filtered by type and state.

Understanding Units

Units are resources that systemd manages. Services are the most common, but systemd also manages mounts, timers, sockets, and more.

Unit Type	Extension	Purpose
Service	.service	Manage daemons and processes
Target	.target	Group units, define system states
Socket	.socket	IPC/network socket for on-demand activation
Mount	.mount	Filesystem mount points
Timer	.timer	Scheduled activation (like cron)
Path	.path	File/directory watching
Device	.device	Hardware devices

# List all unit types
[root@host ~]# systemctl list-units --type=help

# List all loaded units
[root@host ~]# systemctl list-units

# List units of specific type
[root@host ~]# systemctl list-units --type=timer

Units are the fundamental resources that systemd manages. While services are the most common, systemd uses a unified approach for managing many types of system resources. Service units manage daemons and processes - this is what we focus on in this module. Target units group other units together and represent system states - like multi-user mode or graphical mode. Socket units define network or IPC sockets. They enable on-demand activation - a service starts only when something connects to its socket. Mount units manage filesystem mount points. They are often generated automatically from /etc/fstab but can be created manually. Timer units provide scheduled activation, similar to cron jobs but integrated with systemd. Path units watch files or directories and activate other units when changes occur. Device units represent hardware devices exposed by the kernel. Each unit type has its own extension - .service, .target, .socket, .mount, .timer. When you specify a unit, you can often omit the extension for services, but being explicit is clearer.

systemctl Basics

systemctl is the primary command for interacting with systemd. It controls services, checks status, and configures boot behavior.

# Basic syntax
systemctl [command] [unit]

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

# The .service extension is optional for services
[root@host ~]# systemctl start httpd
[root@host ~]# systemctl stop httpd

# Check if service is active
[user@host ~]$ systemctl is-active httpd
active

# Check if service is enabled (starts at boot)
[user@host ~]$ systemctl is-enabled httpd
enabled

systemctl is your primary tool for managing systemd. The basic syntax is systemctl followed by a command and a unit name. Start begins a service immediately. The service will run until stopped or until the system shuts down. Stop terminates a running service. The service stops accepting connections and its processes end. Restart stops then starts a service - useful after configuration changes that require a full restart. Reload tells the service to reload its configuration without fully stopping. Not all services support reload - they need to be designed for it. Apache (httpd) supports reload, for example. The .service extension is optional when working with services, so systemctl start httpd and systemctl start httpd.service are equivalent. Most administrators omit it for brevity. is-active checks if a service is currently running. is-enabled checks if it will start automatically at boot. These return simple answers and exit codes suitable for scripting.

Starting and Stopping

# Start a service
[root@host ~]# systemctl start httpd
# No output means success

# Stop a service
[root@host ~]# systemctl stop httpd

# Restart (stop + start)
[root@host ~]# systemctl restart httpd
# Brief interruption while service restarts

# Reload configuration (no restart)
[root@host ~]# systemctl reload httpd
# Service stays running, just rereads config

# Reload if supported, otherwise restart
[root@host ~]# systemctl reload-or-restart httpd

# Conditional restart (only if already running)
[root@host ~]# systemctl try-restart httpd
# Does nothing if service is stopped

# Kill all processes in service (forceful)
[root@host ~]# systemctl kill httpd

reload vs restart: reload keeps the service running (no downtime), but requires service support. restart guarantees config changes take effect.

Let me explain the different control commands in more detail. start brings up a service that is not running. systemd reads the unit file and executes the start command defined there. If successful, there is no output - silence means success. stop shuts down a running service. systemd sends the appropriate signal (usually SIGTERM) and waits for the service to exit. restart is a stop followed by start. There is a brief interruption while the service stops and starts again. Use this when you need to ensure a fresh start. reload tells the service to reread its configuration files without stopping. The service continues running, so there is no interruption. However, not all services support reload - it requires the service to be designed for it. reload-or-restart tries reload first, and if the service does not support it, falls back to restart. This is the safe choice when you are not sure. try-restart only restarts if the service is already running. If it is stopped, it stays stopped. Useful in scripts where you want to refresh running services without starting stopped ones. kill sends signals directly to all processes in the service's control group. More forceful than stop.

Checking Status

systemctl status provides detailed information about a service including its state, recent log entries, and process information.

[root@host ~]# systemctl status sshd
● sshd.service - OpenSSH server daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: enabled)
     Active: active (running) since Mon 2024-01-20 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

Jan 20 09:00:00 host systemd[1]: Starting OpenSSH server daemon...
Jan 20 09:00:00 host sshd[1234]: Server listening on 0.0.0.0 port 22.
Jan 20 09:00:00 host systemd[1]: Started OpenSSH server daemon.

Key fields: Loaded (unit file status), Active (running state), Main PID, Memory usage, and recent journal entries.

systemctl status is your go-to command for understanding what a service is doing. The output is rich with information. The colored dot at the start indicates health - green for active, red for failed, white for inactive. Loaded shows where the unit file is and whether it is enabled for boot. The preset indicates the vendor's default recommendation. Active shows the current state - active (running), inactive (dead), or failed. It includes how long since the state change. Docs points to relevant man pages. Main PID identifies the primary process of the service. Tasks shows how many processes/threads the service has spawned. Memory and CPU show resource usage. CGroup shows the control group hierarchy containing the service's processes. The bottom section shows recent journal entries for this service - log messages that help you understand what happened. This combined view - state, resources, and logs - makes troubleshooting straightforward.

Service States

State	Description
active (running)	Service is running normally
active (exited)	One-shot service completed successfully
active (waiting)	Running but waiting for an event
inactive (dead)	Service is not running
failed	Service attempted to start but failed
activating	Service is starting up
deactivating	Service is shutting down

# Quick state checks (useful for scripting)
[user@host ~]$ systemctl is-active httpd
active

[user@host ~]$ systemctl is-active stopped-service
inactive

[user@host ~]$ systemctl is-failed httpd
active        # "active" means not failed

# Exit codes: 0 = yes (active/enabled/failed), non-zero = no

Services can be in various states, and understanding these helps with troubleshooting. active (running) is the normal state for a daemon - the process is running and handling requests. active (exited) means a one-shot service ran and completed. Some services just do a task and exit rather than running continuously. active (waiting) means the service is running but waiting for something, like a socket activation. inactive (dead) simply means not running. This is normal for services that are stopped. failed means the service tried to start but could not. This requires investigation - check the logs with journalctl. activating and deactivating are transient states during startup and shutdown. The is-active and is-failed commands return simple answers suitable for scripting. They also set exit codes - 0 for yes (active, enabled, or failed depending on the query), non-zero for no. This makes them useful in shell scripts for conditional logic.

Enabling and Disabling

Enable configures a service to start automatically at boot. Disable prevents automatic startup. Neither affects current running state.

# Enable service to start at boot
[root@host ~]# systemctl enable httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service 
  → /usr/lib/systemd/system/httpd.service

# Disable service from starting at boot
[root@host ~]# systemctl disable httpd
Removed /etc/systemd/system/multi-user.target.wants/httpd.service

# Enable does NOT start the service now!
# To enable AND start in one command:
[root@host ~]# systemctl enable --now httpd

# Disable AND stop in one command:
[root@host ~]# systemctl disable --now httpd

# Check enabled status
[user@host ~]$ systemctl is-enabled httpd
enabled

Important: enable/disable control boot behavior only. Use start/stop to control current state. Use --now to do both.

Enable and disable control whether services start automatically at boot - they do not affect the current running state. This is a common point of confusion. When you enable a service, systemd creates a symbolic link in the appropriate target's wants directory. This link tells systemd to start the service when that target is reached during boot. When you disable, systemd removes that link. The service will not start automatically, but you can still start it manually. A very common workflow is enabling and starting together. The --now flag combines both operations. systemctl enable --now httpd enables the service for boot AND starts it immediately. Similarly, disable --now stops the service and prevents it from starting at next boot. is-enabled tells you the boot configuration. Possible answers are enabled, disabled, static (no install section, cannot be enabled directly), or masked (forcefully disabled).

Masking Services

Masking completely disables a service - it cannot be started even manually. Use this to prevent a service from running under any circumstances.

# Mask a service (completely disable)
[root@host ~]# systemctl mask httpd
Created symlink /etc/systemd/system/httpd.service → /dev/null

# Try to start masked service - fails
[root@host ~]# systemctl start httpd
Failed to start httpd.service: Unit httpd.service is masked.

# Check status shows masked
[root@host ~]# systemctl status httpd
○ httpd.service
     Loaded: masked (Reason: Unit httpd.service is masked.)
     Active: inactive (dead)

# Unmask to allow starting again
[root@host ~]# systemctl unmask httpd
Removed /etc/systemd/system/httpd.service

Use case: Mask services that conflict with others, or services you want to ensure never run on this system.

Masking is stronger than disabling. A disabled service will not start at boot, but you can still start it manually. A masked service cannot start at all - systemd refuses to start it. Masking works by creating a symbolic link to /dev/null. When systemd tries to read the unit file, it gets nothing. The service effectively does not exist. Use masking when you need to absolutely prevent a service from running. Common scenarios include services that conflict with each other (only one should ever run), services that are dangerous in your environment, or during maintenance when you need to guarantee something stays off. Always unmask before trying to start or enable the service again. systemctl unmask removes the /dev/null link, restoring access to the original unit file. Note that mask/unmask only affects the local system configuration. The original unit file in /usr/lib/systemd/system remains unchanged.

Listing Services

# List all loaded units
[root@host ~]# systemctl list-units

# List only services
[root@host ~]# systemctl list-units --type=service

# List running services
[root@host ~]# systemctl list-units --type=service --state=running

# List failed services
[root@host ~]# systemctl list-units --type=service --state=failed
UNIT           LOAD   ACTIVE SUB    DESCRIPTION
httpd.service  loaded failed failed Apache HTTP Server

# List all installed unit files (not just loaded)
[root@host ~]# systemctl list-unit-files --type=service
UNIT FILE                  STATE    PRESET
httpd.service              disabled disabled
sshd.service               enabled  enabled
chronyd.service            enabled  enabled

# Show enabled services
[root@host ~]# systemctl list-unit-files --type=service --state=enabled

systemctl provides various listing commands to see what is running and what is available. list-units shows currently loaded units - things systemd is actively managing. Add --type=service to see only services. You can filter by state to find running services, failed services, or any other state. list-units only shows loaded units. If a service is not running and not enabled, it may not appear. For a complete picture, use list-unit-files. list-unit-files shows all installed unit files, regardless of whether they are currently loaded. The STATE column shows enabled, disabled, static, or masked. PRESET shows the vendor's default recommendation. Combining --state with list-unit-files lets you find all enabled services, all disabled services, and so on. This is useful for auditing what will start at boot. These listing commands are essential for understanding your system's service configuration.

Viewing Service Logs

journalctl views logs from systemd's journal. Filter by unit to see logs for a specific service.

# View logs for a specific service
[root@host ~]# journalctl -u sshd
Jan 20 09:00:00 host systemd[1]: Starting OpenSSH server daemon...
Jan 20 09:00:00 host sshd[1234]: Server listening on 0.0.0.0 port 22.
Jan 20 09:00:01 host sshd[1234]: Server listening on :: port 22.
Jan 20 09:00:01 host systemd[1]: Started OpenSSH server daemon.

# Follow logs in real-time (like tail -f)
[root@host ~]# journalctl -u httpd -f

# Show logs since last boot
[root@host ~]# journalctl -u httpd -b

# Show recent logs (last 50 lines)
[root@host ~]# journalctl -u httpd -n 50

# Show logs from specific time period
[root@host ~]# journalctl -u httpd --since "2024-01-20 09:00" --until "2024-01-20 12:00"

# Show only errors and above
[root@host ~]# journalctl -u httpd -p err

journalctl is the tool for viewing systemd's journal - the centralized log system. The -u option filters by unit, so you see only logs from that service. This is cleaner than grepping through /var/log files. The -f option follows the log in real-time, like tail -f. Essential for watching what happens when you start a service or when troubleshooting. The -b option shows logs since the last boot, filtering out historical data from previous boots. The -n option limits output to a specific number of recent entries. --since and --until filter by time, useful for investigating issues that occurred during a specific window. The -p option filters by priority (severity). Priority levels are emerg, alert, crit, err, warning, notice, info, debug. Using -p err shows only errors and more severe messages, cutting through the noise. Combining these options - for example, journalctl -u httpd -p err -b - gives you errors from httpd since last boot.

Troubleshooting Failures

# Check for failed services
[root@host ~]# systemctl --failed
UNIT           LOAD   ACTIVE SUB    DESCRIPTION
httpd.service  loaded failed failed Apache HTTP Server

# Get detailed status
[root@host ~]# systemctl status httpd
× httpd.service - Apache HTTP Server
     Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled)
     Active: failed (Result: exit-code) since Mon 2024-01-20 10:30:00
    Process: 5678 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
   Main PID: 5678 (code=exited, status=1/FAILURE)

Jan 20 10:30:00 host httpd[5678]: AH00558: httpd: Could not determine server's FQDN
Jan 20 10:30:00 host httpd[5678]: (98)Address already in use: AH00072: make_sock: could not bind

# View detailed logs
[root@host ~]# journalctl -xeu httpd
# -x adds explanatory messages, -e jumps to end

# Reset failed state after fixing
[root@host ~]# systemctl reset-failed httpd

Common causes: Configuration errors, port conflicts, missing dependencies, permission issues, resource exhaustion.

When services fail, systemd provides good diagnostic information. Start with systemctl --failed to see all failed services. The status output for a failed service shows the failure result and exit code. The log entries at the bottom often contain the specific error message explaining why it failed. In the example, Apache failed because the port was already in use - another process is listening on port 80. journalctl -xeu adds extra context. The -x flag includes explanatory messages from the systemd catalog, -e jumps to the end of the log, and -u filters to the specific unit. Common failure causes include configuration syntax errors (test configs before restarting), port conflicts (check with ss -tlnp), missing files or permissions, insufficient resources (disk space, memory), and dependency services not running. After fixing the issue and successfully starting the service, systemctl reset-failed clears the failed state from systemd's records.

Understanding Targets

Targets are groups of units that represent system states. They replace the runlevels from SysVinit and define what services run at each stage of boot.

Target	Old Runlevel	Description
poweroff.target	0	System shutdown
rescue.target	1	Single-user rescue mode
multi-user.target	3	Multi-user, no GUI (servers)
graphical.target	5	Multi-user with GUI (workstations)
reboot.target	6	System reboot
emergency.target	-	Minimal emergency shell

# View current default target
[root@host ~]# systemctl get-default
multi-user.target

# Set default target
[root@host ~]# systemctl set-default graphical.target
Removed /etc/systemd/system/default.target
Created symlink /etc/systemd/system/default.target → /usr/lib/.../graphical.target

Targets are systemd's replacement for SysVinit runlevels. A target is a unit that groups other units together, representing a system state. When systemd reaches a target, all units required by that target are started. poweroff.target and reboot.target are for shutdown and restart. rescue.target provides a single-user environment for maintenance - only essential services run. multi-user.target is the standard for servers - full multi-user networking, but no graphical interface. graphical.target adds the GUI on top of multi-user, used for workstations. emergency.target is even more minimal than rescue - a bare shell with almost nothing running. The default target determines what state the system boots into. Servers typically use multi-user.target, workstations use graphical.target. systemctl get-default shows the current default, and set-default changes it. The default target is just a symbolic link at /etc/systemd/system/default.target.

Changing System State

# Switch to different target immediately
[root@host ~]# systemctl isolate multi-user.target
# Stops graphical services, switches to text mode

[root@host ~]# systemctl isolate graphical.target
# Starts graphical services

# Rescue mode (single-user, for maintenance)
[root@host ~]# systemctl isolate rescue.target

# Emergency mode (minimal, for serious recovery)
[root@host ~]# systemctl isolate emergency.target

# Equivalent convenient commands
[root@host ~]# systemctl rescue      # Same as isolate rescue.target
[root@host ~]# systemctl emergency   # Same as isolate emergency.target

# Reboot and shutdown
[root@host ~]# systemctl reboot
[root@host ~]# systemctl poweroff
[root@host ~]# systemctl halt

Note: isolate switches to a target, stopping services not needed by the new target. This can disrupt users!

You can switch between targets on a running system using systemctl isolate. Isolate stops all units not required by the target and starts any units required by the target that are not already running. Switching from graphical.target to multi-user.target stops the display manager and all graphical applications. This logs out users at the GUI. Use with caution in production. rescue.target drops to a single-user shell with minimal services. Use for system maintenance when you need to prevent other users from interfering. emergency.target is even more minimal - just a shell with the root filesystem. Use for serious recovery situations. Convenient shorthand commands exist for common operations. systemctl rescue and systemctl emergency are equivalent to isolating those targets. systemctl reboot, poweroff, and halt do what their names suggest. These can also be done with traditional commands like shutdown and reboot, which now call systemctl.

Service Dependencies

Services can depend on other services. systemd tracks these dependencies and starts services in the correct order.

# Show what a service requires
[root@host ~]# systemctl list-dependencies httpd
httpd.service
● ├─system.slice
● ├─httpd-init.service
● └─sysinit.target
●   ├─dev-hugepages.mount
●   ├─dev-mqueue.mount
●   ...

# Show reverse dependencies (what requires this service)
[root@host ~]# systemctl list-dependencies httpd --reverse

# Show dependencies of a target
[root@host ~]# systemctl list-dependencies multi-user.target

# View unit file to see dependency configuration
[root@host ~]# systemctl cat httpd
[Unit]
Description=Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
Wants=httpd-init.service
...

systemd tracks dependencies between units and uses them to determine start order and requirements. list-dependencies shows what a unit requires - other units that must be present for this one to work. The tree view shows the dependency chain. The --reverse option shows the opposite - what depends on this unit. Useful for understanding the impact of stopping a service. Dependencies are defined in unit files using directives like Requires (hard dependency - if the required unit fails, this one fails too), Wants (soft dependency - start if available but do not fail if not), After (ordering - wait for these units to start first), and Before (ordering - start before these units). When you start httpd, systemd reads these dependencies, starts required units first, waits for After units, then starts httpd. This automatic dependency handling is a key benefit of systemd over older init systems.

Unit Files

Unit files define how systemd manages a service. They contain configuration for startup, dependencies, and behavior.

# Unit file locations (in priority order)
/etc/systemd/system/    - Local administrator configuration (highest priority)
/run/systemd/system/    - Runtime generated units
/usr/lib/systemd/system/ - Package-installed units (vendor)

# View a unit file
[root@host ~]# systemctl cat sshd.service
[Unit]
Description=OpenSSH server daemon
After=network.target sshd-keygen.target
Wants=sshd-keygen.target

[Service]
Type=notify
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target

Never edit files in /usr/lib/systemd/system/ - they are overwritten on updates. Copy to /etc/systemd/system/ first.

Unit files are INI-style configuration files that tell systemd how to manage a unit. Understanding their structure helps with troubleshooting and customization. Unit files live in specific directories with a priority order. /etc/systemd/system has the highest priority - administrator customizations go here. /run/systemd/system holds runtime-generated units. /usr/lib/systemd/system contains vendor-provided files from packages. systemctl cat shows the unit file contents and indicates where it came from. Unit files have sections in brackets. [Unit] contains description and dependencies. [Service] defines how to start, stop, and monitor the service - the ExecStart line is the actual command. [Install] defines what happens when the unit is enabled - WantedBy says which target should pull in this service. Never edit files in /usr/lib/systemd/system directly - package updates overwrite them. Instead, copy to /etc/systemd/system and edit there, or use drop-in files.

Modifying Unit Files

# Edit unit file (creates drop-in override automatically)
[root@host ~]# systemctl edit httpd
# Opens editor for /etc/systemd/system/httpd.service.d/override.conf

# Example: Add environment variable
[Service]
Environment="OPTIONS=-DFOREGROUND"

# Edit full unit file (copy original to /etc/systemd/system/)
[root@host ~]# systemctl edit --full httpd

# After editing, reload systemd configuration
[root@host ~]# systemctl daemon-reload
# Then restart the service for changes to take effect
[root@host ~]# systemctl restart httpd

# View all files affecting a unit
[root@host ~]# systemctl cat httpd
# Shows base file plus any drop-in overrides

# Revert to vendor unit file (remove local changes)
[root@host ~]# systemctl revert httpd

Always run: systemctl daemon-reload after modifying unit files, then restart the service.

When you need to customize a service, systemctl edit is the proper method. It creates a drop-in override file that only contains your changes. The original vendor file remains untouched, making upgrades safe. Drop-in files go in a .d directory named after the unit - httpd.service.d for httpd.service. Files inside override or add to the base unit file. systemctl edit --full copies the entire unit file to /etc/systemd/system for complete replacement. Use this when you need to make extensive changes. After modifying unit files, always run systemctl daemon-reload. This tells systemd to reread its configuration. Without this, changes are not recognized. Then restart the service for the new configuration to take effect. systemctl cat shows all files affecting a unit - the base file and any drop-ins - so you can see the complete effective configuration. systemctl revert removes local customizations, returning to the vendor configuration.

Best Practices

Do

Check status before and after changes
Use enable --now to enable and start
Use systemctl edit for customizations
Run daemon-reload after unit changes
Check logs when services fail
Test configuration before restart
Document service customizations
Understand dependencies before stopping

Do Not

Edit files in /usr/lib/systemd/system/
Forget daemon-reload after changes
Ignore failed services
Stop critical services without planning
Assume enable starts the service
Skip status checks in scripts
Mask services without documentation
Restart when reload would work

Troubleshooting workflow: status → logs (journalctl) → dependencies → unit file → fix → daemon-reload → restart → status

Let me share best practices for managing systemd services. Always check status before and after making changes. This confirms the current state and verifies your changes worked. Use enable --now when you want a service to both start now and start at boot - it is cleaner than two commands. Use systemctl edit for customizations rather than editing vendor files. This keeps your changes safe during upgrades and makes them easier to track. Always run daemon-reload after modifying unit files. Always check logs with journalctl when services fail - the answer is usually there. Test service configurations before restarting - most services have a config test option. Document why you masked services or made customizations - your future self will thank you. Do not edit files in /usr/lib/systemd/system. Do not forget daemon-reload. Do not ignore failed services - they often indicate real problems. Do not stop critical services without understanding what depends on them. Remember that enable does not start - use --now. Prefer reload over restart when possible for less disruption.

Key Takeaways

systemd: Init system managing services, mounts, targets. PID 1 on modern Linux. Controls the entire system lifecycle.

Control: systemctl start|stop|restart|reload controls running state. enable|disable controls boot behavior.

Monitor: systemctl status shows state and logs. journalctl -u shows full service logs.

Targets: System states like multi-user.target, graphical.target. set-default configures boot target.

Let me summarize the key points about systemd services. systemd is the init system and service manager for RHEL. As PID 1, it starts at boot and manages everything else. It handles services, mounts, timers, and system state through a unified architecture. For control, systemctl is your primary tool. start, stop, restart, and reload manage running state. enable and disable control boot behavior - remember, enable does not start the service, so use --now if you want both. For monitoring, systemctl status provides a quick overview with state, PID, resource usage, and recent logs. journalctl -u gives you full access to all logs for a service with powerful filtering options. Targets represent system states. multi-user.target for servers, graphical.target for workstations. set-default configures what target the system boots into.

LAB EXERCISES

Install and start a web server service (httpd)
Enable the service to start at boot
Check service status and view recent logs
Stop, restart, and reload the service
Intentionally break the config, observe failure, fix it
Create a drop-in override to customize the service
List all enabled services on the system

Next: Introduction to Networking