A service that will not start
A unit is written, and then broken four ways on purpose: a file that is not executable, a port already in use, a working directory that does not exist, and a program that fails faster than systemd will restart it. Each produces a different exit code in systemctl status, and the page begins with a start command that returned success for a service that had already failed.
Troubleshooting Guide 27 of 28 Intermediate
- OSAlmaLinux 10.2
- Kernel6.12.0-211.7.3.el10_2
- systemd257
- Mandatory access controlAppArmor on Ubuntu, SELinux enforcing on Alma
- TimeAbout 28 min
- Firewallufw / nftables 1.1.6 - firewalld / nftables 1.1.5
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| LPLUS-B01 | 192.168.0.74 | AlmaLinux 10.2 | RPM-family host - dnf, firewalld, NetworkManager, SELinux | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a service will not come up and the status output is a wall of green and red that does not obviously say why. This matters because the four causes here cover most real failures, and because the command you would naturally trust - systemctl start - returns zero for at least two of them.
- reading the
Process:line insystemctl statusfor the real exit code - recognising 203/EXEC, 200/CHDIR and an ordinary exit 1 as different faults
- knowing that
systemctl startexits 0 for aType=simpleunit that fails immediately - finding the program's own error - not systemd's - in the journal
- diagnosing a restart loop and clearing it with
systemctl reset-failed - catching a bad unit file with
systemd-analyze verifybefore starting anything
Before you start
- processes-boot-and-what-systemd-started
-
A unit that will not start
-
One bit, and what active actually proves
-
A port that is already taken
-
A working directory that is not there
-
A service that fails faster than systemd will restart it
-
Catching it before it ever starts
-
Putting the machine back