Linux / Bash

Linux systemd Service Status "Degraded" After Restart

A system-wide "degraded" state in systemd means at least one unit (a service, a mount, a timer) failed to start or exited with an error — it's a summary status, not a description of what specifically went wrong, and finding the actual failed unit is the necessary first step before anything can be fixed.

The Problem

Checking overall system status shows:

systemctl status
● hostname
    State: degraded
    Units: 234 loaded (...)

The system is otherwise running normally, and it's not immediately obvious which specific service or unit is responsible for the "degraded" designation without digging further.

Why It Happens

systemd reports the overall system state as "degraded" specifically when one or more units are in a failed state, even if every other unit on the system is running perfectly normally. Common reasons a specific unit ends up in this state:

  • A service crashed or exited with a non-zero status code, and either has no automatic restart configured, or exhausted its configured restart attempts without successfully staying up
  • A service that depends on a resource not yet available at the time it tried to start (a mount point, a network connection, another service) failed during boot, even though the system as a whole continued booting successfully around it
  • A one-shot service or timer-triggered task ran and genuinely failed (returned a non-zero exit code), which systemd correctly reports as a failure even though it's not a persistently running service in the traditional sense
  • A leftover failed state from a much earlier point in time that was never explicitly cleared, even if the underlying issue was already resolved

The Fix

First, identify exactly which unit(s) are actually in a failed state, rather than trying to guess from the general "degraded" status alone:

systemctl --failed

This lists every unit currently in a failed state, giving you a specific, actionable starting point instead of the vague system-wide summary.

For each failed unit listed, check its detailed status and recent logs to understand the actual underlying cause:

systemctl status your-failed-service.service
journalctl -u your-failed-service.service -n 50

The specific error shown here — a crash, a missing dependency, a configuration error — points to the actual fix needed, which varies entirely based on what that specific service does and why it failed.

Once you've identified and fixed the underlying cause (correcting a configuration file, ensuring a dependency is available, fixing a bug in a custom script the service runs), restart the service to confirm it now starts successfully:

sudo systemctl restart your-failed-service.service
systemctl status your-failed-service.service

If the underlying issue is already resolved, but the "failed" state persists because systemd hasn't automatically cleared it, explicitly reset the failed status for that specific unit:

sudo systemctl reset-failed your-failed-service.service

To reset every currently failed unit at once, rather than one at a time:

sudo systemctl reset-failed

After resetting, confirm the overall system state has returned to normal:

systemctl status
# State: running (no longer degraded)

For a service that fails intermittently rather than consistently, review its restart policy to ensure it's configured to automatically recover from transient failures without requiring manual intervention every time:

[Service]
Restart=on-failure
RestartSec=5s
StartLimitIntervalSec=60
StartLimitBurst=3

This configuration automatically restarts the service after a failure, with a brief delay, while also setting a reasonable limit on how many restart attempts happen within a given time window — preventing a genuinely broken service from restart-looping indefinitely while still recovering gracefully from occasional, transient failures.

Still Not Working?

If systemctl --failed shows no failed units at all, but the system still reports as degraded, check for failed units scoped to a specific user session rather than the system-wide scope, since these are tracked separately and won't appear in the standard system-level failed unit list:

systemctl --user --failed

A failed unit within a user's own systemd session (common with user-level services like certain desktop applications or user-configured background tasks) can also contribute to an overall degraded perception depending on how status is being checked and reported, and requires checking this separate user-scoped command to locate.

You might also like