How to Write a systemd Service Unit File

The three sections every unit needs

A service unit lives in a .service file. It always has three sections: [Unit] for metadata and ordering, [Service] for how to run the process, and [Install] for when to start it on boot.

Here is a complete, production-ready example for a Python Flask API:

[Unit]
Description=Production Flask API
After=network.target

[Service]
Type=simple
User=appuser
ExecStart=/opt/venv/bin/python /opt/api/app.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

[Unit] - metadata and ordering

• Description - a human-readable label shown in systemctl status output.
• After=network.target - tells systemd to start this unit only after the network stack is up. It is an ordering hint, not a hard dependency; your service starts last in the normal boot sequence without a tight dep chain.

[Service] - the process spec

• Type=simple - the process systemd starts is the service. Do not use Type=forking unless the binary double-forks into the background on its own (old-school daemons do this; gunicorn/uvicorn/python do not).
• User=appuser - run as a non-root account. If the user does not exist, systemd will fail to start the unit. Create it with useradd --system appuser.
• ExecStart - the full path to the binary and its arguments. Always use absolute paths; relative paths break when the working directory changes. For virtualenv Python, point at the venv's interpreter: /opt/venv/bin/python.
• Restart=always - restart the process on any exit (crash, OOM kill, non-zero exit code). Combine with RestartSec=5 to add a 5-second cooling-off before the next attempt so a tight crash loop does not peg CPU.

[Install] - boot integration

WantedBy=multi-user.target is the correct target for almost every server service. It means "enable this unit when the system boots into the normal multi-user runlevel." After writing the file, enable and start it:

systemctl enable --now api.service

--now enables (creates the symlink) and starts the service in one shot.

Validate before you deploy

systemd-analyze verify checks syntax and required fields without starting the service or needing PID 1 running:

systemd-analyze verify api.service

A clean file exits with no output. Any warning or error is printed to stderr. Fix them before copying the file to /etc/systemd/system/.

Common production additions

Once the basics pass, harden the unit with resource and security directives:

[Service]
MemoryMax=512M
CPUQuota=50%
NoNewPrivileges=true
EnvironmentFile=/etc/api.env

EnvironmentFile keeps secrets out of the unit file itself - write KEY=VALUE pairs to /etc/api.env (mode 0600, owned by root) and systemd injects them as environment variables at start time.