Copy · paste · systemctl enable --now
systemd unit files you can actually paste.
Complete .service, .timer, .mount, .path and
.socket recipes for the things you actually configure — auto-restart a crashing service,
run at boot, replace a cron job with a timer, auto-mount a share, watch a folder, socket-activate, and
harden a service — each with the exact enable and verify commands.
18 recipes
- Services (.service) Order a service after the network or another unit (After, Requires, Wants) The difference between After=, Requires=, Wants=, and BindsTo=, and how to correctly wait for the network or a database before your service starts.
- Services (.service) Pass environment variables to a systemd service Set env vars inline with Environment=, or load them from a file with EnvironmentFile= (the right way to keep secrets out of the unit).
- Services (.service) Run a one-shot task at boot (Type=oneshot) Run a script once at boot (or on demand) that does its job and exits — for setup, migrations, or tweaks — and have systemd remember it as 'active'.
- Services (.service) Auto-restart a service when it crashes (with backoff and a rate limit) Make systemd restart your service if it exits or crashes, wait a few seconds between tries, and stop hammering it if it keeps failing.
- Services (.service) Run a systemd service as a specific user and group Drop a service from root to a dedicated unprivileged user, set its working directory, and (optionally) create the user with DynamicUser.
- Services (.service) Run a program at boot as a systemd service The minimal .service unit to start your own program (a script, binary, or app) automatically at boot, and keep it managed by systemd.
- Services (.service) Run a long-running program as a user service (no root) Put a service under ~/.config/systemd/user/ so it runs as you, with systemctl --user — and keep it running after you log out using lingering.
- Timers (.timer) Run a job daily at a specific time (and catch up after downtime) A systemd timer with OnCalendar for a daily 03:30 run, weekly and monthly variants, and Persistent=true so a missed run fires when the machine comes back.
- Timers (.timer) Run a job every 5 minutes with a systemd timer (the cron replacement) A .timer + .service pair that runs a command every 5 minutes — the modern, journald-logged replacement for a */5 cron entry.
- Timers (.timer) Run a job N minutes after boot, then on an interval (OnBootSec / OnUnitActiveSec) Monotonic systemd timers: run a job 2 minutes after boot and then every 15 minutes — independent of wall-clock time, perfect for health checks and pollers.
- Timers (.timer) Spread scheduled jobs with RandomizedDelaySec (avoid the thundering herd) Add a random jitter to a systemd timer so a fleet of machines (or many timers on one host) don't all hit a server at the exact same second.
- Mounts (.mount) Mount a share only when it's accessed (.automount) Pair an .automount with a .mount so a network share mounts lazily on first access and can unmount when idle — faster boots, no hang if the server is down.
- Mounts (.mount) Create a bind mount as a systemd unit Expose a directory at a second path with a .mount unit using Options=bind — the systemd equivalent of mount --bind, managed and ordered like any other unit.
- Mounts (.mount) Auto-mount an NFS or CIFS/SMB share with a .mount unit Mount a network share as a native systemd .mount unit — including the all-important rule that the filename must match the mount path.
- Path units (.path) Run a command when a file appears or changes (.path unit) A .path + .service pair that watches a file or directory and triggers a command on creation or modification — inotify-driven, no polling.
- Sockets (.socket) Socket-activate a service (start it on the first connection) A .socket + .service pair so systemd holds the listening port and starts your service only when a client first connects — faster boots and on-demand services.
- Hardening Harden any service with sandboxing directives A drop-in set of systemd sandboxing options — NoNewPrivileges, ProtectSystem, PrivateTmp, system-call filtering and more — to lock a service down, plus how to score it.
- Managing units Essential systemctl & journalctl commands for managing units The day-to-day systemd commands: enable, start, status, reload, logs, list timers, safe overrides with 'systemctl edit', and validating a unit file.
Why this exists
You know systemd can do it. You don't remember the exact directive.
systemd runs services, schedules jobs, mounts filesystems, watches paths, and sandboxes processes —
but the precise option (Restart=on-failure? OnCalendar= syntax? the
.mount naming rule?) never sticks, so you re-read the man page or paste a half-right unit
from a forum. unitforge.pages.dev is a library of focused, copy-paste unit files for
real tasks, each with a one-line explanation, the enable/verify commands, and
the gotchas (escaped mount names, enabling the timer not the service, network ordering).
How it works
Find the task, copy the unit, enable it
- Pick a recipe. Browse by unit type in the full recipe list.
- Copy the unit file into
/etc/systemd/system/(one-click copy on every block). - Run
daemon-reloadthenenable --now— each recipe gives the exact commands.
FAQ
Frequently asked questions
Are these systemd unit files free?
Yes. Every recipe on unitforge.pages.dev is free to read and copy, with no account, paywall, or sign-up. Some outbound links (for example to VPS hosting or Linux courses) may be affiliate links, which never change the price you pay.
Where do I put a unit file?
System units go in /etc/systemd/system/<name>.service (your own units; the distro's live in /lib/systemd/system). Per-user units go in ~/.config/systemd/user/. After adding or editing one, run "systemctl daemon-reload", then "systemctl enable --now <name>".
Do I need to be root?
For system units, yes — use sudo for daemon-reload, enable, start, and editing files under /etc/systemd/system. User units (systemctl --user, ~/.config/systemd/user/) need no root at all; enable lingering with "loginctl enable-linger $USER" if they should run after you log out.
Which systemd version do these target?
Modern systemd (v240+), which ships on current Debian/Ubuntu, RHEL/Fedora, Arch, and SUSE. A few directives (DynamicUser, some hardening and StartLimit options) are newer; where it matters the recipe notes it. Check yours with "systemctl --version".
What's the difference between enable and start?
"start" runs the unit right now (until reboot). "enable" sets it to start on every boot (but doesn't start it now). "enable --now" does both. For timers, sockets, paths, and automounts you enable the .timer/.socket/.path/.automount — not the .service it triggers.
Why use a systemd timer instead of cron?
Timers log every run to the journal (journalctl -u), show next/last run with "systemctl list-timers", can catch up missed runs (Persistent=true), depend on other units, retry, and jitter across a fleet (RandomizedDelaySec). cron does none of that. The "every 5 minutes" recipe is a drop-in replacement for a */5 entry.