Inspecting Unit Status Deeply

Interpret detailed systemctl status output to identify common failure patterns.

In this lesson, you will learn how to decode the verbose output of systemctl status to pinpoint exactly why a service has failed to start.

When a service enters a failed or activating state, running systemctl status <unit_name> provides a diagnostic window into the unit’s recent history. Beyond just seeing "active (running)" or "failed," this command gives you the critical metadata needed to troubleshoot the lifecycle issues we’ve explored in previous lessons.

Analyzing the Output

When you run the command, look for these three distinct sections:

The Process Summary: This section shows the Main PID and the Tasks count. If the process is dead but the unit is "failed," check the CGroup section. If you see orphan processes still running, it suggests a failure in the service's cleanup or a double-forking issue that the service manager cannot track.
The Log Tail: systemctl status typically shows the last 10 lines of the unit's logs from the journald storage engine. This is where you identify immediate failures like "Permission denied," "Address already in use," or configuration syntax errors.
The State Metadata: Pay close attention to the Active: line. It will often provide a reason, such as result: 'exit-code' or result: 'timeout'.

Identifying Failure Patterns

If you see result: 'exit-code', the application started but crashed. You should immediately look at the ExecStart= logic or environment variables. If you see result: 'timeout', the service likely failed its Type=notify handshake or took too long to initialize, which often points to a dependency resolution or ordering issue where a required socket or target was not yet ready.

Example of a revealing status snippet:

   Active: failed (Result: exit-code) since Tue 2023-10-24 10:00:00 UTC; 5s ago
  Process: 1234 ExecStart=/usr/bin/app (code=exited, status=1/FAILURE)
 Main PID: 1234 (code=exited, status=1/FAILURE)

In this case, the status=1 tells you the application itself returned an error code, meaning the service manager successfully launched the process, but the software configuration or environment is invalid.

Key Takeaway: Use the Active: result and the terminal log lines to differentiate between a failure to launch the binary versus a runtime crash or a dependency timeout.