systemctl and systemd

A deep section in How Computers Actually Work. This page follows a real Linux command from the shell into systemd, then toward process creation and service management.

Anchor

systemctl is a command-line client. It does not directly start or stop services. Instead, it sends requests to systemd, the system manager.

Reality Hook: When you type systemctl start nginx, you are not personally starting nginx. You are asking systemd to start it according to its unit file, dependencies, and service rules.

The Command Path

You type: systemctl start nginx ↓ Your shell finds /usr/bin/systemctl ↓ The kernel runs systemctl as a process ↓ systemctl sends a request to systemd ↓ systemd reads the unit definition ↓ systemd checks dependencies and policy ↓ systemd launches the service ↓ fork() / exec() create the running program

The visible command is short. The hidden activity is layered. The system moves from user request, to client process, to system manager, to unit logic, to process creation.

systemctl Is a Client

A useful way to think about systemctl is as a remote control. It talks to systemd, asks for information, or requests an action.

systemctl status nginx asks systemd for service state.
systemctl start nginx asks systemd to start a service.
systemctl stop nginx asks systemd to stop a service.
systemctl enable nginx asks systemd to configure startup behavior.

In each case, systemctl is not the long-running manager. It is the short-lived command that makes a request and exits.

systemd Is the Manager

systemd runs as PID 1, the first user-space process started by the Linux kernel. Because of that role, it becomes responsible for starting, supervising, and organizing much of the rest of the system.

It tracks service state.
It starts services in dependency order.
It watches processes it launches.
It records failures and exit status.
It can restart services according to policy.

Key Insight: systemctl is the request. systemd is the decision-maker.

Unit Files

systemd uses unit files to describe what a service is and how it should behave. A service unit may define what program to run, what must start first, and what should happen if the service fails.

[Unit]
Description=Example Web Service
After=network.target

[Service]
ExecStart=/usr/sbin/nginx
Restart=on-failure

[Install]
WantedBy=multi-user.target

The important line here is ExecStart. That is the program systemd eventually launches when the service starts.

What Happens During start

When systemd receives a start request, it does not simply run a binary immediately. It evaluates the unit and its context.

Is the unit file loaded?
Is the service already running?
Are dependencies satisfied?
Does ordering require another target or service first?
What command is defined by ExecStart?

After that, systemd uses normal Linux process creation mechanisms to launch the service.

Where fork() and exec() Enter

At the bottom of the systemd action is ordinary Linux execution:

fork() creates a new process.
exec() replaces that process with the service program.

systemd │ ├── prepares service environment │ ├── fork() │ creates child process │ └── exec() loads service binary such as /usr/sbin/nginx

That is the moment a service stops being a file on disk and becomes a live running process.

Try This

Check service state:

systemctl status sshd

or:

systemctl status nginx

List running services:

systemctl list-units --type=service --state=running

Inspect a unit file:

systemctl cat sshd

or:

systemctl cat nginx

Look for the service process:

pgrep -a sshd

or:

pgrep -a nginx

Why This Matters

systemctl gives you a human-friendly way to interact with systemd. systemd gives Linux a coordinated way to manage services. The kernel provides the process machinery underneath.

This connects several layers at once:

Command line
Service manager
Unit configuration
Process creation
Memory loading

Final Insight: A simple command like systemctl start nginx is a doorway into the hidden life of Linux: requests, policies, dependencies, processes, and execution.

Next Study

The natural next deep section is: fork() and exec(). That page follows the exact point where systemd turns a request into a running program.

Return to fork/exec in the narrative page

Visual Model

Follow a systemctl request from the command line through systemd and into a running service.