LPIC-1 Devices, Filesystems and FHS Practice Question
A junior administrator accidentally deleted a large log file that is still being written to by a running process. The file no longer appears in directory listings, but `df -h` shows the filesystem is still nearly full. Which command will reclaim the space without interrupting the running process?
⚠ Common exam trap
The trap here is assuming that a deleted file immediately frees its disk space, when an open file descriptor keeps the blocks allocated until the process closes it or the file is truncated.
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
✓
truncate -s 0 /proc/<PID>/fd/<FD> using the file descriptor path
An unlinked file that remains open keeps its inode and data blocks allocated until the last descriptor closes. Truncating the file through its /proc/<PID>/fd/ descriptor zeroes the content and frees the blocks while the process continues running, satisfying the requirement of no interruption. Diagnostics like lsof help locate the descriptor, but the reclamation itself must act on the open file.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Run sync to flush dirty pages and free the deleted file's blocks
Why it's wrong here
The sync command writes buffered dirty data to disk; it does not release blocks belonging to an unlinked but open file. Those blocks stay allocated until the final file descriptor is closed, regardless of how many times data is flushed. Administrators sometimes assume syncing removes deleted files, but here it changes nothing about the space consumption.
- ✗
lsof | grep deleted, then kill the process holding the file
Why it's wrong here
Listing deleted files with lsof identifies which process holds the unlinked inode, but killing that process is disruptive and unnecessary. Terminating the process would release the space, yet it interrupts the running service, which the scenario explicitly forbids. The goal is to reclaim space without disruption, so killing the process is the wrong remedy even though the diagnostic step itself is valid.
- ✓
truncate -s 0 /proc/<PID>/fd/<FD> using the file descriptor path
Why this is correct
When a file is unlinked but still open, its data blocks remain allocated until the last file descriptor closes. Truncating through the /proc/<PID>/fd/ path empties the file content while the process keeps its descriptor open, immediately freeing the blocks. The running process continues writing from its current offset, and the filesystem space is reclaimed without any service interruption.
- ✗
Run fsck on the filesystem to release orphaned inodes
Why it's wrong here
Filesystem checking repairs metadata inconsistencies such as orphaned inodes left after a crash, but this file is not an orphan: the kernel still tracks it through an open file descriptor. Running fsck on a mounted filesystem is also unsafe and typically refused. It would not reclaim the blocks because the inode is legitimately in use, not corrupt.
Go deeper
Related to this question
About these practice questions
Courseiva writes every LPIC-1 question from scratch — 402 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official LPI exam blueprint
This LPIC-1 practice question is part of Courseiva's free LPI 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 LPIC-1 exam.