LFCS Operation of Running Systems Practice Question
A system has a process stuck in uninterruptible sleep (D state). The administrator wants to identify which kernel function it is waiting on. Which tool should be used?
⚠ Common exam trap
Test-takers frequently confuse strace (user-space syscall tracing) with kernel stack inspection, assuming strace can show kernel internals, but strace only traces syscall entry/exit and cannot reveal the internal kernel function where the process is blocked.
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
✓
cat /proc/PID/stack
Reading /proc/PID/stack directly shows the kernel stack trace of the process, revealing the exact kernel function or wait queue the process is blocked on while in uninterruptible sleep (D state). This is the only tool listed that can inspect the kernel-side call stack without attaching a debugger or altering process state.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
cat /proc/PID/stack
Why this is correct
A task in D state is blocked inside a kernel call, and /proc/PID/stack exposes the kernel stack trace showing the exact function it sleeps in. Userspace tools such as ps or top only report the state, not the waiting function.
- ✗
gdb -p PID
Why it's wrong here
gdb attaches a debugger that interrupts the process, which cannot be done to a task in uninterruptible sleep; it inspects user-space stacks, not the kernel wait channel. It is the right tool for debugging a running user-space program's crash or logic fault.
- ✗
perf top -p PID
Why it's wrong here
perf top profiles CPU sampling across the system and shows hot functions, not the specific kernel wait channel blocking a sleeping task. It is the right choice for identifying CPU-bound hotspots and performance bottlenecks in running code.
- ✗
strace -p PID
Why it's wrong here
strace reports system calls the process makes, but a task in D state is blocked inside the kernel and issues no syscalls, so nothing is captured. It is correct for tracing syscall activity of a running or hung-in-userspace process.
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.