Create a systemd Service Unit in Linux

A systemd service unit is a .service file that tells systemd how to start, stop, and supervise a process. This walkthrough builds a small demo-heartbeat.service on vm1.lab.example that prints a timestamp every 30 seconds to stdout (captured by the journal), then manages it with systemctl.

Where service unit files live

Custom units belong under /etc/systemd/system/. Package managers install vendor units elsewhere:

Files in /etc/systemd/system/ take precedence over vendor units with the same name.

Write the program the service will run

Store custom administrator scripts in /usr/local/sbin/ rather than temporary directories such as /tmp:

sudo tee /usr/local/sbin/demo-heartbeat.sh <<'EOF'
#!/bin/bash
while true; do
  echo "time=$(date -Is)"
  sleep 30
done
EOF

Make it executable:

sudo chmod 755 /usr/local/sbin/demo-heartbeat.sh

Run the script for two seconds so you can confirm the output format without leaving a background loop running:

sudo timeout 2 /usr/local/sbin/demo-heartbeat.sh

Sample output:

time=2026-08-21T16:54:18+05:30

That line goes to stdout. When systemd supervises the script, the same output lands in the journal for the unit.

Create the unit file

A service normally uses [Unit] for metadata and dependencies, [Service] for the process itself, and [Install] when the unit should support systemctl enable.

Create /etc/systemd/system/demo-heartbeat.service:

[Unit]
Description=Demo heartbeat service

[Service]
Type=simple
ExecStart=/usr/local/sbin/demo-heartbeat.sh
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Description= is the name systemctl status displays. This demo needs no After= or Before= line because the script has no dependency on another unit — add those only when the service genuinely must start after something else, such as After=network-online.target for a boot script that calls a remote API.

Type=simple fits a script whose main process stays in the foreground. Restart=on-failure lets systemd retry after a non-zero exit without looping on a clean stop from systemctl stop. WantedBy=multi-user.target is what systemctl enable uses to start the unit on boot.

For a script that runs once and exits, use Type=oneshot instead — see run a script at boot with systemd.

Reload systemd and verify the unit file

Reload the unit cache so systemd reads the new file:

sudo systemctl daemon-reload

daemon-reload exits silently on success.

Check the unit syntax before you start it:

systemd-analyze verify /etc/systemd/system/demo-heartbeat.service

When verify passes, it prints nothing.

Start the service and check status

Start the unit on the running system:

sudo systemctl start demo-heartbeat.service

Wait a couple of seconds, then read the active state:

systemctl status demo-heartbeat.service --no-pager

Sample output:

● demo-heartbeat.service - Demo heartbeat service
     Loaded: loaded (/etc/systemd/system/demo-heartbeat.service; disabled; preset: disabled)
     Active: active (running) since Fri 2026-08-21 16:54:31 IST; 2s ago
   Main PID: 101112 (demo-heartbeat.)
      Tasks: 2 (limit: 48735)
     Memory: 592K (peak: 1.2M)
        CPU: 25ms
     CGroup: /system.slice/demo-heartbeat.service
             ├─101112 /bin/bash /usr/local/sbin/demo-heartbeat.sh
             └─101116 sleep 30

Aug 21 16:54:31 vm1.lab.example systemd[1]: Started demo-heartbeat.service - Demo heartbeat service.

Active: active (running) and a Main PID line confirm systemd is supervising the script. Read the heartbeat lines from the journal:

journalctl -u demo-heartbeat.service -n 5 --no-pager

Sample output:

Aug 21 16:54:31 vm1.lab.example systemd[1]: Started demo-heartbeat.service - Demo heartbeat service.
Aug 21 16:54:31 vm1.lab.example demo-heartbeat.sh[101112]: time=2026-08-21T16:54:31+05:30

The demo-heartbeat.sh[PID]: line is stdout from your script — that is the output journalctl -u is meant to show.

Enable the service at boot

Enable the unit for future boots:

sudo systemctl enable demo-heartbeat.service

Sample output:

Created symlink '/etc/systemd/system/multi-user.target.wants/demo-heartbeat.service' → '/etc/systemd/system/demo-heartbeat.service'.

Confirm systemd will start it on boot:

systemctl is-enabled demo-heartbeat.service

Sample output:

enabled

The symlink under multi-user.target.wants/ is the persistent enable marker.

Stop, disable, and remove the unit

Stop the running service:

sudo systemctl stop demo-heartbeat.service

Confirm it is no longer active:

systemctl is-active demo-heartbeat.service

Sample output:

inactive

Disable it so it does not start on the next boot:

sudo systemctl disable demo-heartbeat.service

Sample output:

Removed '/etc/systemd/system/multi-user.target.wants/demo-heartbeat.service'.

To remove the unit entirely, delete the unit file and script:

sudo rm -f /etc/systemd/system/demo-heartbeat.service /usr/local/sbin/demo-heartbeat.sh

Reload systemd so it drops the removed unit from its cache:

sudo systemctl daemon-reload

Both commands exit silently when the files are gone and systemd has re-read the unit set.

Choose a service Type

Type=simple works for this foreground script. Other applications may require exec, oneshot, notify, or forking depending on how they start — check the upstream unit file or man page before you copy a Type= value from another service.

Troubleshooting

References

• systemd.service(5)
• systemd.unit(5)
• Red Hat — Managing systemd services

Summary

You create a systemd service by placing a .service file under /etc/systemd/system/ with [Unit], [Service], and usually [Install], pointing ExecStart= at a script or binary systemd should supervise. After systemctl daemon-reload, start brings the unit up, status shows the active state, and journalctl -u captures stdout from the service. enable adds the multi-user.target.wants/ symlink for boot.

The mistake I see most often is editing the unit file but skipping daemon-reload, or adding After= without a real dependency. Match Type= to how the process starts — simple for a foreground loop like this demo, oneshot for a one-time boot script — and keep custom units in /etc/systemd/system/.

For broader systemctl verbs, see the systemctl command reference. For boot, timer, and shutdown timing, use the linked systemd guides in the intro table.