How to Check Failed Systemd Services and Units in Ubuntu Terminal

On modern Ubuntu installations, systemd acts as the central init system and service supervisor, orchestrating background daemons, network interfaces, scheduled timer jobs, and storage mounts. When a server boots into a degraded state, an Nginx web server fails to start, or a database crashes following an update, systems administrators need rapid commands to pinpoint exactly which units have broken down. In Ubuntu, systemctl provides instant filtering to list all failed system units and inspect their termination codes.

Listing All Failed Units with systemctl –failed

The quickest way to check whether any service on your Ubuntu machine is in an error state is the --failed flag:

1. Open your terminal session via Ctrl + Alt + T or connect over SSH.
2. Execute the failed units query:

   systemctl --failed

3. If any background units have crashed or failed their startup health checks, systemctl outputs a structured table:

     UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
   ● apache2.service              loaded failed failed The Apache HTTP Server
   ● [email protected]       loaded failed failed OpenVPN connection to client
   
   LOAD   = Reflects whether the unit definition was properly loaded.
   ACTIVE = The high-level unit activation state.
   SUB    = The low-level unit activation state.
   2 loaded units listed.

If your operating system is healthy with zero broken services, the terminal displays 0 loaded units listed.

Inspecting Granular Crash Telemetry with systemctl status

Once you identify the name of a failed service from the summary list, query its execution status to view the process exit code:

systemctl status apache2.service

The status report highlights essential diagnostic details:

• Main PID and Exit Code: Shows whether the process died with a standard error code (e.g. status=1/FAILURE) or was killed by a signal (e.g. SIGKILL or SIGSEGV).
• Active Duration: Details the timestamp of the crash and how long the service ran prior to failure.
• Recent Log Tail: Prints the final 10 log messages generated by the daemon immediately before terminating.

Reading Deep Crash Dumps Using journalctl

When the standard status output is truncated, invoke journalctl filtered to the specific unit to view detailed stack traces and configuration errors:

journalctl -u apache2.service -e --no-pager

The -e flag jumps directly to the end of the log buffer, allowing you to identify syntax errors in configuration files, socket port conflicts, or permission denials.

Resetting Failed State After Resolving Issues

After fixing configuration mistakes or restarting the service with sudo systemctl restart [service_name], systemd may continue to retain the unit in its failure tracking history. To reset the degraded status banner across all units:

sudo systemctl reset-failed