How to Run Background Services with systemd

Sometimes, you need a script or program to keep running in the background on your Linux server. For example, maybe you’ve written a Python script that watches a folder or checks something every minute. You don’t want to start it manually every time the server boots up. That’s where systemd comes in.

In this post, I’ll show you how to use systemd to run your program as a background service. I’ve done this many times when setting up servers, and it really helps keep things neat and automatic.

What is systemd?

systemd is a tool used by most modern Linux systems. It starts programs when the system boots. It also manages services and processes in the background. A service is just a task or program that runs quietly behind the scenes—like a mail checker, database, or web server.

Instead of running your script using nohup or screen, you can create a systemd service. It’s easier to control. You can start, stop, or restart it with one simple command.

When Would You Use systemd?

Here are some times when systemd helps:

You have a script that needs to run all the time.
You want your program to start automatically after a reboot.
You want to check if your script is running and restart it if it fails.

For me, systemd was useful when I built a small Telegram bot. I needed it running 24/7, and I didn’t want to log in to start it each time.

Let’s Start: Example Setup

I’ll walk you through setting up a basic Python script to run as a service. You can swap it out for any program you like.

Let’s say you have a file at:

/home/yourname/myscript.py

And inside it, you have something simple like this:

# myscript.py
import time

while True:
    with open("/home/yourname/log.txt", "a") as f:
        f.write("Script is still running...\n")
    time.sleep(60)

This just logs a message every minute. Nothing fancy. But it’s a good way to test.

Step 1: Create a systemd Service File

On your server, create a new file:

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

Inside, paste this:

[Unit]
Description=My Background Script
After=network.target

[Service]
ExecStart=/usr/bin/python3 /home/yourname/myscript.py
Restart=always
User=yourname
WorkingDirectory=/home/yourname
StandardOutput=append:/home/yourname/myscript.log
StandardError=append:/home/yourname/myscript.err
Environment=PYTHONUNBUFFERED=1

[Install]
WantedBy=multi-user.target

Let me explain what these lines do:

Description is just a label.
ExecStart runs your script using Python 3.
Restart=always restarts your script if it crashes.
User tells systemd who owns the process.
WorkingDirectory is where the script runs from.
StandardOutput and StandardError save the logs.
WantedBy=multi-user.target means it starts at boot.

Step 2: Reload systemd and Start the Service

Once the file is saved, reload systemd so it knows about your new service:

sudo systemctl daemon-reexec

Then start the service:

sudo systemctl start myscript.service

You can check if it’s working:

sudo systemctl status myscript.service

If everything is okay, you’ll see a green “active (running)” line.

Step 3: Make It Start on Boot

To make the service start automatically when your server reboots:

sudo systemctl enable myscript.service

You can test this by rebooting the server:

sudo reboot

After rebooting, log in and run:

sudo systemctl status myscript.service

Still running? Great.

Step 4: View Logs and Troubleshoot

If something isn’t working, you can check logs:

journalctl -u myscript.service

Or check the output files you defined:

cat /home/yourname/myscript.log
cat /home/yourname/myscript.err

My Opinion: Why I Prefer systemd

Before I used systemd, I would keep scripts alive using screen, tmux, or nohup. But those methods are harder to manage. You don’t always know if they’re still running.

With systemd, I get:

Easy start/stop commands
Auto-restart if it crashes
Logs in one place
Auto-start after reboot

That’s more dependable. And when you’re managing servers, you want things to be reliable.

Common Questions You Might Have

What if my script uses a virtual environment?

Just update the ExecStart line to point to the Python binary inside your virtualenv. For example:

ExecStart=/home/yourname/venv/bin/python /home/yourname/myscript.py

Can I run multiple scripts with systemd?

Yes. Just create one .service file for each script. Give them different names like myscript1.service, myscript2.service, and so on.

What if my script needs environment variables?

Add this in the [Service] part:

Environment=MY_KEY=value
Environment=ANOTHER=value

You can also use EnvironmentFile=/path/to/file.env if you have lots of variables.

Three Helpful Lists

Basic systemd Commands

start: Starts your service manually
stop: Stops it
status: Shows if it’s running

Example:

sudo systemctl stop myscript.service

Problems I’ve Run Into

Wrong file paths (double check them)
Script doesn’t have permission to run (use chmod +x)
Service doesn’t restart on crash (missing Restart=always)

Benefits of Using systemd

Stable background service
Logs saved automatically
Can reboot and forget about it—it just works

Final Thoughts

Using systemd to run background tasks makes your life easier. You don’t need to babysit your scripts. I’ve used this for bots, monitors, backup jobs, and even simple web scrapers.

Try it once with a small script. Once it clicks, you’ll find systemd is really useful.

If you’re running a server, this is one of those tools that’s worth learning. Do you already have a script you want to run 24/7? This is a good time to try it.

Let me know if you run into any problems—I’ve probably seen them too.