systemd - Launch Your First Service

Learn everything you need about systemd, then create your first service in just 5 minutes

On modern Linux, systemd is the init system—enhancing shell script execution, dependency management, control over start/stop. systemd can handle orchestration of different resource types, including:

• Service units (.service) for daemons, scripts, etc.
• Timer units (.timer) for scheduling tasks
• Socket units (.socket) to activate services on demand
• Mount units (.mount) to manage file system mounts
• Target units (.target) to group other units and represent runlevels

Why systemd Matters: systemd in the Real World  

systemd is always running in the background, orchestrating services and tools we depend on every day, such as:

• Popular dev tools: Docker, MySQL, PostgreSQL. It gives them the ability to start their units in order, recover from failures, and honour resource limits.
• Scheduled tasks: Backups and health checks run reliably via timers (which trigger service units). It’s especially feasible to use systemd timers (in place of cron) when you need dependency handling (e.g., wait for network-online), built-in logging, catch-up on missed runs, or per-user scheduling without root privileges.
  The traditional cron daemon (crond) is itself managed as a systemd service (crond.service).
• On-demand activation services: ssh, cups for printing services—systemd listens on their respective socket (eg. ssh.socket for ssh) and launches the service unit only when needed, reducing idle resource usage.
• Runlevel grouped services: Targets like multi-user.target (headless servers), graphical.target (GUI environments) bundle related services and run them in stages based on the target’s defined declarative dependencies.

Unit Files  

We know that systemd’s architecture is built on the concept of units. The units are defined by unit files, written in a declarative language containing 3 distinct sections, namely:

• [Unit]: Defines what the service is and its relationships (metadata, dependencies, and activation conditions).
• [Service]: Specifies how to run the process (command, restart behaviour, privileges, and resource limits).
• [Install]: Describes how the unit is enabled and tied to targets for startup.

The unit files are located in /lib/systemd/system/ and /etc/systemd/system/. As an example, take a look at the unit file for sshd.service:

[Unit]
Description=OpenSSH Daemon
Wants=sshdgenkeys.service
After=sshdgenkeys.service
After=network.target

[Service]
Type=notify-reload
ExecStart=/usr/bin/sshd -D
KillMode=process
Restart=always

[Install]
WantedBy=multi-user.target

systemctl  

systemctl is the the command used to manage and control systemd. It makes it easy to see a summary of each service, start/stop a service, see recent logs, etc.

systemd also introduced a centralised logging system called journald where all units write their stdout/stderr. The journalctl command is used to interact with the journal. If your OS does not use journald, you will have to “manually” access it.

Depending on your user/groups, you may need to use sudo.

Get Unit Summary:

systemctl status [unit]

# eg.
systemctl status sshd.service
systemctl status docker.service
systemctl status reflector.timer

Start/Stop/Restart:

systemctl start [unit]
systemctl stop [unit]
systemctl restart [unit]

Enable/Disable: Used for controlling if a service starts automatically at boot.

systemctl enable [unit]
systemctl disable [unit]

Check timer triggers:

systemctl list-timers --all

Inspect logs:

For journald:

journalctl -u [unit]

# eg.
journalctl -u sshd.service

For syslog:

grep [unit] /var/log/syslog

# or /var/log/messages
# check your system's log location

Create Your First Service  

Depending on your user/groups, you may need to use sudo.

One-shot Service  

1. Create the unit file for your service—for this example, we will call it hello.service—and place it in /etc/systemd/system/. Use the content below for your unit file.

[Unit]
Description=Hello World Service

[Service]
Type=oneshot
ExecStart=/usr/bin/echo "Hello World!"

[Install]
WantedBy=multi-user.target

1. Reload the daemon and start/enable the service.

systemctl daemon-reload
systemctl start hello.service

1. Check service activity.

systemctl status hello.service
journalctl -u hello.service --since "5 minutes ago"

It’s that simple!

Long-lived Service  

You may notice that it is a one-shot service, meaning that it only runs once. Let’s create a long-lived service.

1. Create a bash script called hello.bash and place it in /usr/local/bin/ with the contents below.

#!/usr/bin/env bash
i=1
while true; do
	echo "Hello World $i!"
	((i++))
	sleep 1
done

Make it executable:

chmod +x /usr/local/bin/hello.bash

1. Edit the service file that you just created /etc/systemd/system/hello.service. You only need to change items in the [Service] section.

[Unit]
Description=Hello World Service

[Service]
ExecStart=/usr/local/bin/hello.bash
Restart=always

[Install]
WantedBy=multi-user.target

1. Reload the daemon and check its status/logs.

Conclusion  

systemd’s unit model—spanning categories like services, timers, sockets, targets—gives you a single, declarative framework for process management, scheduling and resource control. By using systemd, you get features like reliable startups, automatic recovery, and unified logs without having to introduce complexity by juggling different tools.

Resources  

• A Brief Overview and History of systemd — the Linux Process Manager 
• ArchWiki: systemd 
• Manage Systemd Services with systemctl on Linux 
• Red Hat: Managing Services with systemd 
• systemd.io 
• Understanding Systemd Units and Unit Files 

Additional Reading  

• systemd-timers vs. cron