386+ Tools Comprehensive Tools for Webmasters, Developers & Site Optimization

Systemd Unit Generator - Create Linux Service Files

Systemd Unit Generator

Generate systemd service unit files for Linux services.

Name without .service extension
Full path to executable and arguments
Run service as this user
Wait time before restarting service

About Systemd

Systemd is the init system and service manager for most modern Linux distributions. It's responsible for starting services at boot, managing running services, and handling dependencies between services.

Unit File Structure

A systemd unit file is divided into sections, each serving a specific purpose:

Contains metadata and dependency information:

  • Description - Human-readable description of the service
  • After - Start after these units (e.g., network.target)
  • Requires - Hard dependency (fail if dependency fails)
  • Wants - Soft dependency (continue if dependency fails)

Defines how the service should run:

  • Type - Service type (simple, forking, oneshot, etc.)
  • ExecStart - Command to start the service
  • ExecStop - Command to stop the service (optional)
  • User - User to run service as
  • WorkingDirectory - Current directory when starting
  • Restart - Restart behavior (always, on-failure, no)
  • RestartSec - Delay before restarting

Defines installation information for enabling/disabling:

  • WantedBy - Target to attach to (usually multi-user.target)
  • RequiredBy - Units that require this service

Service Types

Type Description Use Case
simple Service stays in foreground Most common, default type
forking Service forks to background Traditional daemons
oneshot Runs once then exits Setup scripts, one-time tasks
notify Sends notification when ready Services with sd_notify support

Restart Policies

always

Always restart the service regardless of exit status. Best for critical services that should never stop.

on-failure

Restart only on failure (non-zero exit code). Good for most services.

no

Never restart. For one-time services or services you want to manage manually.

Real-World Examples

Node.js Application
[Unit]
Description=Node.js Web Application
After=network.target

[Service]
Type=simple
User=nodejs
WorkingDirectory=/var/www/myapp
ExecStart=/usr/bin/node server.js
Restart=always
RestartSec=10
Environment=NODE_ENV=production
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
Python Flask Application with Gunicorn
[Unit]
Description=Gunicorn instance to serve Flask app
After=network.target

[Service]
Type=simple
User=flask
WorkingDirectory=/var/www/flaskapp
Environment="PATH=/var/www/flaskapp/venv/bin"
ExecStart=/var/www/flaskapp/venv/bin/gunicorn --workers 3 --bind 0.0.0.0:5000 wsgi:app
Restart=always

[Install]
WantedBy=multi-user.target

Best Practices

  • Use absolute paths: Always specify full paths to executables
  • Run as non-root: Create dedicated users for services
  • Set WorkingDirectory: Ensures correct file access
  • Enable logging: Use StandardOutput=journal for systemd logging
  • Environment variables: Set with Environment= or EnvironmentFile=
  • Resource limits: Use LimitNOFILE, MemoryLimit, CPUQuota
  • Security hardening: Use PrivateTmp, ProtectSystem, NoNewPrivileges
Quick Commands

Reload systemd:

sudo systemctl daemon-reload

Start service:

sudo systemctl start myservice

Stop service:

sudo systemctl stop myservice

Restart service:

sudo systemctl restart myservice

Enable at boot:

sudo systemctl enable myservice

Check status:

sudo systemctl status myservice

View logs:

sudo journalctl -u myservice -f
Common Issues

Service fails to start:

  • Check ExecStart path is correct
  • Verify file permissions
  • Review journalctl logs

Service keeps restarting:

  • Check application logs
  • Verify dependencies are running
  • Test command manually
Related Tools