Log Dejargonizer

systemd · Event Failed to start

Failed to start: a systemd service did not come up

systemd tried to start a service and it did not stay running. The line itself only says which unit failed — the reason is in the exit status and the unit's own log, and reading those in the right order turns a vague failure into a specific one.

Also written as Failed to startsystemd unit entered failed statesystemctl failed unitMain process exited code=exited

What it means for you

On a personal computer

A background service on this Linux machine did not start. If something has stopped working, this is likely why.

For an analyst

The one-line failure is the least informative part. `systemctl status` gives the exit code and the last few log lines, and `journalctl -u <unit>` gives the rest. Read the exit status first: a non-zero application exit is a different problem from a signal, which is a different problem from a dependency that never came up. Watch for units in a restart loop — systemd gives up after the configured burst limit and then stays quiet, which people mistake for the problem resolving.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Aug 28 09:44:12 web-01 systemd[1]: Starting nginx - high performance web server...
Aug 28 09:44:12 web-01 nginx[24960]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Aug 28 09:44:12 web-01 systemd[1]: nginx.service: Main process exited, code=exited, status=1/FAILURE
Aug 28 09:44:12 web-01 systemd[1]: nginx.service: Failed with result 'exit-code'.
Aug 28 09:44:12 web-01 systemd[1]: Failed to start nginx - high performance web server.

The fields that decide it

Everything else in the log line is context.

Unit name
Which service failed. Everything else follows from this.
Result
How systemd classifies the failure.
  • exit-codeThe process exited non-zero. An application-level error, and the exit status narrows it.
  • signalThe process was killed by a signal. SIGKILL frequently means the out-of-memory killer.
  • timeoutThe unit did not signal readiness in time. Often a slow dependency rather than a fault.
  • core-dumpThe process crashed. Look for a core file and check for a coredumpctl entry.
  • start-limit-hitsystemd stopped retrying after too many rapid restarts. The unit is now down and silent.
status=
The process exit code. 1 is a generic error; 203 usually means the executable could not be run; 226 points at a namespace or permissions problem in the unit file.
Dependency failures
Units that failed because something they required did not start. Chase the root unit, not the ones that followed it.

Ordinary reasons this happens

Most of the time it is one of these.

  • A configuration file with a syntax error after an edit.
  • A service failing at boot because the network or a mounted filesystem was not ready yet.
  • A package upgrade restarting a unit while its configuration is mid-change.
  • A unit that legitimately exits after doing its work, misconfigured as a long-running service.
  • A port already in use by another process.
  • Missing runtime dependencies after a partial installation.

When it is not ordinary

Security tooling stopped and prevented from restarting.

What gives it awayAn auditd, firewall, or endpoint agent unit failing, particularly with a masked or modified unit file.

ATT&CK T1562.001

Log forwarding disabled before other activity.

What gives it awayrsyslog, journald, or a shipping agent failing, followed by a visible gap in collected logs.

ATT&CK T1562.002

A unit file modified to run something else.

What gives it awayA familiar unit failing after its ExecStart was changed, which shows up as a missing binary or an unexpected exit code.

ATT&CK T1543.002

Resource exhaustion from unwanted software.

What gives it awayUnits killed by signal on a machine under sustained memory pressure from an unfamiliar process.

ATT&CK T1496

What to do next

  1. Run `systemctl status <unit>` first — it gives the exit code and the last log lines in one place.
  2. Then `journalctl -u <unit> -n 100 --no-pager` for the full output around the failure.
  3. Read the Result and status values before anything else. Exit code, signal, and timeout are three different investigations.
  4. For status=203, check the ExecStart path exists and is executable.
  5. For a signal, check `dmesg` for the out-of-memory killer.
  6. Check whether the unit is in a restart loop or has hit its start limit — `systemctl reset-failed` clears the latter.
  7. For security-relevant units, verify the unit file has not been modified or masked before restarting it.

Queries to run

grep Every unit currently in a failed state. The first command to run. 
systemctl --failed --no-pager
grep Full output for one unit. Replace the unit name. 
journalctl -u nginx -n 100 --no-pager -o short-precise
grep All errors from the current boot, which catches failures whose unit name you do not know yet. 
journalctl -p err -b --no-pager | head -50
grep What the unit is actually configured to do, which frequently differs from what the file on disk appears to say once drop-ins are applied. 
systemctl show nginx -p ExecStart -p Restart -p RestartSec -p StartLimitBurst
elastic 
event.dataset:"system.syslog" and process.name:"systemd" and message:"Failed to start" | stats count by host.name, message

Common questions

How do I find out why a systemd service failed?

`systemctl status <unit>` gives the exit code and the last handful of log lines, which is usually enough. If it is not, `journalctl -u <unit> -n 100 --no-pager` gives the full output. The 'Failed to start' line in syslog is only a summary — the actual error is almost always in the service's own output just above it.

What does status=203/EXEC mean?

systemd could not execute the program named in ExecStart. The usual causes are a wrong path, a missing executable, a file that is not marked executable, or a missing interpreter on the first line of a script. Check the path exists and that it runs when you invoke it directly.

Why did my service stop trying to restart?

It hit the start limit. systemd allows a set number of restarts within a time window and then stops trying, to avoid looping forever. The unit stays failed and quiet, which people mistake for the problem going away. Fix the underlying fault, then `systemctl reset-failed <unit>` and start it again.

What does 'Failed with result signal' mean?

The process was killed rather than exiting on its own. The most common cause is the kernel's out-of-memory killer — check `dmesg` for an entry naming the process. It can also be a crash, in which case `coredumpctl` may have captured something worth looking at.

Read next

Vendor documentation

Last reviewed 28 August 2026