Where should I place my custom systemd .service files on Linux?

Place your custom service unit files in /etc/systemd/system/ (e.g. /etc/systemd/system/myapp.service). System-managed default unit files reside in /lib/systemd/system/ and should not be edited directly.

Why must I run 'systemctl daemon-reload' after modifying a service file?

Systemd caches all unit configuration files in memory on boot. Running 'sudo systemctl daemon-reload' forces systemd to rescan the disk and reload updated configuration files into its active dependency tree.

What is the difference between Restart=always and Restart=on-failure?

Restart=always restarts the service regardless of whether it exited cleanly (exit code 0) or crashed. Restart=on-failure restarts the service only if it crashed due to an unhandled exception, fatal signal, or non-zero exit code.

How do I view live real-time logs for my systemd service?

Use journalctl with the -u (unit) and -f (follow) flags: 'sudo journalctl -u myapp.service -f -n 100'.

Linux systemd Service Unit (.service) Generator

What is Systemd and How Do Linux Service Units Work?

Systemd is the default system and service manager for modern Linux distributions (Ubuntu, Debian, Red Hat Enterprise Linux, CentOS, Rocky Linux, Fedora, Arch Linux, and SUSE). As the first process launched by the Linux kernel (Process ID 1 / PID 1), systemd is responsible for initializing system components, managing daemon lifecycles, tracking process groups via Linux control groups (cgroups), and automatically restarting crashed applications.

A systemd Service Unit file (ending with .service) is a declarative configuration file that defines how background applications should be started, monitored, secured, and stopped.

Anatomy of a Systemd Service Unit File

A service unit contains three core sections:

1. [Unit]

Defines metadata, human-readable descriptions, and execution dependencies (e.g. After=network.target ensures the daemon waits until networking is fully initialized).

2. [Service]

Specifies the exact command (ExecStart), working directory, unprivileged execution user (User=www-data), restart behavior, and environment variables.

3. [Install]

Specifies how the unit should be enabled for auto-start at boot time (typically WantedBy=multi-user.target for standard multi-user operational runlevels).

Systemd Restart Policy Comparison Guide

Restart Directive	Restarts on Crash / Exception?	Restarts on Clean Exit (Code 0)?	Best Practice Application
Restart=always	Yes	Yes	24/7 web APIs and background worker queues that must never stop.
Restart=on-failure	Yes	No	Standard daemons that stop intentionally during planned maintenance.
Restart=on-abnormal	Yes (Signals/Timeouts only)	No	Services where fatal software exit codes require manual investigation.
Restart=no	No	No	One-shot database migration or backup scripts.

Essential systemctl & journalctl Management Commands

# Reload unit files from disk: sudo systemctl daemon-reload

# Start and enable at boot simultaneously: sudo systemctl enable --now myapp.service

# Check active process status and memory usage: sudo systemctl status myapp.service

# Restart service gracefully: sudo systemctl restart myapp.service

# Tail real-time live application stdout/stderr logs: sudo journalctl -u myapp.service -f -n 100

Frequently Asked Questions (FAQ)

Why should I never run my web application service as root?

Running web services as root means any Remote Code Execution (RCE) vulnerability in your Node.js or Python code grants an attacker full root access to your server. Always configure User=www-data or a dedicated unprivileged system account.

What does NoNewPrivileges=true do?

NoNewPrivileges=true is a Linux kernel security flag that prevents child processes spawned by your application from gaining additional root privileges (such as via SUID binaries like sudo or pkexec).

Linux systemd Service Generator

1. [Unit] Information & Dependencies

2. [Service] Execution & User

3. Environment & Security Hardening