Fill in the command, user and restart policy and get a ready-to-use systemd unit file with copy-paste install commands. Options for environment variables, start order, resource limits and sandboxing are included, and common mistakes such as relative paths or shell syntax in ExecStart are flagged.
Last updated:
Generated unit file
Advertisement
Advertisement
How to use the Systemd Service File Generator
Pick an example close to your program and click Load example, or start editing the default Node.js unit.
Enter the unit name, description and ExecStart command with an absolute path, plus the working directory and the user that should run it.
Choose the restart policy and add the units it should start after, environment variables and log name.
Apply hardening with the Basic or Strict preset, then fine-tune individual options.
Copy the unit file or open Install commands, paste them in a terminal and check the service with systemctl status.
Anatomy of a unit file
A service unit is a plain text file with three sections. Directives are case-sensitive, and each belongs to one section:
Section
Directive
What it does
[Unit]
Description=
Human-readable name shown by systemctl status.
After= / Wants=
Start order and weak dependency. After alone does not pull a unit in.
Requires=
Strong dependency: if the required unit stops, this one stops too.
StartLimitIntervalSec=, StartLimitBurst=
Give up after too many restarts in a time window.
[Service]
Type=
How systemd knows the service has started (simple, exec, forking, notify, oneshot, idle).
ExecStart=
The command to run. Not a shell: no pipes or redirects.
User= / Group=
Account the process runs as (root if omitted in system services).
WorkingDirectory=
Current directory of the process.
Restart= / RestartSec=
When to restart automatically and how long to wait first (default 100 ms).
Environment= / EnvironmentFile=
Variables for the process; a leading - on the file path makes it optional.
[Install]
WantedBy=
Target that pulls the service in when it is enabled, usually multi-user.target.
Everyday systemctl and journalctl commands
Command
Purpose
sudo systemctl daemon-reload
Reload unit files after creating or editing them.
sudo systemctl enable --now app
Start at boot and start right now.
sudo systemctl restart app / reload app
Restart the process, or run ExecReload (config reload without downtime).
systemctl status app
State, main PID, memory and the last log lines.
journalctl -u app -f
Follow the service log live; add --since "1 hour ago" to filter.
sudo systemctl edit app
Create a drop-in override instead of changing the original file.
systemd-analyze verify app.service
Check a unit file for unknown directives and missing files.
systemd-analyze security app
Show the sandboxing exposure score and which options would improve it.
Tips
Escape special characters. In unit files % starts a specifier (for example %n is the unit name), so write %% for a literal percent sign. $VAR and ${VAR} in ExecStart are replaced from Environment, and $$ is a literal dollar.
Log to stdout. Anything the program prints goes to the journal automatically; there is no need for log files unless you want them.
Harden step by step. Start with Basic, restart the service and check its logs, then try Strict. If the app needs to write somewhere, add that folder to ReadWritePaths.
Prefer timers to cron for systemd hosts. A oneshot service plus a .timer unit gets logging, dependencies and missed-run catch-up for free.
Frequently asked questions
Where do I put a systemd service file?
System services you create go in /etc/systemd/system/name.service. Per-user services go in ~/.config/systemd/user/name.service. After adding or changing a file, run systemctl daemon-reload (or systemctl --user daemon-reload) so systemd reads it.
How do I make a service start at boot?
The [Install] section with WantedBy=multi-user.target tells systemd where to hook the service in. Run sudo systemctl enable --now name.service to create that link and start it immediately. User services use WantedBy=default.target, and loginctl enable-linger keeps them running when you are logged out.
What is the difference between Restart=always and Restart=on-failure?
on-failure restarts the service only when it exits with a non-zero code, is killed by a signal, times out or trips the watchdog. always also restarts it after a clean exit. Neither restarts a service you stop with systemctl stop. If restarts happen more often than StartLimitBurst times within StartLimitIntervalSec (5 in 10 seconds by default), systemd gives up.
Why does my ExecStart command fail when it works in the terminal?
systemd runs the command directly, without a shell and without your login environment. Use absolute paths, avoid pipes, redirects, && and ~, set WorkingDirectory and Environment explicitly, or wrap the command in /bin/sh -c '...'. Check journalctl -u name.service for the exact error.
Which Type should I choose?
Use simple (or exec) for programs that stay in the foreground, which covers most modern apps. Use forking only for old daemons that fork into the background, ideally with PIDFile. notify is for programs that call sd_notify when ready, and oneshot is for scripts that run once and exit, often with RemainAfterExit=yes.
How do I pass environment variables or secrets?
Use Environment=KEY=value lines (quote the whole assignment when the value has spaces) for ordinary settings. For passwords and tokens use EnvironmentFile=/etc/name/env with permissions 600, because unit files are readable by every user on the system.
What do the hardening options do?
They sandbox the service: NoNewPrivileges blocks privilege escalation, PrivateTmp gives it its own /tmp, ProtectSystem and ProtectHome make system folders read-only or hidden, and the Protect/Restrict options block kernel tuning, module loading and similar actions. Run systemd-analyze security name.service to see an exposure score, and test the service after each change.
Are all the tools on FreeToolCabin tested for quality and accuracy?
Yes! Every tool on our site undergoes automated Q/A testing in real browser environments to ensure high precision, correct output, and zero errors. If you happen to spot a bug or have a suggestion, please contact us at [email protected] and our team will review it right away.