Managing Service Units

systemd service unit files define how to start, stop, and manage a background service. By mastering the structure and commonly used configuration options of unit files, you can create reliable system services for any application.

Unit File Locations

systemd searches for unit files in the following directories, from highest to lowest priority:

Path	Purpose	Priority
`/etc/systemd/system/`	Administrator-customized unit files	Highest
`/run/systemd/system/`	Dynamically generated unit files at runtime	Medium
`/usr/lib/systemd/system/`	Unit files installed by packages	Lowest

Custom services should always be placed in the /etc/systemd/system/ directory.

Unit File Structure

A standard service unit file consists of three main sections:

[Unit]
# Description and dependencies

[Service]
# Service runtime parameters

[Install]
# Installation (enable) behavior

[Unit] Section

The [Unit] section provides description information and dependency relationships for the unit. It is a common configuration section shared by all unit types.

[Unit]
Description=My Application Service
Documentation=https://example.com/docs
After=network.target
Wants=network-online.target
Requires=postgresql.service

Common directives:

Directive	Description
`Description=`	A short description of the service, displayed in `systemctl status` output
`Documentation=`	Documentation URL for reference
`After=`	Specifies startup ordering; this service starts after the specified units
`Before=`	Specifies startup ordering; this service starts before the specified units
`Requires=`	Hard dependency; this service cannot start if the specified units are not running
`Wants=`	Soft dependency; failure of the specified units does not affect this service
`BindsTo=`	Similar to Requires, but this service is also stopped when the specified unit stops

[Service] Section

The [Service] section is the core of a service unit file, defining the startup method, runtime parameters, and restart policies.

[Service]
Type=simple
ExecStart=/usr/bin/myapp --config /etc/myapp/config.yml
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill -SIGTERM $MAINPID
Restart=on-failure
RestartSec=5
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
Environment=NODE_ENV=production
EnvironmentFile=/etc/myapp/env

Type= Service Type

Type= specifies the startup method of the service and directly affects how systemd determines whether the service has started successfully:

Type	Description	Use Case
`simple` (default)	The ExecStart process is the main process	Most foreground applications
`forking`	The process forks and the parent exits; the child becomes the main process	Traditional daemons (e.g., Apache)
`oneshot`	The process runs to completion and exits; can be combined with RemainAfterExit	Initialization scripts, one-time tasks
`notify`	The service proactively notifies systemd it is ready via sd_notify()	Applications supporting sd_notify
`dbus`	The service is considered started after acquiring a D-Bus name	D-Bus services
`idle`	Similar to simple, but waits until other tasks are complete before starting	Console output-related services

Restart= Restart Policy

Value	Description
`no` (default)	Do not restart automatically
`on-success`	Restart only on clean exit (exit code 0)
`on-failure`	Restart only on abnormal exit (recommended for daemons)
`on-abnormal`	Restart on signal termination or timeout
`on-abort`	Restart on uncaught signal
`always`	Restart regardless of exit reason

Use RestartSec= to set the number of seconds to wait before restarting, preventing rapid restart loops when a service is failing.

ExecStart= Startup Command

ExecStart= defines the command to execute when the service starts. Note that absolute paths must be used:

ExecStart=/usr/bin/python3 /opt/myapp/server.py

For Type=oneshot services, you can specify multiple ExecStart= lines, which are executed sequentially.

[Install] Section

The [Install] section defines the behavior when systemctl enable is executed:

[Install]
WantedBy=multi-user.target
Alias=myapp.service

Directive	Description
`WantedBy=`	Specifies which target this service is enabled under (most commonly `multi-user.target`)
`RequiredBy=`	Similar to WantedBy, but establishes a hard dependency
`Alias=`	Creates an alias for the service

Creating a Custom Service

The following example demonstrates how to create a complete systemd service using a Go web application.

Step 1: Write the Unit File

sudo vim /etc/systemd/system/mywebapp.service

Enter the following content:

[Unit]
Description=My Go Web Application
Documentation=https://example.com/mywebapp
After=network.target
Wants=network-online.target

[Service]
Type=simple
User=webadmin
Group=webadmin
WorkingDirectory=/opt/mywebapp
ExecStart=/opt/mywebapp/mywebapp
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal
SyslogIdentifier=mywebapp

# Security hardening
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=true
PrivateTmp=true

# Resource limits
LimitNOFILE=65536
MemoryMax=512M

[Install]
WantedBy=multi-user.target

Step 2: Reload the systemd Configuration

After creating or modifying a unit file, you must notify systemd to reload its configuration:

sudo systemctl daemon-reload

Step 3: Start and Enable the Service

sudo systemctl enable --now mywebapp.service

Step 4: Verify the Service Status

sudo systemctl status mywebapp.service

sudo journalctl -u mywebapp.service -f

Overriding Existing Service Configuration

If you need to modify a service configuration installed by a package, do not edit the files under /usr/lib/systemd/system/ directly (they may be overwritten during system updates). Instead, use the drop-in override mechanism:

sudo systemctl edit nginx.service

This opens an editor and creates the file /etc/systemd/system/nginx.service.d/override.conf. For example, to add a memory limit:

[Service]
MemoryMax=1G

After saving and exiting, daemon-reload is executed automatically.

To view the complete merged configuration (original + overrides):

systemctl cat nginx.service

One-Shot Task Service Example

Some tasks only need to run once, such as system initialization scripts:

[Unit]
Description=Initialize Application Database
After=postgresql.service
Requires=postgresql.service

[Service]
Type=oneshot
ExecStart=/opt/myapp/init-db.sh
RemainAfterExit=yes
User=postgres

[Install]
WantedBy=multi-user.target

RemainAfterExit=yes means that after the process exits, the service status still shows as active, preventing other services that depend on it from being affected.

Troubleshooting Service Issues

When a service fails to start properly, follow these troubleshooting steps:

sudo systemctl status mywebapp.service -l

sudo journalctl -u mywebapp.service --no-pager -n 50

sudo systemd-analyze verify /etc/systemd/system/mywebapp.service

systemctl show mywebapp.service