Intro to systemd: Managing Services and Boot Processes Like a Pro

Last Updated: June 23, 2025

• A Linux system using systemd (Ubuntu 20.04+, Debian 10+, CentOS 7+, Arch, Fedora, etc.)
• sudo privileges
• Basic command-line experience.

• You know your way around bash, ssh, and apt or yum
• You’re familiar with the concept of “services” (e.g. nginx, sshd)
• You want to automate or control how background tasks run on your system across reboots.

ps -p 1 -o comm=

If it says systemd, you’re good to go.

Ubuntu/Debian:

sudo apt update
sudo apt install systemd

RHEL/CentOS/Fedora:

sudo yum install systemd

Note: In containerized environments like Docker, systemd is often stripped out or disabled. Use base images like phusion/baseimage or switch to podman for native support.

• Starting your OS
• Launching background services
• Managing user sessions, logs, timers, dependencies, and even mounts

If you’re running Linux in 2025, odds are you’re already using systemd. (even if you didn’t know it)

sudo systemctl start nginx         # Start a service now
sudo systemctl enable nginx        # Enable it to start on boot
sudo systemctl disable nginx       # Disable it from starting on boot
sudo systemctl restart nginx       # Restart the service (i.e. Reload config)
sudo systemctl status nginx        # Check current state
sudo systemctl stop nginx          # Stop the service

This structure is consistent across most services, i.e. cron, docker, ssh and so on.

# /etc/systemd/system/my-backup.service
[Unit]
Description=Daily Backup Job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/daily-backup.sh
Now here’s the corresponding .timer:

# /etc/systemd/system/my-backup.timer
[Unit]
Description=Run backup daily at 2am

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

Enable both with:

sudo systemctl daemon-reload
sudo systemctl enable --now my-backup.timer

And there you have it! Now it runs manually or on boot.

# /etc/systemd/system/my-backup.timer
[Unit]
Description=Run backup daily at 2am

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

Timers work with .service units, so they’re modular and easier to debug than traditional crontabs.

You might have used cron in our Log Rotation Tutorial.

Start it up:

sudo systemctl enable --now my-backup.timer

Check status:

systemctl list-timers

systemd Best Practices

1. Always define a Description
   Helps humans (and future-you) understand what it does.
2. Use absolute paths in ExecStart, ExecStop, etc.
   Environment PATHs are not guaranteed.
3. Use Type=oneshot for scripts and Type=simple or Type=forking for services.
4. Reload daemon after creating or editing unit files:
   sudo systemctl daemon-reload
5. Put user-specific units in ~/.config/systemd/user/
   For services that don’t require root.
6. Use WantedBy=multi-user.target to auto-start services after boot networking is up.
7. Don’t put logic in unit files—wrap commands in scripts if needed.

Symptom	Diagnosis	Solution
Service won’t start	sudo journalctl -xe or systemctl status <service>	Check for typos, missing paths
Timer isn’t firing	systemctl list-timers	Ensure .timer file is enabled
Service fails silently	Missing logs	Add StandardOutput=journal to unit
Unit file changes ignored	Daemon not reloaded	Run sudo systemctl daemon-reload
Logs missing	journalctl empty	Enable persistent logging under /var/log/journal

# All logs
journalctl

# For a specific service
journalctl -u nginx.service

# Most recent logs
journalctl -xe

You can even make it persistent:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Alternatives and Why We Use systemd

Tool	Purpose	Why systemd wins
SysVinit	Legacy init scripts	Lacks dependency handling
Upstart	Transitional tool	Deprecated, Ubuntu-only
Runit/OpenRC	Lightweight	Great for minimal setups, not default
Supervisor	Process manager	Doesn’t integrate with boot/logs

systemd wins for its all-in-one nature, tight integration with boot, logging, and dependencies; As well as consistency, support, and features like journald and timers. In fact, it’s the Linux standard going forward.

• Define services once, version them in Git, and deploy them consistently across environments
• Replace fragile cron jobs with timer units that are easier to debug, audit, and maintain
• Leverage built-in logging, restart policies, and health checks (no extra tooling required)
• Count on wide compatibility: systemd is pre-installed on almost every cloud image and major distro

And that’s just the start. Once you’re comfortable with systemd, you unlock a better approach to:

• Deployment automation: run apps, workers, and background jobs on boot without duct tape
• Monitoring: tap into journald for log aggregation and alerting foundations
• Infrastructure as Code: define clean, declarative units instead of relying on imperative scripts
• CI/CD hooks: trigger builds, health checks, or cleanups using service and timer units

If you’re serious about Modern TechOps, systemd is not optional! It is a core skill that pays off in speed, clarity, and control.

Summary

• systemd manages services, logging, and boot processes
• Unit files define services cleanly and reproducibly.
• systemctl gives you full control over services and timers
• journalctl handles integrated logging
• With smart design, systemd can replace cron, shell scripts, and old init hacks.
• systemd is the backbone of modern Linux service management.