Fixing Broken systemd Services, A Simple Step by Step Guide for Beginners

By Bo MorganLinux Basics

 

When a service fails to start on a Linux system, it can feel confusing and intimidating. The good news is that systemd already gives you the tools you need to find the problem and fix it in a calm, repeatable way.

This guide walks through a simple workflow you can use for almost any broken service. We will check the service state, read the error, fix the root cause, and verify that the service is healthy again. Every command and example comes directly from the teaching script you provided.

Step 1, Check the Service Status

Before you try to fix anything, you must see the current state of the service.

This tells you whether it is running, stopped, or failed.

Run:

systemctl status nginx

Example output:

● nginx.service - A high performance web server 
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled) 
   Active: failed (Result: exit-code) 
   Process: 812 ExecStart=/usr/sbin/nginx (code=exited, status=1/FAILURE)

The most important line is Active.

If it says failed, systemd tried to start the service and something went wrong.

Real-world use:

This is the first command you run when a web server, database, or monitoring agent is not working. You never guess. You always start by checking status.

Step 2, Read the Error Message Carefully

Most beginners skip the error message. This is a mistake.

The last few lines of the status output often tell you exactly what failed.

Example:

Jan 24 10:15:32 server nginx[812]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

This means port 80 is already in use.

Another program is using it.

systemd itself is not broken. The configuration or environment is wrong.

Real-world use:

This happens often when Apache and Nginx are both installed. Only one service can use port 80 at a time.

Step 3, Check Detailed Logs with journalctl

If the error is not clear, you read the service logs.

systemd stores logs in the journal.

Run:

journalctl -u nginx

Example output:

Jan 24 10:15:32 server nginx[812]: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)

This tells you the exact file that is missing.

systemd is telling you that the configuration file does not exist.

Real-world use:

This is how you debug broken services after a bad package install or after a configuration file was deleted.

Step 4, Fix the Configuration Problem

Now you fix the actual cause.

In this example, the configuration file is missing, so we reinstall the package.

Run:

sudo apt install --reinstall nginx

Example output:

Setting up nginx (1.18.0) ...

This restores the default configuration files.

You are not fixing systemd.
You are fixing what the service depends on.

Real-world use:

This is how you recover from broken installs or accidental file deletion.

Step 5, Reload systemd and Restart the Service

After fixing the problem, reload systemd and restart the service.

Run:

sudo systemctl daemon-reload

Then:

sudo systemctl restart nginx

If there is no output, the restart succeeded.

Now confirm:

systemctl status nginx

Example output:

Active: active (running)

This means the service is healthy again.

Real-world workflow:

Check status
Read logs
Fix the cause
Restart
Verify

This is the same process used on production servers.

Step 6, When a Service Is Disabled

Sometimes the service works, but does not start automatically on boot.

Check if it is enabled:

systemctl is-enabled nginx

Example output:

disabled

This means the service will not start after a reboot.

Enable and start it:

sudo systemctl enable nginx

Then:

sudo systemctl start nginx

Now the service starts now and on every boot.

Real-world use:

This is common after manual installs or when creating custom services.

Common Beginner Mistakes

Here are three mistakes to avoid.

First, running commands without sudo.
If you see permission denied, rerun the command with sudo.

Second, restarting without reading the error.
If you do not read systemctl status and journalctl, you are guessing.

Third, using the wrong service name.
Always copy the exact service name from systemctl status.

A Practical Real-World Example

A monitoring agent is not reporting data.

Check status:

systemctl status node_exporter

It shows failed.

Read logs:

journalctl -u node_exporter

You see:

bind() to 0.0.0.0:9100 failed

Another process is using port 9100.

Find it:

sudo ss -tulpn | grep 9100

Stop the conflicting process.

Restart the service:

sudo systemctl restart node_exporter

Verify:

systemctl status node_exporter

It now shows active and running.

This is real IT troubleshooting.
No magic. Just a clear process.

Optional Next Step, Verify a Service File

Once you are comfortable, you can check a service file for syntax errors.

Run:

systemd-analyze verify /lib/systemd/system/nginx.service

This checks the service file for mistakes.

This is useful when you start creating your own services.

Only try this after you are confident with the basic workflow.

Conclusion

Fixing broken systemd services is a skill you build through repetition.

You do not need advanced theory.
You need a simple process you can trust.

Check the status.
Read the logs.
Fix the root cause.
Restart and verify.

Work through this a few times, and it will start to feel natural.