systemd Service Management: Creating, Starting and Monitoring Services

On modern Linux distributions, services (programs running in the background) are managed with systemd. Starting the web server, running an application automatically when the server boots, or bringing a crashed service back up — all of it is systemd's job. This guide explains systemd service management with the systemctl and journalctl commands.

Related reading: Essential Linux server commands · Connecting to a server with SSH

What Is systemd and a Service (Unit)?

systemd is the first process to run at boot on Linux and manages all services on the system. Every entity systemd manages is called a unit; the most common unit type is the .service file — that is, programs running in the background.

A service can be started, stopped, restarted and enabled to run automatically at system boot. systemd can also automatically restart crashed services and collects each service's logs centrally.

Service Management with systemctl

You use the systemctl command to manage services. The basic operations are:

# View the service's status
systemctl status nginx

# Start / stop / restart
sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx

# Reload the configuration without downtime
sudo systemctl reload nginx

Managing Auto-Start

For a service to run automatically every time the server boots, it must be enabled. start only starts the service right now; enable makes it start at boot — the two are different.

Creating Your Own Service

You can turn your own application (for example a Node.js or Python app) into a systemd service. To do this you create a .service file in the /etc/systemd/system/ directory. A typical service file has three sections: [Unit] (description and dependencies), [Service] (how it runs) and [Install] (when it is enabled).

[Unit]
Description=Example Application
After=network.target

[Service]
User=appuser
WorkingDirectory=/opt/app
ExecStart=/usr/bin/node server.js
Restart=always

[Install]
WantedBy=multi-user.target

After creating the file, you need to make systemd aware of the new service:

# Re-read new/changed unit files
sudo systemctl daemon-reload

# Enable and start the service
sudo systemctl enable --now app

Monitoring Logs with journalctl

systemd collects all services' logs centrally; you access them with journalctl: journalctl -u nginx shows a specific service's logs, and journalctl -u nginx -f shows logs live. This is the fastest way to find out why a service will not start.

Frequently Asked Questions

What is the difference between enable and start?

start only starts the service right now; if the server reboots, the service comes up off. enable adds the service to the boot list. In production you usually want both: enable --now.

A service will not start, what should I do?

First check the summary error with systemctl status service, then inspect detailed logs with journalctl -u service. Most problems are a wrong file path, a permission error or a port conflict.

I changed the service file but it had no effect?

Every time you change a unit file you need to run sudo systemctl daemon-reload, then restart the service.