Understanding Systemd and Managing Services in Linux

Learn how systemd works in Linux and how to manage services efficiently using systemctl. A complete guide for administrators who want full control over the system startup and background processes.

Introduction: What Is Systemd and Why It Matters

If you’ve used any modern Linux distribution — like Ubuntu, Debian, Fedora, or CentOS — you’ve already been using systemd, even if you didn’t realize it.

Systemd is the init system and service manager responsible for:

• Booting the system
• Managing background services (daemons)
• Handling logs and dependencies
• Ensuring processes start and stop correctly

In short, systemd controls your Linux system from the moment it powers on — until it shuts down.

Before systemd, Linux used older init systems like SysVinit or Upstart.
Systemd replaced them with a faster, parallelized, dependency-aware architecture that made Linux startup times shorter and management much easier.

⚙️ 1. Understanding How Systemd Works

When you press the power button:

1. The kernel initializes hardware.
2. The kernel launches PID 1, which is systemd.
3. systemd starts all services defined as necessary for your target (runlevel).
4. Once all dependencies are met, the system reaches the multi-user or graphical target (similar to “runlevel 5” in older systems).

Everything that systemd controls is defined in unit files — special configuration files describing what to start, how, and when.

📦 2. Systemd Units: The Building Blocks

A unit in systemd represents a resource or service.
There are several types of units:

Example service unit file:

/etc/systemd/system/myapp.service

🧩 Example: Simple Custom Service File

Here’s a minimal myapp.service example:

[Unit]
Description=My Custom Python App
After=network.target

[Service]
ExecStart=/usr/bin/python3 /home/wang/app.py
Restart=always
User=wang

[Install]
WantedBy=multi-user.target

To enable and start it:

sudo systemctl enable myapp.service
sudo systemctl start myapp.service

Boom — your Python script now runs as a managed background service.

🧰 3. Common systemctl Commands

systemctl is your main interface for interacting with systemd.

🔍 Example: Checking and Managing Services

Check Status:

sudo systemctl status nginx

Start or Stop a Service:

sudo systemctl start nginx
sudo systemctl stop nginx

Enable a Service on Boot:

sudo systemctl enable nginx

Disable a Service:

sudo systemctl disable nginx

View All Active Services:

systemctl list-units --type=service

🕒 4. Understanding Targets (Runlevels in Systemd)

Targets in systemd replace old-school runlevels.
They represent system states (sets of services and dependencies).

Check the current target:

systemctl get-default

Change the default boot target:

sudo systemctl set-default multi-user.target

🔄 5. Managing the Boot Process and Logs

Systemd comes with integrated logging via journald, which stores logs for all services.

View Logs for a Specific Service

journalctl -u nginx.service

Follow Logs in Real-Time

journalctl -u nginx.service -f

View Boot Logs

journalctl -b

View All Errors Across Services

journalctl -p 3 -xb

Pro tip: You can combine journalctl with grep to search for patterns inside logs.

Example:

journalctl -xe | grep "error"

🧩 6. Creating and Managing Timers (Cron Alternative)

Systemd timers are a modern replacement for cron jobs.
They use .timer units that trigger .service files.

Example — backup.timer and backup.service:

backup.service

[Unit]
Description=Daily Backup Script

[Service]
ExecStart=/usr/local/bin/backup.sh

backup.timer

[Unit]
Description=Runs backup daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Enable and start the timer:

sudo systemctl enable --now backup.timer

Check timers:

systemctl list-timers

🧠 7. Troubleshooting systemd Services

When something fails, systemd provides detailed diagnostics.

Check Service Logs

sudo journalctl -u myapp.service

Analyze Boot Performance

systemd-analyze

Find Which Services Delayed Boot

systemd-analyze blame

Reload Configuration After Changes

sudo systemctl daemon-reload

Reset Failed Units

sudo systemctl reset-failed

🧩 8. Real-World Example: Restarting Services on Failure

In your .service file, you can define automatic restarts:

[Service]
ExecStart=/usr/bin/python3 /home/wang/server.py
Restart=on-failure
RestartSec=5

Now, if your script crashes, systemd will automatically restart it after 5 seconds.
This is extremely useful for production environments.

⚡ 9. Why Systemd Simplifies Server Management

• Unified command (systemctl) replaces multiple old tools (service, chkconfig, init.d scripts)
• Parallel startup speeds up boot time
• Built-in logging simplifies debugging
• Timers and dependencies improve automation
• Portable unit files make deployment consistent across distributions

Once you understand systemd, you gain complete control over how Linux starts, runs, and recovers — whether you manage a personal server or a data center.

🧭 Summary

Systemd is the heartbeat of modern Linux.
It manages your services, handles boot, tracks logs, and gives you full visibility into system behavior.

If you can confidently use:

• systemctl for control
• journalctl for logs
• and *.service files for customization,

then you’re no longer just a Linux user — you’re a Linux administrator. 💪

🔗 Next Steps

Continue expanding your Linux mastery:

• Monitoring System Performance with top, htop, and iostat
• Troubleshooting Disk Space Issues in Linux
• How to Secure SSH Access on Your Linux Server

Or get the full “Mastering Linux Services and Automation” eBook on dargslan.com.