What's the difference between the Type= values?

'simple' (the default) assumes the process in ExecStart is the main process and doesn't fork; 'forking' expects the process to fork and the original parent to exit, with the child becoming the main process (common for older daemons); 'oneshot' runs a command to completion and doesn't stay running (typical for setup scripts); 'notify' expects the service to signal readiness via sd_notify once it's actually ready, letting systemd know precisely when startup finished rather than guessing.

What do the sandboxing toggles actually restrict?

ProtectSystem=strict mounts the entire filesystem read-only for the process except explicitly allowed paths; NoNewPrivileges=yes blocks the process (and its children) from gaining new privileges via setuid binaries or file capabilities, even if it's already running as root; PrivateTmp=yes gives the service its own private /tmp and /var/tmp, invisible to other processes on the system, closing a common local information-disclosure and symlink-attack vector.

What does RestartSec control, and why does Restart matter?

Restart= controls whether systemd restarts the service after it exits ('on-failure' only restarts after a nonzero exit or signal, 'always' restarts unconditionally, 'no' disables auto-restart), and RestartSec= is the delay systemd waits before attempting that restart, giving a crashing service a moment to avoid a tight restart loop that could pin a CPU core or hammer a dependency.

Where do I put the generated file and how do I enable it?

Save it to /etc/systemd/system/ .service, then run `systemctl daemon-reload` to make systemd notice the new unit, `systemctl enable ` to apply the [Install] WantedBy= target on boot, and `systemctl start ` to start it immediately.

systemd .service File Generator - Unit, Service, Install

Overview

Introduction

Writing a systemd unit file by hand means remembering which section a given directive belongs in, [Unit], [Service], or [Install], and which hardening options are worth turning on for a service that doesn't strictly need root.

This tool generates a complete .service file from a form: description, dependency ordering, the command to run, a restart policy, a few common sandboxing toggles, and the target it should start under.

What Is systemd Service Generator?

A systemd unit file generator covering the three sections every service unit needs: [Unit] (Description, After, Wants), [Service] (Type, ExecStart, User, Restart, RestartSec, and optional sandboxing directives), and [Install] (WantedBy).

The sandboxing toggles, ProtectSystem=strict, NoNewPrivileges=yes, and PrivateTmp=yes, are common, low-risk hardening options appropriate for most services that don't need to write outside their own data directory or gain new privileges at runtime.

How systemd Service Generator Works

After= and Wants= (in [Unit]) express ordering and soft dependency relationships to other units, systemd starts After= targets first if they're going to start anyway, without forcing them to start just because this unit wants to run.

The [Service] section's Restart= and RestartSec= together define the failure-recovery behavior, and any sandboxing toggles you enable are appended as additional directives in the same section, since they're just more systemd.exec() options scoped to this one service.

When To Use systemd Service Generator

Use it when turning a script or long-running process into a proper background service that starts on boot, restarts on crash, and is managed with systemctl instead of a shell job or a homegrown init script.

It's also useful as a quick reference for the exact directive names and section placement, since systemd unit syntax has many directives and getting the section wrong causes the file to silently do nothing.

Often used alongside Crontab Generator and Bash Script Generator.

Features

Advantages

Produces correctly sectioned unit files, avoiding the common mistake of a directive in the wrong section being silently ignored.
Surfaces three widely applicable sandboxing options as simple toggles, nudging services toward least-privilege by default.
Covers all four common Type= values with sensible defaults for Restart/RestartSec.

Limitations

Doesn't cover every systemd directive (resource limits via CPUQuota=, Environment=, etc.), only the fields most services need; add extras by hand after generating.
Sandboxing toggles are a reasonable default set, not exhaustive hardening, services with unusual filesystem or network needs may need ProtectSystem=strict paired with ReadWritePaths= exceptions this tool doesn't generate.

Examples

A hardened Node.js API service

Input

description: My API, after: network.target, type: simple, execStart: /usr/bin/node /opt/app/server.js, user: appuser, restart: on-failure, restartSec: 5, protectSystem: true, noNewPrivileges: true, privateTmp: true, wantedBy: multi-user.target

Output

[Unit]
Description=My API
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/node /opt/app/server.js
User=appuser
Restart=on-failure
RestartSec=5
ProtectSystem=strict
NoNewPrivileges=yes
PrivateTmp=yes

[Install]
WantedBy=multi-user.target

All three sandboxing toggles are enabled, and the service restarts automatically after a crash with a 5-second delay.

Best Practices & Notes

Best Practices

Run services as a dedicated non-root User= whenever the process doesn't specifically need root privileges.
Enable ProtectSystem=strict, NoNewPrivileges=yes, and PrivateTmp=yes by default, and only relax them if a service demonstrably needs broader filesystem or privilege access.
Set After=network.target (or network-online.target for services needing DNS/external connectivity at startup) so the service doesn't start before networking is available.

Developer Notes

ExecStart is validated to start with an absolute path (systemd requires this unless prefixed with a modifier character like '-' or '+', which this generator also accepts) since a relative path in ExecStart is a common and confusing source of unit failures. RestartSec is validated as a non-negative integer number of seconds; systemd itself also accepts time-unit suffixes like '5s' or '1min', but a plain integer is the least ambiguous and most portable form.

systemd Service Generator Use Cases

Turning a Node.js, Python, or Go application into a systemd-managed background service
Creating a hardened service definition for a process that doesn't need root or broad filesystem access
Producing a starting-point unit file to adapt for a specific daemon's flags and dependencies

Common Mistakes

Putting a directive in the wrong section (e.g. Restart= under [Unit] instead of [Service]), which systemd silently ignores rather than erroring on.
Forgetting `systemctl daemon-reload` after editing or adding a unit file, causing systemd to keep using its old cached view of the unit.
Using a relative path or a shell built-in in ExecStart, which fails since systemd invokes ExecStart directly, not through a shell, unless you explicitly wrap it with /bin/sh -c.

Tips

Use `systemctl status <name>` and `journalctl -u <name>` immediately after starting a new unit to confirm it actually reached the running state you expect.
Pair this with the Bash Script Generator if ExecStart should point at a custom script rather than a single binary.

systemd Service Generator