Linux Mastery

The Human Knowledge Project

Chapter 16 — Services, Boot & systemd

Why This Chapter Matters

Modern Linux systems perform an enormous amount of work automatically behind the scenes.

When Linux starts, it must:

All of these tasks occur before you begin using the computer.

On most modern Linux distributions, they are coordinated by a system called systemd.

Understanding services, daemons, the Linux boot process, and systemd is essential for Linux administration and troubleshooting.

Learning Objectives

Upon completing this chapter, you will be able to:

Introduction

When you press the power button, your computer does far more than simply "start Linux."

Hundreds of individual tasks occur in a carefully organized sequence.

Hardware is initialized.

The operating system loads.

Background services begin running.

Networking becomes available.

Finally, the login screen appears.

Most users never see these steps, yet every Linux system depends on them.

Understanding this startup process makes troubleshooting much easier and provides a deeper understanding of how Linux works.

1. What Happens During Boot?

Starting a Linux system is called booting.

During boot, Linux progresses through several stages before presenting a login prompt.

A simplified boot sequence looks like this:


BIOS / UEFI
      ↓
Bootloader
      ↓
Linux Kernel
      ↓
systemd
      ↓
Services
      ↓
Login

THKI Memory Aid


Power On
      ↓
BIOS / UEFI
      ↓
Bootloader
      ↓
Linux Kernel
      ↓
systemd
      ↓
Services
      ↓
Login

Each stage prepares the next until the operating system is fully operational.

2. The Role of systemd

On most modern Linux distributions, the initialization system is:


systemd

Once the Linux kernel finishes loading, it starts systemd.

From that point forward, systemd becomes responsible for bringing the operating system into a usable state.

It manages:

Because so many parts of Linux depend upon it, systemd is one of the most important components of a modern Linux system.

THKI Insight

Most Linux users interact with systemd every day without realizing it.

Every time your computer starts, systemd quietly launches the services that make the operating system usable.

3. Why systemd Exists

Earlier Linux systems used initialization systems such as:

As Linux grew more sophisticated, operating systems required:

systemd was designed to address these needs by providing one consistent framework for managing the entire startup process.

4. What Is a Service?

A service is a program that runs in the background to provide functionality for the operating system.

Examples include:

Many services begin automatically during the boot process and continue running until the computer shuts down.

Without these services, much of Linux would simply not function.

5. What Is a Daemon?

A daemon is a background program that operates without direct user interaction.

Examples include:

In everyday Linux usage, the terms daemon and service are often used interchangeably.

A daemon performs work quietly in the background while users interact with the system normally.

6. Why Daemons Matter

Daemons allow Linux to perform continuous work even when no user is actively interacting with the computer.

Examples include:

Without daemons, Linux would require constant user intervention to perform routine system tasks.

7. Viewing Running Services

To display active services:


systemctl list-units --type=service

This command displays services currently managed by systemd.

Depending on your system, the list may contain hundreds of entries.

Viewing this list gives you an appreciation for how much work Linux performs automatically behind the scenes.

8. systemctl — Controlling Services

The primary command used to manage services under systemd is:


systemctl

It allows administrators to:

Learning systemctl is one of the most important Linux administration skills.

9. Viewing Service Status

To display information about a service:


systemctl status ssh

Typical information includes:

This is often the first command administrators use when troubleshooting a service.

10. Starting, Stopping, and Restarting Services

To start a service immediately:


sudo systemctl start ssh

To stop a running service:


sudo systemctl stop ssh

To restart a service:


sudo systemctl restart ssh

Some services can reload their configuration without fully restarting.

Example:


sudo systemctl reload ssh

Reloading is often faster and avoids interrupting active users.

11. Starting Services Automatically

Some services should begin every time Linux boots.

Enable automatic startup:


sudo systemctl enable ssh

Disable automatic startup:


sudo systemctl disable ssh

Enabling a service does not necessarily start it immediately.

It simply tells Linux to start the service automatically during future boots.

THKI Memory Aid


start
      ↓
Run Now
stop
      ↓
Stop Now
restart
      ↓
Stop + Start
enable
      ↓
Start at Boot
disable
      ↓
Do Not Start at Boot

Remember:

12. Checking Service Status

To determine whether a service is currently running:


systemctl is-active ssh

To determine whether it is configured to start automatically during boot:


systemctl is-enabled ssh

These commands provide quick answers without displaying the detailed output of systemctl status.

13. Unit Files

systemd manages many different types of resources called units.

Common unit types include:

| Unit Type | Purpose |

|-----------|---------|

| service | Background services |

| target | Operating states |

| mount | Mounted filesystems |

| timer | Scheduled tasks |

Most administrators work primarily with service units.

14. Unit File Locations

Service definitions are stored in unit files.

Common locations include:


/etc/systemd/system/

and:


/usr/lib/systemd/system/

To examine a unit file:


less /usr/lib/systemd/system/ssh.service

These files describe how services start, stop, and interact with other system components.

15. Boot Targets

systemd uses targets to represent different operating states.

Targets replace the older Linux concept of runlevels.

Common targets include:

| Target | Purpose |

|---------|---------|

| graphical.target | Graphical desktop |

| multi-user.target | Multi-user text mode |

| rescue.target | Repair and recovery |

| reboot.target | Restart the system |

Targets determine which services Linux starts during boot.

16. Viewing and Changing the Default Target

To display the default startup target:


systemctl get-default

To change it:


sudo systemctl set-default multi-user.target

Changing the default target changes how Linux starts the next time the computer boots.

17. Graphical and Text Modes

A graphical target starts:

A multi-user target normally starts:

without launching a desktop environment.

Servers commonly use the multi-user target because they do not require a graphical interface.

18. Rescue Mode

Sometimes Linux must start with only minimal services.

This special operating state is called:


rescue mode

Rescue mode is useful for:

Because only essential services are loaded, rescue mode provides a controlled environment for system repair.

19. journalctl — Viewing System Logs

Modern Linux systems use a centralized logging system called the system journal.

The primary command for viewing these logs is:


journalctl

The system journal records information from:

Because so much information is recorded, the journal is one of the first places administrators look when troubleshooting problems.

THKI Insight

Experienced Linux administrators rarely guess why something failed.

They consult the system logs first.

20. Viewing Journal Entries

Display the entire system journal:


journalctl

Large systems may contain thousands of log entries.

To display only the most recent entries:


journalctl -n 50

This displays the last 50 log messages.

To follow new log entries as they occur:


journalctl -f

This behaves much like:


tail -f

and is useful when monitoring a system in real time.

21. Viewing Logs for Individual Services

To display log messages for a specific service:


journalctl -u ssh

To display only messages from the current boot:


journalctl -b

Filtering logs in this way makes troubleshooting much faster than searching through the entire system journal.

22. Why Logs Matter

System logs help administrators diagnose:

Nearly every Linux troubleshooting session eventually involves reading log files.

23. Analyzing Boot Performance

systemd can measure how long the system takes to boot.

Display overall boot timing:


systemd-analyze

Display the slowest startup services:


systemd-analyze blame

These commands help identify services that delay system startup.

Administrators often use them when optimizing boot performance.

24. Failed Services

To display services that failed to start:


systemctl --failed

This command quickly identifies problems that might otherwise be difficult to locate.

It is one of the first commands many administrators run after an unsuccessful boot or service failure.

25. Rebooting and Shutting Down

Restart the system:


sudo reboot

Shut the system down immediately:


sudo shutdown now

Schedule a shutdown in ten minutes:


sudo shutdown +10

These commands allow administrators to manage system power safely and predictably.

26. Why systemd Is Sometimes Controversial

Although systemd is used by most modern Linux distributions, it has also generated discussion within the Linux community.

Supporters appreciate:

Critics argue that it:

Regardless of these opinions, understanding systemd is an essential Linux administration skill.

27. Real-World Administrative Workflow

A Linux administrator might routinely:

A typical workflow might look like this:

Check for failed services:


systemctl --failed

Review recent log messages:


journalctl -xe

Restart the affected service:


sudo systemctl restart service_name

This systematic approach is far more effective than simply guessing at the cause of a problem.

28. Safety Note

Services are part of the operating system's infrastructure.

Changing startup targets or disabling important services can:

Before changing critical services, understand what they do and why they are running.

Chapter Summary

| Command / Concept | Purpose |

|-------------------|---------|

| systemd | Initialization and service manager |

| systemctl | Manage services and system targets |

| Service | Background program providing system functionality |

| Daemon | Background process |

| journalctl | View the system journal |

| Target | Operating state managed by systemd |

| systemd-analyze | Analyze boot performance |

Key Ideas

Modern Linux systems depend heavily on background services.

Understanding:

provides the foundation for effective Linux troubleshooting and administration.

Many Linux problems can be solved by examining service status and reading the system logs.

Practice Exercises

  1. Display all running services.
  2. Check the status of a service.
  3. Start and stop a service (if permitted).
  4. Restart a service.
  5. Enable a service at boot.
  6. Disable a service.
  7. Determine whether a service is active.
  8. Determine whether a service is enabled.
  9. Display the default boot target.
  10. Compare graphical.target and multi-user.target.
  11. View the system journal.
  12. Display the last 50 journal entries.
  13. Follow the journal in real time.
  14. Display logs from the current boot.
  15. Display logs for a specific service.
  16. List failed services.
  17. Analyze boot performance.
  18. Display the slowest startup services.
  19. Explain the difference between a service, a daemon, and a process.
  20. Describe a troubleshooting workflow using:
  1. Explain why Linux depends on background services.
  2. Describe the purpose of rescue mode.
  3. Explain why system logs are essential for troubleshooting.
  4. Describe a real-world problem caused by a failed service.

Looking Ahead

You now understand how Linux starts, manages services, and records system activity.

In the next chapter, you will learn how Linux schedules work to occur automatically using jobs, timers, and task scheduling—allowing the operating system to perform routine work even when no one is logged in.