systemd Unit File Generator

Overview

Fill in the basics - service name, executable, working directory, user, restart policy, environment variables - and the generator produces a [Unit] / [Service] / [Install] block that drops straight into /etc/systemd/system/. Optional toggles cover hardening (NoNewPrivileges, ProtectSystem, PrivateTmp) and dependency declarations (After=, Requires=).

It's for sysadmins and developers deploying services on Linux without container orchestration. Reach for it when systemd-ifying a hand-rolled application, replacing an init.d script, or producing a baseline unit that you'll iterate on with systemctl edit.

How it works

systemd unit files are INI-style with sections ([Unit], [Service], [Install]) and key=value directives. The generator emits the directives most commonly used: Description, After, ExecStart, Restart, User, Group, WorkingDirectory, EnvironmentFile, plus the standard WantedBy=multi-user.target install hook.

Output follows the conventions documented in systemd.service(5) and systemd.unit(5). The generator emits the path the unit should live at (/etc/systemd/system/<name>.service) so you know where to drop it.

Examples

• Minimal service:

  [Unit]
  Description=My service
  After=network.target
  
  [Service]
  ExecStart=/usr/local/bin/myapp
  Restart=on-failure
  User=myapp
  WorkingDirectory=/var/lib/myapp
  
  [Install]
  WantedBy=multi-user.target
  

• With environment file:

  EnvironmentFile=/etc/myapp/env
  

• Hardening flags:

  NoNewPrivileges=yes
  ProtectSystem=strict
  ProtectHome=yes
  PrivateTmp=yes
  

• Reload and enable:

  systemctl daemon-reload
  systemctl enable --now myapp.service
  

FAQ

Where does the unit file go?

/etc/systemd/system/<name>.service for user-installed units. /usr/lib/systemd/system/ is reserved for package-managed units - don't write there manually.

What's multi-user.target?

It's the equivalent of "runlevel 3" - multi-user, non-graphical. Use it as the default WantedBy target unless your service needs the graphical session.

Should I use Type=simple or Type=notify?

simple (the default) works if your binary doesn't fork. For applications that signal readiness via sd_notify (more reliable startup sequencing), use Type=notify.

How do I view logs?

journalctl -u myapp.service. Add -f to follow live, --since "1 hour ago" for time-bounded queries. systemd captures stdout/stderr by default.

Try systemd Unit File Generator