Linux systemd Tutorial: Create and Manage Custom Services

Introduction

Most Linux servers run background services such as web servers, databases, APIs, and monitoring tools. These services need to start automatically, restart when they fail, and be managed consistently.

Modern Linux distributions use systemd as their service manager. It provides a standard way to start, stop, restart, and monitor applications running in the background.

Whether you're deploying a .NET application, a Python API, or a Node.js service, understanding systemd is an important skill for managing production servers.

In this tutorial, you'll learn how to create and manage custom systemd services.

What Is systemd?

systemd is a system and service manager used by most modern Linux distributions.

Its responsibilities include:

Starting services
Stopping services
Restarting failed services
Managing system boot processes
Tracking service status

Example services:

Code

Nginx
MySQL
Redis
ASP.NET Core API

These services are typically managed through systemd.

Checking Service Status

To view the status of a service:

Bash

sudo systemctl status nginx

Example output:

Code

Active: active (running)

This command shows:

Service status
Process ID
Recent logs
Startup information

Starting and Stopping Services

Start a service:

Bash

sudo systemctl start nginx

Stop a service:

Bash

sudo systemctl stop nginx

Restart a service:

Bash

sudo systemctl restart nginx

Reload configuration:

Bash

sudo systemctl reload nginx

These commands are commonly used during deployments.

Creating a Custom Service

Suppose you have a .NET application.

Application location:

Code

/var/www/myapi

Executable:

Code

MyApi.dll

Create a service file:

Bash

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

Service File Example

Add the following configuration:

Code

[Unit]
Description=My ASP.NET Core API

[Service]
WorkingDirectory=/var/www/myapi
ExecStart=/usr/bin/dotnet /var/www/myapi/MyApi.dll
Restart=always
User=www-data

[Install]
WantedBy=multi-user.target

Save the file.

This tells systemd how to run your application.

Understanding Service File Sections

Unit Section

Code

[Unit]
Description=My ASP.NET Core API

Provides information about the service.

Service Section

Code

[Service]
ExecStart=/usr/bin/dotnet MyApi.dll

Defines how the service runs.

Install Section

Code

[Install]
WantedBy=multi-user.target

Allows automatic startup during boot.

Reload systemd

After creating or modifying a service:

Bash

sudo systemctl daemon-reload

This reloads systemd configuration files.

Enable Auto Startup

Enable the service:

Bash

sudo systemctl enable myapi

Output:

Code

Created symlink

The application now starts automatically when the server boots.

Start the Service

Start the custom service:

Bash

sudo systemctl start myapi

Check status:

Bash

sudo systemctl status myapi

If everything is configured correctly:

Code

Active: active (running)

View Service Logs

systemd integrates with the journal.

View logs:

Bash

journalctl -u myapi

View live logs:

Bash

journalctl -u myapi -f

This is extremely useful for troubleshooting.

Automatic Service Restart

One of systemd's most useful features is automatic recovery.

Example:

Code

Restart=always

If the application crashes:

Code

Application Crash
       ↓
systemd Detects Failure
       ↓
Service Restarts

This improves application availability.

Real-World Example

Suppose you're hosting an ASP.NET Core API.

Without systemd:

Code

Manual Start
      ↓
Server Reboot
      ↓
Application Offline

With systemd:

Code

Server Reboot
      ↓
systemd Starts Service
      ↓
Application Online

This makes deployments more reliable.

Common Mistakes

Forgetting daemon-reload

After modifying service files:

Bash

sudo systemctl daemon-reload

must be executed.

Incorrect File Paths

Verify:

Code

WorkingDirectory
ExecStart

Incorrect paths are a common cause of failures.

Running as Root Unnecessarily

Instead of:

Code

User=root

Use a dedicated application user whenever possible.

This improves security.

Best Practices

When using systemd:

Use dedicated service accounts.
Enable automatic restart.
Store logs properly.
Use descriptive service names.
Monitor service health.
Keep service files under version control when possible.

These practices improve maintainability and reliability.

Conclusion

systemd is the standard service manager for modern Linux systems and an essential tool for running production applications. It simplifies service management by providing commands for starting, stopping, monitoring, and automatically restarting applications.

Whether you're hosting ASP.NET Core APIs, Python services, Node.js applications, or background workers, systemd ensures your applications remain available and start automatically after system reboots. Learning how to create and manage custom services is a valuable skill for developers working with Linux servers.