systemd Service File Generator
Turn a command into a real systemd service: fill in ExecStart, Type, User and Restart, and copy a ready unit file plus the install commands.
This systemd service file generator turns a plain command into a real service that systemd starts, stops and brings back after a crash. Fill in the fields you know, the ExecStart line, the Type, the User, the restart policy and any Environment values, and out comes a complete .service unit file along with the exact commands to drop it in place and enable it at boot. Need the job on a schedule instead, the cron way? Flip the timer switch and you also get a matching .timer with an OnCalendar line. Load a preset for a Node app, a Python worker, a Go binary or a nightly backup. Everything runs in your browser, so nothing you type ever leaves the page.
100% in your browser. Nothing you type ever leaves this page.
systemd service file generator
You've got a command. You want it to run as a real service, the kind systemd babysits. Fill in what to run, who runs it, how it should come back after a crash. Out comes a complete .service unit file and the exact commands to install it. Want it on a schedule instead, cron-style? Flip the timer on. All of it happens right here in your browser.
What a systemd service file generator does
On pretty much any Linux box you'll touch today, systemd is the thing that starts your services, stops them, and drags them back up when they die. To get your own program in on that, you write a unit file. It says what the command is, who runs it, when it kicks off, what happens when it falls over. The syntax isn't big. It's just touchy. Forget an absolute path and the thing fails without much of a peep. Same if you pick the wrong Type or skip a daemon-reload. So this generator takes plain fields and spits out a unit file that's actually correct, plus the commands to drop it in place.
Three sections, that's the whole shape of a unit file. [Unit] is the metadata and the ordering bits (Description, After, Wants). [Service] is where the real work lives: the command in ExecStart, the Type, the User, the restart policy. [Install] tells systemd what "enable this" actually means, almost always WantedBy=multi-user.target so it fires at boot. Nail those, and honestly your program just sits there next to nginx and sshd like it always belonged.
Choosing the right Type
| Type | Use when |
|---|---|
simple | Your command stays in the foreground, and that process is the service. What most apps want. |
exec | Same idea as simple, but systemd holds off on calling it "started" until the binary's actually run. A bit stricter. Solid pick on newer systemd. |
forking | The command forks, the parent quits. That's the old-school daemon dance. You'll usually need a PIDFile. |
oneshot | Runs, finishes, done. Often you'd bolt a timer onto it. Toss in RemainAfterExit=yes if it leaves some state behind. |
notify | The service pings systemd through sd_notify to say it's ready. Only some things speak this, modern web servers among them. |
Restart policy and security
Restart=on-failure brings the service back if it exits non-zero or crashes. That's the one most things should use. always goes further and restarts even on a clean exit, which fits a daemon that's never supposed to stop. Either way, set RestartSec too, or a crashing service will just hammer itself in a loop. On the security side: don't run it as root if you can help it. Give it a dedicated User, point it at a WorkingDirectory. And once the plain unit boots fine, I'd layer on the sandboxing directives, NoNewPrivileges=true and friends like ProtectSystem=strict or PrivateTmp=true. Maybe overkill for a throwaway script, but on anything real it's cheap insurance.
Services, timers and cron
A systemd timer is basically cron, redone. The trick is you take a oneshot service and pair it with a .timer unit carrying an OnCalendar line. Same concept as a cron schedule, just gentler to read (daily, or *-*-* 03:00:00). And timers can do things cron can't. Everything lands in the journal so you can actually see what ran. They'll catch up a run you missed while the box was off, if you set Persistent=true. Plus they get all the dependency and sandboxing machinery that services already have. Tick the timer box up top and you get both files.
The whole thing runs on JavaScript, in your browser. Nothing you type leaves the page, nothing gets logged anywhere. Worth knowing, because unit files tend to be full of internal paths and service names you'd rather keep to yourself.
Sources and further reading
Frequently asked questions
Where do I put the service file?
Your own units live in /etc/systemd/system/yourname.service. Made one, or just edited it? Run sudo systemctl daemon-reload first so systemd actually re-reads what is there. Then sudo systemctl enable --now yourname starts it and wires it up for boot in one go.
Why does my service fail with status 203/EXEC?
203/EXEC is systemd telling you it could not run the command at all. Nine times out of ten it is a path in ExecStart that is not absolute, so write it out in full, /usr/bin/node and so on. Or the file is not marked executable. Or the User you picked just cannot run it. Pull up systemctl status and journalctl -u yourname and the real reason is usually sitting right there.
What is the difference between enable and start?
start runs it right now, this second. enable is about boot: it drops the WantedBy symlink so the thing comes up on its own next time. People mix these up constantly. enable --now just does both at once. And disable yanks the boot symlink but leaves whatever is already running alone.
Should I use a timer or cron?
If you are already on systemd, I would just reach for a timer. You get journal logs, catch-up on missed runs, and all the service stuff like User and sandboxing comes along for free. That said, cron is not dead. It is perfectly fine for a quick recurring job, and it travels better to boxes that do not run systemd at all. The generator hands you both the service and a matching timer, so you do not have to choose blind.