Understanding Systemctl: How to Create & Manage Your Own Linux Services

Understanding Systemctl: How to Create & Manage Your Own Linux Services

Leader posted 3 min read

Managing processes manually on Linux can get messy—especially when you’re working on production servers, automation pipelines, or applications that need to run reliably in the background. That’s where systemctl and systemd services come in. With them, you can create fully managed, auto-restarting, long-running background services for any application you’re building.

In this guide I have broken down how systemctl works, why systemd services are powerful, and how you can create and manage your own services from scratch.

This topic came to mind recently when I needed to turn a simple script into an always-running background service. Instead of using screen, nohup, or manual commands, systemd gave me a clean, scalable solution—and it reminded me how many developers still underestimate its power.

Let’s dive in.


What is systemctl?

systemctl is the command-line tool used to control and manage systemd, the init system that boots your machine and manages services, logs, and system processes.

With it you can:

  • Start, stop, and restart services
  • Enable services to run at boot
  • Disable or mask services
  • Inspect status and logs
  • Create your own custom services

systemctl is the modern replacement for older tools like service, init.d, and Upstart.


Why Systemd Services Are Powerful

Creating your own systemd service allows you to:

  • Run scripts or apps automatically at boot
  • Restart on failure
  • Run programs in the background cleanly
  • Manage long-running apps like bots, APIs, workers, and listeners
  • Centralize logs
  • Avoid hacks like screen sessions or crontab loops

If you’re building anything that needs to run constantly—API listeners, queue workers, bots, servers—this is the cleanest way to do it.


How to Create Your Own Systemd Service

Let’s walk through it step-by-step.


1. Create a Service File

All services live in:

/etc/systemd/system/

Let’s create one:

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

Then add this:

[Unit]
Description=My Custom Linux Service
After=network.target

[Service]
ExecStart=/usr/bin/python3 /home/user/myapp.py
WorkingDirectory=/home/user
Restart=always
User=user
Environment="ENV=production"

[Install]
WantedBy=multi-user.target

What each section means:

[Unit]

Defines metadata and dependencies.

[Service]

Defines what is actually run, its user, environment variables, restart behavior, etc.

[Install]

Defines how the service integrates with system boot.

This structure works for scripts, Python apps, Node.js apps, compiled binaries, queue workers, etc.


2. Reload Systemd

Whenever you add or modify a service:

sudo systemctl daemon-reload

3. Start the Service

sudo systemctl start myapp.service

4. Check the Status

sudo systemctl status myapp.service

This will show:

  • PID
  • logs
  • errors
  • active/inactive status

5. Enable the Service at Boot

sudo systemctl enable myapp.service

Now your app starts automatically after every reboot.


6. Stop / Restart / Disable

sudo systemctl stop myapp.service
sudo systemctl restart myapp.service
sudo systemctl disable myapp.service

Managing Logs for Your Service

systemd integrates with the journal for clean, centralized log management.

View logs:

journalctl -u myapp.service

Follow logs live:

journalctl -u myapp.service -f

Clear logs:

sudo journalctl --vacuum-time=2d

Advanced Options for Production Services

You can customize services with:

✔ Restart policies

Restart=on-failure
RestartSec=5

✔ Resource limits

LimitNOFILE=10000

✔ Environment files

EnvironmentFile=/etc/myapp.env

✔ ExecStartPre (run commands before the service starts)

ExecStartPre=/usr/bin/bash /home/user/check.sh

✔ Run as a specific user or group

User=www-data
Group=www-data

✔ Timeout configurations

TimeoutStopSec=20

Systemd is extremely flexible—perfect for complex applications and enterprise environments.


Use Cases for Your Own Services

Developers typically use systemd services for:

  • Queue workers (Laravel Horizon, custom workers)
  • Node.js servers
  • Python bots and automation
  • Webhook listeners
  • Background schedulers
  • IoT device controllers
  • Backup scripts
  • Discord/Telegram bots
  • Custom APIs running on VPS
  • Docker container launchers

If it needs to run reliably… turn it into a service.


Final Thoughts: Your System, Your Rules

Understanding how systemctl and systemd services work gives you serious power over your Linux environment. Instead of relying on unstable manual processes, you can build reliable, fully-managed background services that survive reboots, restart on failure, and stay organized.

Whether you’re a DevOps engineer, backend developer, sysadmin, or someone managing VPS deployments, mastering systemd will make your automation cleaner and your applications far more stable.

And for me, this came to life again when I recently needed to convert a simple script into a background service—it reminded me why systemctl remains one of the most underrated tools in a Linux developer’s toolbox.

3 Comments

2 votes
1
2 votes
1 vote

More Posts

What Is an Availability Zone Explained Simply

Ijay - Feb 12

I’m a Senior Dev and I’ve Forgotten How to Think Without a Prompt

Karol Modelskiverified - Mar 19

Why most people quit AWS

Ijay - Feb 3

How to Reduce Your AWS Bill by 50%

rogo032 - Jan 27

How to Create a CLI Tool Using Bash: A Practical Guide for Developers

Gift Balogun - Mar 18
chevron_left

Related Jobs

View all jobs →

Commenters (This Week)

1 comment
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!