systemd service file generator
Turn a command into a proper systemd service: fill in what to run, which user, how to restart it and when to start it, and copy a complete .service unit file plus the exact install commands. Enable the optional timer to schedule it like a cron job. Everything is generated in your browser.
What a systemd service file generator does
On every modern Linux distribution, systemd is the init system that starts, stops, supervises and restarts background services. To run your own program as a managed service, you write a unit file describing the command, the user it runs as, when it should start and how it should recover from a crash. The syntax is small but unforgiving: a missing absolute path, the wrong Type or a forgotten daemon-reload and the service silently fails. This generator builds a correct unit file from plain fields and gives you the install commands to go with it.
A unit file has three sections. [Unit] holds metadata and ordering (Description, After, Wants). [Service] defines the process: the command in ExecStart, the Type, the User, the restart policy. [Install] tells systemd what enabling the service means, usually WantedBy=multi-user.target so it starts at boot. Get these three right and your program becomes a first-class citizen alongside nginx and sshd.
Choosing the right Type
| Type | Use when |
|---|---|
simple | Your command stays in the foreground and is the main process. The default for most apps. |
exec | Like simple, but systemd waits until the binary has executed before considering it started. Stricter, good default on recent systemd. |
forking | The command forks and the parent exits (traditional daemons). Usually needs a PIDFile. |
oneshot | A short task that runs and exits, often paired with a timer. Add RemainAfterExit=yes if it sets up state. |
notify | The service signals readiness via sd_notify. Used by services that support it, like modern web servers. |
Restart policy and security
The Restart=on-failure policy restarts the service if it exits non-zero or crashes, which is what most services want; always restarts even on clean exits and suits long-running daemons that should never stop. Pair it with RestartSec to avoid a tight crash loop. For hardening, run the service as a dedicated non-root User rather than root, set a WorkingDirectory, and consider adding sandboxing directives such as NoNewPrivileges=true, ProtectSystem=strict and PrivateTmp=true once the basic unit works.
Services, timers and cron
A systemd timer is the modern replacement for a cron job. You pair a oneshot service with a .timer unit that has an OnCalendar expression (the same idea as a cron schedule, with a friendlier syntax like daily or *-*-* 03:00:00). Timers add benefits cron lacks: they log to the journal, they can catch up missed runs with Persistent=true after the machine was off, and they inherit all the dependency and sandboxing features of services. Enable the timer option above to generate both files.
Privacy and how this tool runs
The unit files and commands are generated by JavaScript in your browser. Nothing you type is sent to a server or logged. You can use the generator offline once the page has loaded.
Frequently asked questions
Where do I put the service file?
Custom units go in /etc/systemd/system/yourname.service. After creating or editing it, run sudo systemctl daemon-reload so systemd re-reads units, then sudo systemctl enable --now yourname to start it and enable it at boot.
Why does my service fail with status 203/EXEC?
203/EXEC means systemd could not execute the command. The usual causes are a non-absolute path in ExecStart (use the full path like /usr/bin/node), the file not being executable, or the User lacking permission to run it. Check with systemctl status and journalctl -u yourname.
What is the difference between enable and start?
start runs the service now; enable makes it start automatically at boot by creating the WantedBy symlink. enable --now does both in one command. disable removes the boot symlink without stopping the running service.
How do I pass environment variables?
Use one or more Environment=KEY=VALUE lines in the [Service] section, which this generator adds for you. For many variables or secrets, use EnvironmentFile=/etc/yourname.env instead so they live outside the unit file with tighter permissions.
Should I use a timer or cron?
Prefer a systemd timer when you are already on systemd: it logs to the journal, supports catch-up for missed runs, and reuses service features like User and sandboxing. Cron is fine for simple recurring tasks and is more portable to non-systemd systems. The generator can output both the service and a matching timer.
Do I need WantedBy=multi-user.target?
Only if you want the service to start at boot. multi-user.target is the normal multi-user, networked, non-graphical state, the right target for servers. Without an [Install] section the service can still be started manually but will not auto-start. For timers, the install target is timers.target.
Related tools and resources
More command builders and Linux references from the same toolkit.
