systemd Unit Generator

How to use it

1. Give the service a name and the command to run — with the full path of the program (/usr/bin/node, not node).
2. Choose the user it runs as. A dedicated user (the install steps create it) is safer than root.
3. Decide how it runs: all the time, restarted if it crashes — or on a schedule with a .timer, the systemd alternative to cron.
4. Copy the file(s) to /etc/systemd/system/, then run the commands under the result.

What you get

• Restart on failure, with a pause between tries, so a crash doesn’t take your app down for good.
• Start order: after the network is really up, and after the services it needs (postgresql.service…).
• Limits that matter in production: MemoryMax= makes the kernel stop this service when it uses too much memory, instead of a random process (see Linux process “Killed”); LimitNOFILE= raises the open files limit, which limits.conf doesn’t do for services (see Too many open files).
• Basic hardening: no privilege escalation, a private /tmp, system folders read-only.
• Timers with catch-up after downtime (Persistent=true) and a random delay, logged in the journal like every service.

Common commands

sudo systemctl daemon-reload              # after creating or editing a unit file
sudo systemctl enable --now myapp         # start now and at boot
systemctl status myapp                    # state and last log lines
journalctl -u myapp -f                    # follow the logs
sudo systemctl edit myapp                 # change settings in a drop-in, without touching the file
systemctl list-timers                     # when every timer runs next
systemd-analyze calendar "Mon..Fri 08:30" # check an OnCalendar expression
systemctl list-unit-files 'myapp*'        # is the unit installed, under which name

FAQ

Why does my command work in the shell but not in ExecStart?

ExecStart= is not a shell. There is no PATH from your profile, no cd, no &&, | or > redirections, no ~. Use full paths and WorkingDirectory=; if you really need shell syntax, run it through /bin/sh -c '…' — or better, put it in a script. If the service fails to start, see Job for … failed because the control process exited with error code.

simple, exec, notify or oneshot?

simple for most apps that run in the foreground. exec is the same, but systemctl start already fails if the program can’t even be started (wrong path, permissions). notify only if the app tells systemd it’s ready (many daemons can: nginx, PostgreSQL, some app servers). oneshot for scripts that do something and exit — that’s what timers run.

Timer or cron?

Both work. A timer logs every run in the journal, can catch up after the machine was off, doesn’t run twice if the previous run is still going, and uses the same limits and users as services. Cron is simpler for a quick one-liner — see the Cron Builder and Cron job not running.

Which commands do I need to manage the service?

They’re in the systemctl and journalctl Cheat Sheet.

Where can I practice managing services?

In the lesson Services: systemctl and journalctl.