Kernel meldet eine zu lange blockierte Aufgabe · Linux Fix Lab

Symptome und Geltungsbereich

Ein Prozess bleibt im Zustand D und beendet eine Operation nicht.
Der Kernel meldet INFO: task ... blocked for more than ... seconds.

Betroffene Umgebung

Linux-Kernel mit Hung-Task-Erkennung, etwa bei lokalen Datenträgern, Netzwerkdateisystemen und Wartezuständen in Gerätetreibern.

Erkennbare Meldungen (synthetische Beispiele)

INFO: task file-worker:1240 blocked in I/O wait for more than 120 seconds.

Folgende Aufrufspur zur Abhängigkeit nutzen; der Aufgabenname diagnostiziert kein zugrunde liegendes Gerät und keine Sperre.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

Ein Gerät oder Netzwerkdateisystem kann eine E/A-Anforderung nicht abschließen.
Auch eine Kernel-Sperrabhängigkeit kann Fortschritt verhindern; die genannte Aufgabe wartet oft nur und ist nicht die Ursache.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Aufgabenzustände und Namen der Wartepunkte ohne Signale lesen; manche Symbole können durch Berechtigungen verborgen sein.

ps -eo pid,ppid,stat,wchan:32,comm

Ergebnis einordnen: D zeigt in diesem Moment nicht unterbrechbares Warten. Mehrere Aufgaben im gleichen Wartepfad können eine gemeinsame Abhängigkeit zeigen; ein Snapshot allein belegt keinen Deadlock.

Prüfschritt 2

Wahrscheinlich zugehörigen Kernel-Kontext bei Bedarf mit Administratorzugriff lesen; vollständige benachbarte Spuren für die Diagnose behalten.

journalctl -b -k --no-pager --grep='blocked.*for more than|I/O error|resetting link|nvme|nfs|Call Trace'

Ergebnis einordnen: Ein Speicher-Reset oder NFS-Wiederherstellung vor der Warnung kann das Warten erklären. Ohne E/A-Hinweise die vollständige sperrbezogene Spur prüfen, statt Plattenausfall anzunehmen.

Nächste Schritte nach Befund

Ermittelte blockierende Abhängigkeit wiederherstellen

Verweist die Spur auf ein nicht verfügbares Netzwerkdateisystem oder Gerät, Server, Verbindung oder Gerät über normalen Wiederherstellungsweg zurückbringen und ausstehende E/A abwarten. Keine neue Arbeit an den betroffenen Pfad senden.

Vorsicht: Erzwungenes Aushängen oder wiederholtes SIGKILL repariert keine Kernel-E/A und kann Daten verlieren. Kein Dateisystem reparieren, das beschreibbar eingehängt ist.

Wiederherstellung / Rücknahme: Angehaltene Arbeitslasten nach gesunder Abhängigkeit schrittweise zurücknehmen; nur vorübergehende Umleitungen zurücksetzen.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Wiederholten Kernel-Wartepfad untersuchen

Sind Hardware und entfernte Abhängigkeiten erreichbar, wiederholt sich aber dieselbe Spur, einen unterstützten Kernel mit relevanter Korrektur vergleichen und vollständige Blockadespur melden. Ein kontrollierter Neustart kann einen Deadlock nach Sicherung von Belegen und Arbeit lösen.

Vorsicht: hung_task_timeout_secs nicht zur Reparatur auf null setzen; das unterdrückt Belege. Ein Neustart ist Wiederherstellung, kein Beweis einer behobenen Ursache.

Wiederherstellung / Rücknahme: Bei neuen Fehlern den vorherigen vorhandenen Kernel wählen; temporäre Boot-Optionen des Vergleichs zurückstellen.