systemd Unit Generator
Build a .service file with [Unit], [Service] and [Install] sections, set ExecStart, Type, the user and a restart policy.
-
1Enter data
Enter content, paste text or load a file from disk. -
2Click the button
The tool will immediately process your data in the browser. -
3Get the result
Copy the finished text or save the file to your device.
return "Result ready in 0.1s";
}
Rate this tool:
Related tools
Other tools you may find usefulsystemd unit generator - a .service file for a Linux service
The systemd unit generator assembles a ready .service file from three sections: [Unit], [Service] and [Install]. Enter the service name, the ExecStart command, a user and a working directory, pick a Type and a restart policy, and the tool returns content to save under /etc/systemd/system/. Instead of screen or nohup you hand the app to systemd: it comes back after a server reboot and restarts itself after a crash.
What this tool actually produces
The service name is checked against [A-Za-z0-9_.@-] at 1-64 characters, because it lands in the /etc/systemd/system/<name>.service path. The ExecStart field is required: without a command the [Service] section has nothing to run, so the tool reports an error instead of returning an empty unit. The User, WorkingDirectory and EnvironmentFile fields appear only when you fill them in.
The [Unit] section gets a Description and After=network.target. The [Service] section carries the chosen Type, the optional environment fields, the mandatory ExecStart, the Restart policy and - except for Restart=no - a RestartSec=5 delay. The [Install] section holds WantedBy=multi-user.target, which lets systemctl enable attach the service to a normal boot.
Anatomy of a .service file
| Section / field | Syntax | Role |
|---|---|---|
[Unit] | Description=, After=network.target | Human description and start order relative to other units |
Type | Type=simple | Process model: simple, forking or oneshot |
ExecStart | ExecStart=/usr/bin/app | The start command - use a full path, systemd has no shell PATH |
Restart | Restart=always | When to bring the process back: always, on failure, or never |
User / WorkingDirectory | User=www-data | The account and directory the service runs under |
[Install] | WantedBy=multi-user.target | The target enable hooks into - autostart at boot |
Type, Restart and full paths - what to watch
Type=simple is the default model: the process must stay in the foreground. An app that daemonizes itself needs Type=forking, while a one-off task wants Type=oneshot, often with RemainAfterExit=yes. ExecStart takes a full path to the binary: systemd does not inherit PATH from your shell, so a bare php artisan ... usually ends in a No such file or directory error.
root unless you have to. Set User= to a least-privilege account and keep secrets in an EnvironmentFile with 600 permissions. The hardening option adds NoNewPrivileges=true, ProtectSystem=full, ProtectHome=true and PrivateTmp=true - if the service writes into /usr, turn ProtectSystem off.Deployment step by step
- Fill in the name, description and
ExecStartcommand, choose aTypeand a restart policy, then generate the file. - Save the contents as
/etc/systemd/system/name.service(a name with no spaces). - Reload the configuration:
sudo systemctl daemon-reload. - Enable autostart and launch the service:
sudo systemctl enable --now name. - Check the state with
systemctl status nameand follow logs live withjournalctl -u name -f.
A systemd unit rounds out the server toolchain: build the app image with the Dockerfile generator, keep repeatable commands in the Makefile generator, and schedule recurring jobs with the crontab generator. Describe a full service stack in the docker-compose generator, and web-server rules in the .htaccess file generator.
What this tool does not do
The generator creates a single long-running or one-off service. It does not build template units ([email protected]), timers, sockets or Requires/Wants dependencies - you add those by hand to the generated skeleton. It also does not check whether the ExecStart binary exists on the server.
Frequently asked questions
Why does my service fail to start?
The usual causes are a wrong path in ExecStart (systemd has no shell PATH), missing permissions on the User= account, or an unreadable EnvironmentFile. Start the diagnosis with journalctl -u name -e and systemctl status name - they show the exit code and the last log lines.
How is enable different from start?
systemctl start runs the service now, but only until the next reboot. systemctl enable creates a link in the WantedBy target (here multi-user.target), so the service comes up automatically at boot. The enable --now shortcut does both at once.
Which Type should I choose?
simple fits processes that stay in the foreground (workers, servers). Pick forking when the program daemonizes itself and releases the terminal. oneshot suits tasks that do their work and exit - often with RemainAfterExit=yes so systemd treats them as active after they finish.
How do Restart and RestartSec work?
Restart=always brings the process back after any exit, on-failure only after a non-zero exit code, and no disables restarts. RestartSec=5 is a pause before the next start, which guards against a tight restart loop. With Restart=no the tool skips RestartSec.
Can I run several copies of the same service?
Yes, through a template unit: save the file as [email protected] and start instances with systemctl start worker@1, worker@2. In ExecStart you reference the instance number with %i. This generator creates one named service - you adapt it into a template by hand.