Linux

Running Linux Services with systemd: A Practical Guide

On a modern Linux server, systemd is often the first place to look when an application should run in the background.

It manages services, startup order, dependencies, logs, and service state.

You do not need to understand every part of systemd to use it effectively.

Start with status

If an application is managed by systemd, begin with its status.

systemctl status nginx

The output normally tells you whether the service is active, when it started, and the recent log lines.

The most useful states to recognize are active, inactive, and failed.

Start and stop a service

The basic operations are predictable.

sudo systemctl start nginx
sudo systemctl stop nginx

Restarting is useful after a configuration change.

sudo systemctl restart nginx

There is also reload, which asks a service to reread configuration without fully stopping it.

sudo systemctl reload nginx

Only use reload when the service supports it.

Enable is not the same as start

This distinction catches many beginners.

start changes the current state. enable changes what happens at boot.

sudo systemctl enable nginx
sudo systemctl start nginx

You can combine the two operations when appropriate.

sudo systemctl enable --now nginx

That means enable it for future boots and start it now.

Read the journal

systemd services normally write logs to the journal.

journalctl -u nginx

For recent entries:

journalctl -u nginx -n 50

To follow new messages live:

journalctl -u nginx -f

This is often faster than guessing what a failed service is doing.

Look at the current boot

A service may have worked yesterday and failed after a reboot.

The current boot's journal can be filtered with:

journalctl -b -u nginx

For the previous boot, use -b -1.

This is especially useful after kernel, storage, or network changes.

Validate before restarting

A restart is not a configuration test.

For example, Nginx provides its own syntax check.

sudo nginx -t

Run application-specific validation first when it exists.

That way a typo is found before the currently running service is replaced by a broken configuration.

Inspect a unit

To see how a service is defined, use:

systemctl cat nginx

For a concise property view:

systemctl show nginx

The first is usually easier to read. The second is useful in scripts and troubleshooting.

Create a small custom service

Suppose you have an application at /opt/hello/hello.sh.

Make it executable:

sudo chmod +x /opt/hello/hello.sh

Create a unit file at /etc/systemd/system/hello.service.

[Unit]
Description=Hello application
After=network-online.target

[Service]
Type=simple
User=hello
ExecStart=/opt/hello/hello.sh
Restart=on-failure

[Install]
WantedBy=multi-user.target

The service should normally use a dedicated account rather than root.

After creating or editing a unit, reload systemd's configuration.

sudo systemctl daemon-reload

Then start it.

sudo systemctl enable --now hello.service

Failed services need evidence

If a service fails, collect evidence before changing several things at once.

systemctl status hello --no-pager
journalctl -u hello -b --no-pager

Look for the first meaningful error, not just the final failed message.

Common causes include a wrong path, missing permissions, unavailable environment variables, and a port already in use.

Check dependencies

A service may depend on networking, a mount, or another service.

systemctl list-dependencies nginx

This can explain why an application behaves differently during boot than when you start it manually later.

Avoid giant root services

Running an application as root can hide permission mistakes and increase the impact of a compromise.

A better service definition usually specifies a dedicated user, a working directory, explicit paths, and only the privileges the application actually needs.

The systemd workflow

A reliable workflow is simple: inspect the service, validate its configuration, start or reload it, check status, then inspect the journal if anything looks wrong.

Once that becomes routine, systemd stops being mysterious. It becomes the place where you can see exactly what should be running and why.