Kahibaro
Discord Login Register ☰
☰
Previous
Up
Next

Systemd and Service Management

Table of Contents

Overview

Systemd is the default init system and service manager on most modern Linux distributions. In this chapter you’ll learn how systemd fits into the system, what kinds of units it manages, how to interact with services, and how typical tasks like enabling, disabling, and troubleshooting services work in practice.

You’ll use systemctl and journalctl a lot in later chapters, so the goal here is to make you comfortable with the basic concepts and day‑to‑day commands.

Systemd in the System

At a high level:

You do not need to fully understand the boot process yet; focus on how systemd exposes a uniform interface to manage system components.

Units: The Building Blocks of systemd

Systemd manages units. Each unit is a configuration file that describes something systemd controls.

Common unit types you’ll see:

Unit file names follow the pattern:

You interact with them using systemctl.

Common Unit Locations

You’ll encounter unit files in three main locations:

Systemd merges these, with priority:

  1. /etc/systemd/system (highest)
  2. /run/systemd/system
  3. /usr/lib/systemd/system or /lib/systemd/system

Using `systemctl` for Day-to-Day Management

systemctl is the primary command-line tool for interacting with systemd.

General structure:

You’ll often use it with root privileges (sudo), especially when changing system state.

Listing and Inspecting Units

List all loaded units: 

systemctl list-units

List only services: 

systemctl list-units --type=service

List all unit files (including disabled, static, not loaded at runtime): 

systemctl list-unit-files
systemctl list-unit-files --type=service

Check status of a specific service: 

systemctl status sshd.service

You can usually omit the .service suffix: 

systemctl status sshd

The status output typically shows:

Starting, Stopping, Restarting Services

These actions affect the current session only (not whether it starts at boot): 

  sudo systemctl start nginx
  sudo systemctl stop nginx
  sudo systemctl restart nginx
  sudo systemctl reload nginx
  sudo systemctl reload-or-restart nginx

Check results with: 

systemctl status nginx

Enabling and Disabling at Boot

These control whether a service starts automatically when the system reaches certain boot targets: 

  sudo systemctl enable nginx
  sudo systemctl enable --now nginx
  sudo systemctl disable nginx
  sudo systemctl disable --now nginx

Note “enable” usually creates symlinks in /etc/systemd/system/ pointing to the main unit file.

Checking and Changing the Default Target (Boot State)

A target describes a collection of units that define a system state, such as:

View current default target: 

systemctl get-default

Set default (what the system aims for at boot): 

sudo systemctl set-default graphical.target
sudo systemctl set-default multi-user.target

Switch to a different target immediately (similar to changing runlevels): 

sudo systemctl isolate multi-user.target

Be cautious with isolate on remote systems; you can lock yourself out if you stop network or SSH services.

Understanding Service States

A service can be:

Check: 

systemctl is-active sshd
systemctl is-enabled sshd
systemctl is-failed

These commands are useful in scripts to make decisions based on service state.

Basic Troubleshooting of Services

When a service misbehaves, you usually:

  1. Check its status.
  2. Inspect the logs.
  3. Try to (re)start it.
  4. If needed, edit the unit or associated config files.

Checking Status and Recent Logs

Status includes logs, but often you’ll want more: 

sudo systemctl status nginx

Get only recent logs for a service: 

sudo journalctl -u nginx

Follow logs in real time: 

sudo journalctl -u nginx -f

Limit by time: 

sudo journalctl -u nginx --since "10 minutes ago"
sudo journalctl -u nginx --since yesterday

Look for errors or misconfigurations reported by the program itself.

Restarting and Analyzing Failures

Try restart: 

sudo systemctl restart nginx
sudo systemctl status nginx

If the service is failed, systemd often prints:

If a unit file was modified or newly created, reload systemd’s view of unit files: 

sudo systemctl daemon-reload

This does not restart services; it only reloads configuration into systemd.

Anatomy of a Service Unit File

Service units typically live under:

View a unit file as systemd sees it: 

systemctl cat nginx.service

A typical service unit: 

[Unit]
Description=My Example Service
After=network.target
[Service]
Type=simple
User=www-data
Group=www-data
ExecStart=/usr/bin/my-service --option
Restart=on-failure
[Install]
WantedBy=multi-user.target

Important sections:

While a later subsection will cover “Creating custom services” in depth, you should recognize these fields when reading unit files.

Working With Configuration Overrides

Instead of editing packaged unit files directly, systemd supports drop-in overrides.

Create an override for a service: 

sudo systemctl edit sshd

This opens an editor and creates:

You might, for example, add environment variables or change limits: 

[Service]
Environment="MY_FLAG=1"

After saving: 

sudo systemctl daemon-reload
sudo systemctl restart sshd

View the resulting merged configuration: 

systemctl cat sshd

You’ll see the original unit plus the drop-in file at the bottom.

Socket-Activated Services (Conceptual Overview)

Some services are started on demand when there’s network or socket activity. Systemd supports this via .socket units.

At a high level:

You interact with socket units similarly to services: 

systemctl list-units --type=socket
systemctl status systemd-journald.socket

The details of writing socket-activated services are more advanced and usually covered after you’re familiar with basic service units.

Timers vs cron (High-Level)

Systemd timer units are another way to schedule tasks (similar to cron), often preferred on systemd-based systems because:

Interaction is analogous to services: 

systemctl list-timers
systemctl status my-backup.timer

You’ll learn how to create timers later; here you just need to know they exist and are managed with systemctl like other units.

Practical Examples

Below are a few practical patterns you’ll use repeatedly as an administrator.

Example: Ensuring a Critical Service Is Running and Enabled

Check if sshd is running and enabled at boot: 

systemctl is-active sshd
systemctl is-enabled sshd

If not: 

sudo systemctl enable --now sshd

Example: Quickly Inspecting a Newly Installed Service

After installing, say, apache2 or httpd: 

systemctl status httpd
systemctl list-unit-files | grep httpd
sudo journalctl -u httpd --since "5 minutes ago"

Then enable and start: 

sudo systemctl enable --now httpd

Example: Temporarily Stopping a GUI to Troubleshoot

Switch to multi-user (text-only) target: 

sudo systemctl isolate multi-user.target

When done, return to graphical: 

sudo systemctl isolate graphical.target

Don’t do this on remote machines unless you know how you’ll get back in.

Summary

In this chapter you:

These commands and concepts are core to everyday Linux administration, and you’ll use them repeatedly in later chapters on service management, logging, backups, and security.

What is systemd?
Managing services (systemctl)
Boot targets
System logs (journalctl)
Creating custom services
Previous
Up
Next

Views: 32

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro

Visitors: 1539 / 24h

Impressum / Imprint

Datenschutz / Data Policy