How to Create a systemd Service File in Linux

systemd is the init system used by most modern Linux distributions, including Ubuntu, Debian, Fedora, and RHEL. It manages system processes, handles service dependencies, and starts services automatically at boot.

A systemd service file — also called a unit file — tells systemd how to start, stop, and manage a process. This guide explains how to create a systemd service file, install it on the system, and manage it with systemctl.

Quick Reference #

Understanding systemd Unit Files #

Service files are plain text files with an .service extension. They are stored in one of two locations:

• /etc/systemd/system/ — system-wide services, managed by root. Files here take priority over package-installed units.
• /usr/lib/systemd/system/ or /lib/systemd/system/ — units installed by packages, depending on the distribution. Do not edit these directly; copy them to /etc/systemd/system/ to override.

A service file is divided into three sections:

• [Unit] — describes the service and declares dependencies.
• [Service] — defines how to start, stop, and run the process.
• [Install] — controls how and when the service is enabled.

Creating a Simple Service File #

In this example, we will create a service that runs a custom Bash script. First, create the script you want to run:

sudo nano /usr/local/bin/myapp.sh

Add the following content to the script:

#!/bin/bash
echo "myapp started" >> /var/log/myapp.log
# your application logic here
exec /usr/local/bin/myapp

Make the script executable:

sudo chmod +x /usr/local/bin/myapp.sh

Now create the service file:

sudo nano /etc/systemd/system/myapp.service

Add the following content:

[Unit]
Description=My Custom Application
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/myapp.sh
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

After saving the file, reload systemd to pick up the new unit:

sudo systemctl daemon-reload

Enable and start the service:

sudo systemctl enable --now myapp

Check that it is running:

sudo systemctl status myapp

● myapp.service - My Custom Application
Loaded: loaded (/etc/systemd/system/myapp.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2026-03-10 09:00:00 CET; 2s ago
Main PID: 1234 (myapp.sh)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/myapp.service
└─1234 /bin/bash /usr/local/bin/myapp.sh

Unit File Sections Explained #

[Unit] Section #

The [Unit] section contains metadata and dependency declarations.

Common directives:

• Description= — a short human-readable name shown in systemctl status output.
• After= — start this service only after the listed units are active. Does not create a dependency; use Requires= for hard dependencies.
• Requires= — this service requires the listed units. If they fail, this service fails too.
• Wants= — like Requires=, but the service still starts even if the listed units fail.
• Documentation= — a URL or man page reference for the service.

[Service] Section #

The [Service] section defines the process and how systemd manages it.

Common directives:

• Type= — the startup type. See Service Types
  below.
• ExecStart= — the command to run when the service starts. Must be an absolute path.
• ExecStop= — the command to run when the service stops. If omitted, systemd sends SIGTERM.
• ExecReload= — the command to reload the service configuration without restarting.
• Restart= — when to restart automatically. See Restart Policies
  below.
• RestartSec= — how many seconds to wait before restarting. Default is 100ms.
• User= — run the process as this user instead of root.
• Group= — run the process as this group.
• WorkingDirectory= — set the working directory for the process.
• Environment= — set environment variables: Environment="KEY=value".
• EnvironmentFile= — read environment variables from a file.

[Install] Section #

The [Install] section controls how the service is enabled.

• WantedBy=multi-user.target — the most common value. Enables the service for normal multi-user (non-graphical) boot.
• WantedBy=graphical.target — use this if the service requires a graphical environment.

Service Types #

The Type= directive tells systemd how the process behaves at startup.

For most custom scripts and applications, Type=simple is the right choice.

Restart Policies #

The Restart= directive controls when systemd automatically restarts the service.

For long-running services, Restart=on-failure is the most common choice. Use Restart=always for services that must stay running under all circumstances.

Running a Service as a Non-Root User #

Running services as root is a security risk. Use the User= and Group= directives to run the service as a dedicated user:

[Unit]
Description=My Custom Application
After=network.target

[Service]
Type=simple
User=myappuser
Group=myappuser
ExecStart=/usr/local/bin/myapp
Restart=on-failure
WorkingDirectory=/opt/myapp
Environment="NODE_ENV=production"

[Install]
WantedBy=multi-user.target

Create the system user before enabling the service:

sudo useradd -r -s /usr/sbin/nologin myappuser

Troubleshooting #

Service fails to start — “Failed to start myapp.service”
Check the logs with journalctl
: sudo journalctl -u myapp --since "5 minutes ago". The output shows the exact error message from the process.

Changes to the service file have no effect
You must run sudo systemctl daemon-reload after every edit to the unit file. systemd reads the file at reload time, not at start time.

“ExecStart= must be an absolute path”
The ExecStart= value must start with /. Use the full path to the binary — for example /usr/bin/python3 not python3. Use which python3 to find the absolute path.

Service starts but immediately exits
The process may be crashing on startup. Check sudo journalctl -u myapp -n 50 for error output. If Type=simple, make sure ExecStart= runs the process in the foreground — not a script that launches a background process and exits.

Service does not start at boot despite being enabled
Confirm the [Install] section has a valid WantedBy= target and that systemctl enable was run after daemon-reload. Check with systemctl is-enabled myapp.

FAQ #

Where should I put my service file?
Put custom service files in /etc/systemd/system/. Files there take priority over package-installed units in /usr/lib/systemd/system/ and persist across package upgrades.

What is the difference between enable and start?
systemctl start starts the service immediately for the current session only. systemctl enable creates a symlink so the service starts automatically at boot. To do both at once, use systemctl enable --now myservice.

How do I view logs for my service?
Use sudo journalctl -u myservice to see all logs. Add -f to follow live output, or --since "1 hour ago" to limit the time range. See the journalctl guide
for full usage.

Can I run a service as a regular user without root?
Yes, using user-level systemd units stored in ~/.config/systemd/user/. Manage them with systemctl --user enable myservice. They run when the user logs in and stop when they log out (unless lingering is enabled with loginctl enable-linger username).

How do I reload a service after changing its configuration?
If the service supports it, use sudo systemctl reload myservice — this sends SIGHUP or runs ExecReload= without restarting the process. Otherwise, use sudo systemctl restart myservice.

Conclusion #

Creating a systemd service file gives you full control over how and when your process runs — including automatic restarts, boot integration, and user isolation. Once the file is in place, use systemctl enable --now to activate it and journalctl -u
to monitor it. For scheduling tasks that run once at a set time rather than continuously, consider cron jobs
as an alternative.