Systemd Service File Explained: How to Re-Run Linux Services on Boot

Systemd is the standard initialization system and system manager across almost all modern Linux distributions. It starts system services in parallel, monitors background daemons, and manages logging. If you are deploying an API server, database proxy, or web script, understanding Systemd is essential for maintaining service uptime.

The core of Systemd configuration lies in the **Unit file**, specifically the .service file. This plain-text configuration defines how your process should start, run, crash, log, and recover.

1. The Anatomy of a Systemd Service File

A standard Systemd service configuration is divided into three primary sections: [Unit], [Service], and [Install].

[Unit] — Metadata and Dependency Chain

The Unit block describes the service and its place in the system boot sequence:

• Description: A human-readable title of your service shown in status commands.
• After: Tells Systemd to wait for specific resources (like the network interfaces or databases) to be online before launching your process.

[Service] — Execution and Lifecycle Rules

The Service block controls the exact runtime state of your process:

• ExecStart: The complete, absolute command path that executes your daemon.
• User & Group: Restricts process access levels. Never run web applications under root. Always use restricted system users configured with standard chown command limits.
• Restart=always: Instructs Systemd to automatically relaunch the process if it goes down.
• RestartSec: Tells Systemd how long to wait (e.g., 5 seconds) before attempting to spin up a crashed process.

[Install] — System Boot Hook

The Install block determines how systemctl handles the service when enabling it:

• WantedBy=multi-user.target: Specifies that this service should launch automatically when the system reaches the standard, multi-user boot state.

2. Copyable hardened Systemd template

Here is a standard, battle-tested Systemd service template optimized for security, limits, and restart metrics:

[Unit]
Description=My Application Background Service
After=network.target mysql.service

[Service]
Type=simple
User=web-admin
Group=web-admin
WorkingDirectory=/var/www/my-app
ExecStart=/usr/bin/node dist/index.js
Restart=always
RestartSec=5
Environment=PORT=8080 NODE_ENV=production
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

3. The Systemctl Command Toolkit

To load your service and test its execution parameters, run these commands in sequence:

# 1. Reload Systemd to discover the new service file
sudo systemctl daemon-reload

# 2. Start the service immediately
sudo systemctl start my-app

# 3. Enable the service to run on system boot
sudo systemctl enable my-app

# 4. View live logs and system uptime status
sudo systemctl status my-app

Frequently Asked Questions

Where are Systemd service files stored?

User-created system services are stored in /etc/systemd/system/. System-level services installed by packages reside in /lib/systemd/system/.

What does Restart=always do in a Systemd service?

The Restart=always directive instructs Systemd to automatically restart the service if the process terminates, crashes, is killed, or exits due to a timeout.

How do I make a service start automatically on boot?

Run 'sudo systemctl enable <service-name>' in your terminal. This creates symbolic links in the target directory (like multi-user.target.wants) enabling auto-start on boot.