OS Mastery Simple OS learning for a global audience Start Here

LAB-PROC-05 - Service Persistence: systemd

Understand what systemd is responsible for and practice basic service inspection before attempting custom service creation.

PS Process Management

Service Persistence: systemd

Understand what systemd is responsible for and practice basic service inspection before attempting custom service creation.

40 min ADVANCED LINUX
Before this lab
Lab LAB-PROC-01 - The Process Lifecycle Lab LAB-PROC-04 - Foreground and Background Jobs
What success looks like
  • Understand what systemd is responsible for and practice basic service inspection before attempting custom service creation.
  • Repeat the workflow without copy-paste or step-by-step prompting.
Safety notes
  • Double-check process IDs and commands before stopping anything outside the lab scenario.

Part A: The Field Guide

A service manager exists so important background programs are not left to luck.

Compared with a manual process, a service can be:

  • started in a standard way
  • monitored by a supervisor
  • restarted when appropriate
  • enabled to start on boot
  • tied into a central logging system

On most modern Linux systems, that service manager is systemd.

Beginner Rule

Inspect existing services first. Build custom service files later, and only on a training machine or VM.

Part B: The Drill Deck

Terminal required: this lab is inspection-first.

G
Guided Step by step - type exactly this and compare the result
>

Exercise G1: Inspect one known service

  1. Run systemctl status ssh or systemctl status cron or another common local service
  2. Look for whether it is active or inactive
  3. Notice that systemctl status also shows recent log lines
  4. Quit the view with q if needed

Exercise G2: Compare start and enable conceptually

Explain the difference:

  1. start means run now
  2. enable means configure it to start at boot

You do not need to change real service settings yet to understand the distinction.

Exercise G3: Inspect the journal for one service

  1. Run journalctl -u ssh --no-pager | tail -n 10
  2. If your system uses a different service name, substitute accordingly
  3. Notice how service logs can be read from the journal
S
Solo Task described, hints available - figure it out
>

Exercise S1: Find the unit file path

  1. Run systemctl status on a known service
  2. Look for the Loaded: line
  3. Note where the unit file is coming from

Exercise S2: Think through the service-manager advantage

In your own words, explain why tmux and nohup are still not the same thing as a supervised service managed by systemd.

M
Mission Real scenario - no hints, combine multiple skills
>

Mission M1: Plan, do not rush

Describe the safe sequence you would follow before creating a custom service on a real machine:

  1. test the command manually first
  2. confirm the correct user and working directory
  3. write the unit on a training system
  4. reload systemd and inspect status carefully
  5. only then consider enabling it

If that sequence makes sense, you are learning service persistence responsibly.

What to do next

Best next step Learning

Return to the related lesson if you want the concept explained more deeply.

Open now
Troubleshooting

Use problem-first help when this lab maps to a real issue.

Open now Reference

Look up commands, topics, and tasks while you practice.

Open now