Linux · medium · Core system faults

A systemd unit fails to start

The exit status in the systemctl output tells you which class of failure it was, and that narrows the cause immediately.

What you see

systemctl start reports the job failed and suggests checking journalctl. The service either never starts or restarts in a loop.

What is actually wrong

Depends on the status code: 203/EXEC means the binary is not there or is not executable, 200/CHDIR means WorkingDirectory does not exist, 226/NAMESPACE means a sandboxing directive cannot be satisfied, 1/FAILURE means the program itself exited with an error.

Codes and articles

Job for X.service failedstatus=1/FAILUREstatus=203/EXECstatus=200/CHDIRstatus=226/NAMESPACEFailed to start

Fixes (3)

Read what the unit actually said

Shell10 minuteslow riskreversible

Always start here. The status line is a summary; the journal has the program's own error.

Read the full status including the last log lines.
Shell
```
systemctl status myservice.service -l --no-pager
```
Read this boot's journal for the unit, with explanations.
Shell
```
journalctl -u myservice.service -b --no-pager -x
```
-b limits it to the current boot, which cuts out weeks of previous failures that make the real error hard to find.
If the service dies instantly, follow it live in another terminal while you start it.
Shell
```
journalctl -u myservice.service -f
```
Check the unit file for a syntax problem or a stale override.
Shell
```
systemd-analyze verify myservice.servicesystemctl cat myservice.service
```
systemctl cat shows the unit plus every drop-in override applied to it — an override in /etc/systemd/system/myservice.service.d/ is easy to forget and silently wins.
After editing any unit file, reload the manager before trying again.
Shell
```
sudo systemctl daemon-reloadsudo systemctl restart myservice.service
```

Confirm it workedThe unit reaches active (running).

Shell

systemctl is-active myservice.service

If you need to undo itNone — reading logs changes nothing.

Fix status=203/EXEC

Shell15 minuteslow riskreversible

The status is 203/EXEC. systemd could not execute the command at all.

Read the exact ExecStart line.

Shell

systemctl cat myservice.service | grep ExecStart

Check the binary exists and is executable.
Shell
```
ls -l /usr/local/bin/myappfile /usr/local/bin/myapp
```
The three usual causes are: the path is wrong, the file is not chmod +x, or it is a script whose shebang points at an interpreter that is not installed.
ExecStart must be an absolute path — systemd does not use $PATH.
Shell
```
which myapp
```
If it is a script, check the shebang and that the interpreter exists.
Shell
```
head -1 /usr/local/bin/myapp
```
Check for CRLF line endings if the script came from Windows — the shebang becomes invalid and the error looks identical.
Shell
```
file /usr/local/bin/myapp | grep -q CRLF && sudo sed -i 's/\r$//' /usr/local/bin/myapp
```

Make it executable if it is not.

Shell

sudo chmod +x /usr/local/bin/myappsudo systemctl daemon-reload && sudo systemctl start myservice

Confirm it workedThe unit starts.

Shell

systemctl is-active myservice.service

If you need to undo itNone.

Fix a sandboxing or working directory failure

Shell20 minuteslow riskreversible

Status 226/NAMESPACE or 200/CHDIR.

Find the directive at fault.

Shell

systemctl cat myservice.service | grep -E 'WorkingDirectory|ReadWritePaths|ProtectSystem|ProtectHome|PrivateTmp|StateDirectory'

For 200/CHDIR, create the directory or correct the path.

Shell

sudo mkdir -p /var/lib/myapp && sudo chown myapp:myapp /var/lib/myapp

For 226/NAMESPACE, the usual cause is ReadWritePaths naming a path that does not exist.
Shell
```
systemctl show myservice.service -p ReadWritePaths
```
systemd refuses to build the mount namespace if a listed path is missing, and the resulting error says nothing about which one.
Prefer StateDirectory= over hand-made directories — systemd creates it with the right ownership automatically.
Shell
```
sudo systemctl edit myservice.service
```

Reload and retry.

Shell

sudo systemctl daemon-reload && sudo systemctl start myservice

Confirm it workedThe unit starts and the sandbox is applied.

Shell

systemd-analyze security myservice.service

If you need to undo itsudo systemctl revert myservice.service removes drop-in overrides you added.

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.