How systemd Unit Files Define Linux Services
In the Linux operating system, systemd manages system initialization,
background daemons, and processes using declarative configuration files
known as unit files. This article explains how a systemd
.service unit file defines the execution behavior, resource
environments, and lifecycle of a Linux service. It breaks down the core
sections of a unit file—[Unit], [Service], and
[Install]—and covers how these directives tell the
operating system when and how to run a program.
Location of Service Unit Files
Systemd looks for service unit files in specific directories based on their priority and purpose:
/etc/systemd/system/: System administrator-created or customized unit files. Configuration placed here takes the highest priority./run/systemd/system/: Runtime units created dynamically at boot or during operation./usr/lib/systemd/system/: Default unit files provided by upstream software packages and the Linux distribution.
Anatomy of a .service
File
A service unit file is an INI-style plain text file ending with the
.service extension. It is organized into three primary
sections: [Unit], [Service], and
[Install].
1. The [Unit] Section
The [Unit] section contains general metadata about the
service and defines its relationships and startup order relative to
other units.
Description: A human-readable title describing what the service does.Documentation: URIs pointing to documentation, man pages, or web references for the service.After: Ensures the service starts only after the specified units are loaded (e.g.,After=network.target).Before: Configures the service to start before another specified unit.Requires: Configures a hard dependency. If the required unit fails or is stopped, this service will fail or stop as well.Wants: Configures a soft dependency. Systemd will attempt to start the listed units, but this service will continue running even if they fail.
2. The [Service]
Section
The [Service] section specifies the exact configuration
for process execution, environment control, and process management.
Type: Defines the process startup behavior. Common types include:simple(default): The process specified inExecStartis the main service process.forking: The process spawns a child process and exits immediately, standard for traditional UNIX daemons.oneshot: Used for short tasks that execute and exit before systemd proceeds.notify: Similar tosimple, but the daemon sends a notification signal to systemd when it is ready.
ExecStart: The absolute path to the executable and any arguments needed to start the process.ExecStop: Commands executed to stop the service cleanly.ExecReload: Commands executed when reloading the service configuration without terminating the process.Restart: Defines under what conditions the service should automatically restart (e.g.,always,on-failure,no).RestartSec: The time to wait before attempting to restart the service.UserandGroup: Drops root privileges and runs the process under the specified system user and group for security.WorkingDirectory: Sets the working directory from which the command is executed.EnvironmentorEnvironmentFile: Defines environment variables directly or points to an external file containing key-value pairs.
3. The [Install]
Section
The [Install] section contains information used when
enabling or disabling the service via systemctl enable or
systemctl disable.
WantedBy: Specifies the target unit that should depend on this service. For example,WantedBy=multi-user.targetensures the service starts when the standard multi-user runlevel is reached.RequiredBy: Similar toWantedBy, but creates a hard dependency on the service when the specified target starts.Alias: Provides an alternative name for the service unit.
Example Service Configuration
Below is a practical example of a custom service file defined at
/etc/systemd/system/myapp.service:
[Unit]
Description=Custom Node.js Application Service
After=network.target
[Service]
Type=simple
User=appuser
Group=appuser
WorkingDirectory=/var/www/myapp
ExecStart=/usr/bin/node /var/www/myapp/server.js
Restart=on-failure
RestartSec=5s
Environment=PORT=3000
[Install]
WantedBy=multi-user.targetActivating and Managing the Service
After creating or modifying a unit file, systemd must be told to reload its configuration cache, after which standard control commands can be used:
systemctl daemon-reload: Scans for new or updated unit files.systemctl start <name>.service: Starts the service immediately.systemctl enable <name>.service: Reads the[Install]block and creates symlinks to ensure the service launches at system boot.systemctl status <name>.service: Displays the current runtime state and recent log outputs.