Systemd Service Generator
Build production-ready systemd unit files with a guided interface
myapp.service
Quick Reference
Service Types
- simple - Default, process stays in foreground
- forking - Traditional daemon that forks
- oneshot - Runs once and exits
- notify - Sends ready notification
Special Prefixes
- - - Ignore exit code (e.g., -/bin/rm)
- @ - Pass argv[0] separately
- + - Run with full privileges
- ! - Elevate via setuid
Specifiers
- %n - Full unit name
- %N - Unescaped unit name
- %p - Unit prefix (before @)
- %i - Instance name (after @)
Useful Commands
- systemctl status - Check status
- journalctl -u - View logs
- systemd-analyze verify - Validate
- systemctl cat - Show unit file
About This Tool
Generate systemd service unit files for running applications as system services on Linux. Supports common configurations including security hardening, resource limits, and restart policies.
Your email headers are analyzed entirely in your browser. No data is sent to any server. This tool is safe to use with sensitive or confidential email headers.
Related Tools
What is systemd?
systemd is the init system and service manager that runs as PID 1 on virtually every modern Linux distribution — Ubuntu, Debian, RHEL, CentOS, Fedora, Arch, and openSUSE all use it. As the first process started by the kernel, systemd is responsible for bringing up the entire system: mounting filesystems, starting services, managing network interfaces, and handling user sessions.
Before systemd, Linux used SysVinit with shell scripts in /etc/init.d/. These scripts were fragile, slow (they ran sequentially), and had no built-in dependency management. systemd replaced this with a declarative configuration format, parallel service startup, socket activation, automatic restart policies, and comprehensive logging via journald.
Essential systemctl commands
systemctl start nginx # Start a service
systemctl stop nginx # Stop a service
systemctl restart nginx # Restart a service
systemctl enable nginx # Start on boot
systemctl status nginx # Check status and recent logs
systemctl daemon-reload # Reload after editing unit files
journalctl -u nginx -f # Follow live logs
At NetOz, every service running on our Adelaide hosting infrastructure — from Nginx and PostgreSQL to custom application daemons — is managed by systemd. It provides consistent lifecycle management, automatic restarts on failure, and centralised logging that makes diagnosing issues straightforward.
How Unit Files Work
A systemd unit file is an INI-style configuration file that describes a resource the system manages. The most common type is a .service file, but systemd also supports timers (.timer), sockets (.socket), mount points (.mount), targets (.target), and more. Unit files live in /etc/systemd/system/ for administrator-created units or /lib/systemd/system/ for package-provided units.
Every service unit file has three main sections:
[Unit] — Metadata and Dependencies
Describes the service and defines ordering and dependency relationships with other units.
[Unit]
Description=NetOz Web Application
After=network.target postgresql.service
Wants=postgresql.service
After= controls startup order. Wants= declares soft dependencies (start if available). Requires= declares hard dependencies (fail if unavailable).
[Service] — How to Run
Defines the command to execute, the user/group to run as, environment variables, restart behaviour, and resource limits.
[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/netoz
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5
Environment=NODE_ENV=production PORT=3000
Type= tells systemd how the process signals readiness: simple (immediately), forking (daemonises), notify (sends sd_notify).
[Install] — Boot Integration
Defines what happens when you run systemctl enable — typically which target the service attaches to for boot startup.
[Install]
WantedBy=multi-user.target
multi-user.target is the standard target for non-graphical servers. graphical.target is for desktop systems.
Service Unit File Examples
Here are production-ready unit file examples for common use cases. Each includes security hardening options that restrict what the service can access on the system.
Node.js Web Application
[Unit] Description=NetOz Dashboard After=network.target [Service] Type=simple User=nodeapp WorkingDirectory=/var/www/netoz-dashboard ExecStart=/usr/bin/node dist/server.js Restart=always RestartSec=5 Environment=NODE_ENV=production Environment=PORT=3000 # Security hardening ProtectSystem=strict ProtectHome=true NoNewPrivileges=true ReadWritePaths=/var/www/netoz-dashboard/uploads [Install] WantedBy=multi-user.target
Python Background Worker
[Unit] Description=NetOz Queue Worker After=network.target redis.service Wants=redis.service [Service] Type=simple User=worker ExecStart=/opt/netoz/venv/bin/celery -A tasks worker -l info Restart=on-failure RestartSec=10 StandardOutput=journal StandardError=journal SyslogIdentifier=netoz-worker # Resource limits MemoryMax=512M CPUQuota=50% [Install] WantedBy=multi-user.target
Scheduled Task with Timer
# netoz-backup.service [Unit] Description=NetOz Database Backup [Service] Type=oneshot User=backup ExecStart=/opt/netoz/scripts/backup.sh Environment=BACKUP_DIR=/var/backups/netoz # netoz-backup.timer [Unit] Description=Run NetOz backup daily at 2am ACST [Timer] OnCalendar=*-*-* 02:00:00 Persistent=true [Install] WantedBy=timers.target
Timers are systemd's replacement for cron. Persistent=true ensures missed runs (e.g., server was off) execute on next boot.
Docker Container Service
[Unit] Description=NetOz Redis Cache After=docker.service Requires=docker.service [Service] Type=simple ExecStartPre=-/usr/bin/docker rm netoz-redis ExecStart=/usr/bin/docker run --name netoz-redis \ -p 127.0.0.1:6379:6379 \ -v redis-data:/data \ redis:7-alpine --maxmemory 256mb ExecStop=/usr/bin/docker stop netoz-redis Restart=always RestartSec=10 [Install] WantedBy=multi-user.target
ExecStartPre=- (with the - prefix) means ignore errors — the container may not exist on first run.
Always run daemon-reload after editing
After creating or modifying a unit file, run sudo systemctl daemon-reload to make systemd re-read the configuration. Then systemctl restart your-service to apply changes. Forgetting daemon-reload is one of the most common systemd mistakes.
Schedule tasks with the Cron Expression Explainer, generate web server configurations with the Web Server Config Generator, or format config files with the JSON / YAML Formatter.