LFCS Operation of Running Systems Practice Question
A process is stuck in an uninterruptible sleep (D state) and cannot be killed. What is the most likely cause?
⚠ Common exam trap
Linux Foundation often tests the misconception that any 'stuck' process is due to network issues, but the D state specifically indicates block I/O, not network I/O, which uses interruptible sleep (S state).
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The process is waiting for I/O from a failing disk
A process in uninterruptible sleep (D state) is typically waiting for I/O from a block device, such as a disk. When a disk is failing or unresponsive, the kernel cannot complete the I/O request, and the process cannot be killed because doing so would risk data corruption or filesystem inconsistency. This state is a kernel-level wait that ignores signals, including SIGKILL.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The process has been stopped by a signal
Why it's wrong here
A stopped process sits in T state, not D state, so a signal explains a different symptom. It is tempting because stopped processes also ignore termination signals, and SIGCONT would be the correct remedy in that scenario rather than addressing blocked I/O.
- ✗
The process is waiting for a network response
Why it's wrong here
Network waits are interruptible, so a socket read leaves the process in S state and killable. It is tempting because network stalls do hang processes, and it would be correct when a process is blocked on a remote response but still responds to signals.
- ✓
The process is waiting for I/O from a failing disk
Why this is correct
D state means the process is blocked in an uninterruptible kernel wait, typically pending I/O completion. A failing disk never returns that I/O, so the process cannot be signalled or killed until the device responds or is reset.
- ✗
The process is waiting for CPU
Why it's wrong here
Waiting for CPU is runnable, shown as R state, not uninterruptible sleep. It is tempting because CPU contention does delay processes, and it would be correct when a process is queued for the scheduler yet remains killable and responsive to signals.
Go deeper
Related to this question
About these practice questions
One of 406 original LFCS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LFCS practice question is part of Courseiva's free Linux Foundation certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LFCS exam.