Systemd services that stay up after you log out

Every beginner meets the same ghost: the service works while you watch, then dies overnight or after a reboot. The cause is almost never the application. It is the difference between starting a process and installing a service.

Start is now, enable is forever

start runs the unit right now in this boot. enable wires it into boot so it returns after every restart. Production needs both: start it now, enable it for later. Check both states when you inherit a machine, because started-but-not-enabled is a reboot away from an outage.

Restart with a limit

A restart policy of always or on-failure turns crashes into brief hiccups. But an unchecked restart loop on a broken config writes thousands of log lines and hides the real error. Pair the policy with a burst limit: a few restarts in a short window, then stop and stay stopped so a human looks.

Worked example: a fictional night outage

The context below is fictional. Fictional service ParcelTrack (fictional) runs from a hand-started process on a VM. It works for weeks, then the host reboots for patching at 3 AM and the service never comes back. Nobody is paged because nobody defined what up means.

Morning diagnosis takes ten minutes: the process was started, never enabled, and there was no unit file at all. The fix is a small unit file with the working directory, the run user, restart on failure with a burst limit, and enable plus start. The verification is a reboot test on purpose: reboot, confirm the service returns alone, then write down the check.

Checklist: a service you can leave alone

1. Unit file exists, with run user and working directory set.
2. Both started now and enabled for boot.
3. Restart on failure with a burst limit.
4. A reboot test proved it comes back alone.

Related reading

• DevOps Foundations covers services in Module 1.
• When it breaks at boot: Boot Failure from Environment and Unit.