Dennis HilkLinux Fix LabDE

Kernel & System Stability

Kernel reports a task blocked for too long

Hung-task warnings identify prolonged uninterruptible waiting; inspect the wait path and preceding I/O events instead of killing the named task.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • A process stays in D state and cannot complete an operation.
  • The kernel prints INFO: task ... blocked for more than ... seconds.

Relevant environment

Linux kernels with hung-task detection, including local storage, network filesystems and device-driver waits.

Recognizable messages (synthetic examples)
INFO: task file-worker:1240 blocked in I/O wait for more than 120 seconds.

Use the following call trace to find its dependency; the task name is not a diagnosis of the underlying device or lock.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • A device or network filesystem may not complete an I/O request.
  • A kernel lock dependency can also block progress; the named task is often a waiter rather than the root cause.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read task states and wait-channel names without sending signals; some symbols may be hidden by privilege policy.

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

Interpret the result: D indicates uninterruptible wait at this instant. Multiple tasks in the same wait path can point to a shared dependency; this snapshot cannot establish a deadlock alone.

Check 2

Read likely related kernel context with administrator access if necessary; keep complete adjacent traces for diagnosis.

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

Interpret the result: A storage reset or NFS recovery before the warning may explain the wait. With no I/O evidence, inspect the complete lock-related call trace rather than assume a disk failure.

Evidence-guided next steps

Restore the identified blocking dependency

If the trace points to an unavailable network filesystem or device, restore that server, link or device through its normal recovery process and wait for pending I/O to resolve. Stop submitting new work to the affected path.

Precautions: A forced unmount or repeated SIGKILL cannot repair kernel I/O and may lose data. Do not run filesystem repair on a mounted writable filesystem.

Recovery / rollback: Return stopped workloads gradually after the dependency is healthy; undo only temporary workload routing changes.

Did this solution help you?

Share this solution#

Investigate a repeated kernel wait path

If hardware and remote dependencies are responsive but the same call trace recurs, compare a supported kernel with a relevant fix and report the full blocked-task trace. A controlled reboot can clear a deadlock after evidence and work are saved.

Precautions: Do not set hung_task_timeout_secs to zero as a repair; that suppresses evidence. A reboot is recovery, not proof of a fixed cause.

Recovery / rollback: Choose the earlier retained kernel if the new one adds failures; restore temporary boot options used for the comparison.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.