Where do I put the file, and what do I run?

A system unit goes in /etc/systemd/system, then sudo systemctl daemon-reload and sudo systemctl enable --now name.service. A user unit goes in ~/.config/systemd/user with systemctl --user instead. Copy or download the file and the tool shows the exact commands for the one you generated.

Why does my service fail to start with a permission error after sandboxing?

Almost always because ProtectSystem=strict has made the path it writes to read-only. Add that path to ReadWritePaths. The sandbox block is a starting point rather than a verdict: start the service, read the journal, and loosen exactly what it needs.

Which Type should I choose?

simple for a process that runs in the foreground, which covers most application servers. notify if the program tells systemd when it is ready. oneshot for something that runs and exits, usually paired with a timer. forking only for a daemon that backgrounds itself, which modern services rarely do.

Generators / LOCAL TOOL

systemd Service Generator

Write a complete systemd .service file from a few fields, including the directives that only work in pairs.

Runs locally — input is never uploaded

ServiceDescribe the service

ExecStart The absolute path to the binary, with its arguments. Unit name Defaults to the executable's name. Description User Group Working directory Environment file

Type

Restart

Restart delay Seconds, or a systemd span such as 30s.

Options

Unit fileReady when you are

WHAT IT DOES

The directives that only work in pairs.

Fill in the command, the user, and the restart policy, and get a complete unit file with its [Unit], [Service], and [Install] sections. The individual directives are easy to look up; what this writes for you are the ones that have to appear together, and the combinations that start cleanly and then fail an hour later.

Why use it?

Running a program as a service involves more than its command: identity, dependencies, restart policy, and filesystem access need to agree with how it operates.

How to use this tool

Set the service identity, executable, working directory, and the options your program needs.
Generate the unit and review its dependencies and hardening restrictions, especially the paths it can write.
Save the unit and run systemd-analyze verify on the destination test host before installing or enabling it. Generation does not start the service.

Details and limitations

Waiting for the network writes both After=network-online.target and Wants=network-online.target. After on its own orders the unit behind a target that may never be pulled into the boot, which is why a service that needs the network still starts too early.
The sandbox option writes NoNewPrivileges, PrivateTmp, ProtectSystem=strict, ProtectHome, and their neighbours, and adds ReadWritePaths for the working directory, because strict makes the whole filesystem read-only and a service that writes anywhere needs that path named back.
A relative ExecStart is refused rather than written: systemd needs an absolute path, and a unit with a bare command name fails at first start.
A oneshot service with a restart policy is called out, since it is meant to run and exit and a timer is usually what was wanted.
A unit with no User= is called out too, because the default is root.
An empty field writes no directive at all, rather than an empty one, and a user unit installs into default.target instead of multi-user.target.

WORKED EXAMPLES

Separate a generated unit from a deployed service

Configure the unit for your actual executable and runtime user. Save it as example.service on a test host with systemd, then run systemd-analyze verify ./example.service before installing it.

Expected result

Verification reports unit-file problems for that host. It does not start the program or prove its permissions, secrets, network access, or dependencies are correct. Review hardening and writable paths together before enabling the service.

COMMON QUESTIONS

systemd Unit questions

Where do I put the file, and what do I run?: A system unit goes in /etc/systemd/system, then sudo systemctl daemon-reload and sudo systemctl enable --now name.service. A user unit goes in ~/.config/systemd/user with systemctl --user instead. Copy or download the file and the tool shows the exact commands for the one you generated.
Why does my service fail to start with a permission error after sandboxing?: Almost always because ProtectSystem=strict has made the path it writes to read-only. Add that path to ReadWritePaths. The sandbox block is a starting point rather than a verdict: start the service, read the journal, and loosen exactly what it needs.
Which Type should I choose?: simple for a process that runs in the foreground, which covers most application servers. notify if the program tells systemd when it is ready. oneshot for something that runs and exits, usually paired with a timer. forking only for a daemon that backgrounds itself, which modern services rarely do.