Linux systemd Basics

What Is systemd?

systemd is the init system and service manager used by many modern Linux distributions. It is responsible for booting the system, starting services, tracking their state, and managing logs and dependencies.

If you run a server with Nginx, Docker, SSH, or a custom app, systemd often controls whether that service starts at boot and how it behaves.

Understanding Units and Targets

systemd manages objects called units. A unit describes something systemd knows how to manage.

Common unit types include:

• .service for services
• .socket for socket activation
• .mount for mount points
• .timer for scheduled tasks
• .target for grouped system states

A target is roughly like a collection of units that represents a system state, such as multi-user mode.

Managing Services with systemctl

systemctl is the main command for working with systemd.

Start a service:

sudo systemctl start nginx

Stop a service:

sudo systemctl stop nginx

Restart a service:

sudo systemctl restart nginx

Check status:

systemctl status nginx

This shows whether the service is active, recent log lines, and the main process ID.

Enabling and Disabling at Boot

A service can be running now without being configured to start at boot.

Enable at boot:

sudo systemctl enable nginx

Disable at boot:

sudo systemctl disable nginx

A common beginner mistake is assuming start and enable mean the same thing. They do not.

• start affects the current session
• enable affects future boots

Tip: Many deployment issues happen because a service was started manually but never enabled.

Reading Logs with journalctl

systemd integrates with the system journal, which you can query using journalctl.

Show recent logs:

journalctl

Follow logs in real time:

journalctl -f

View logs for a specific unit:

journalctl -u nginx
journalctl -u sshd -f

Filter by time:

journalctl --since "2026-07-14 09:00:00"
journalctl -u nginx --since "1 hour ago"

This is incredibly useful for diagnosing why a service failed to start.

Writing a Simple Unit File

You can manage your own applications with systemd by creating a unit file.

Example:

[Unit]
Description=Demo Application Service
After=network.target

[Service]
Type=simple
WorkingDirectory=/opt/demo-app
ExecStart=/usr/bin/python3 /opt/demo-app/app.py
Restart=on-failure
User=demo
Group=demo

[Install]
WantedBy=multi-user.target

Save it as:

/etc/systemd/system/demo-app.service

Then reload systemd and start the service:

sudo systemctl daemon-reload
sudo systemctl start demo-app
sudo systemctl enable demo-app

Understanding Key Unit Sections

[Unit]

This section describes metadata and dependencies.

[Service]

This section defines how the service starts, under which user, in which directory, and what should happen if it fails.

[Install]

This section describes how the unit is tied into targets when enabled.

Practical Troubleshooting Flow

Suppose your service will not start after deployment.

A useful workflow is:

systemctl status demo-app
journalctl -u demo-app --since "10 minutes ago"

Typical causes include:

• wrong ExecStart path
• missing working directory
• permission problems
• missing environment variables
• app crashes during startup

systemd gives you a repeatable place to inspect that behavior.

Test Your Understanding

Let's see how well you understood the concepts! These exercises will help reinforce what you just learned.

Exercise 1: Start versus enable

Question: What is the difference between systemctl start nginx and systemctl enable nginx?

Exercise 2: Filtering the journal

Scenario: A custom app service fails after deployment, and you want only its journal entries from the last 10 minutes.

Question: Which command from the lesson is the best match?

Exercise 3: Making systemd notice changes

Question: Why do you run systemctl daemon-reload after creating or editing a unit file in /etc/systemd/system?