LPIC-1 Devices, Filesystems and FHS Practice Question
You are a system administrator at a hosting company. A customer reports that their website hosted on a shared LAMP server is returning error 500. The server runs Ubuntu 22.04 with Apache, MySQL, and PHP. You log in and find that the /var partition (on /dev/sda3, ext4) is almost full. You identify that the MySQL database directory /var/lib/mysql contains several large binary logs that are no longer needed. You delete the binary logs using 'rm -f /var/lib/mysql/mysql-bin.*'. However, the available space does not increase. You also notice that an inode leak is suspected. You check inode usage with 'df -i' and see that the partition has plenty of free inodes. You then check with 'lsof | grep deleted' and see several entries for mysqld holding deleted files. What is the correct procedure to free the space?
⚠ Common exam trap
Watch out — candidates often assume deleting a file immediately frees disk space, overlooking that processes with open file descriptors prevent the kernel from releasing the inode and data blocks until the descriptor is closed.
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
✓
Restart the MySQL service with 'systemctl restart mysql'.
When a file is deleted while a process (like mysqld) still holds an open file descriptor to it, the file's inode remains allocated and the disk space is not freed until the process releases the descriptor. Restarting the MySQL service (systemctl restart mysql) causes mysqld to close all open file descriptors, allowing the kernel to release the deleted binary logs' inodes and reclaim the disk space.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Restart the MySQL service with 'systemctl restart mysql'.
Why this is correct
mysqld still holds open descriptors to the unlinked binary logs, so the ext4 blocks remain allocated despite the rm. Restarting MySQL closes those handles, releasing the space; free inodes confirm the issue is held descriptors, not inode exhaustion.
- ✗
Use 'dpkg --purge mysql-server' to completely remove MySQL, then reinstall it.
Why it's wrong here
Purging and reinstalling MySQL destroys the customer's databases while mysqld still holds the deleted binary logs open, so the space remains consumed until the process restarts. Package removal is for replacing or repairing software, not for releasing file descriptors held by a running daemon.
- ✗
Run 'e2fsck -f /dev/sda3' to reclaim inodes and fix filesystem inconsistencies.
Why it's wrong here
e2fsck repairs filesystem metadata and orphaned inodes; it cannot release space held by a running process's open file descriptors, and running it on a mounted /var risks corruption. It is the right tool for actual filesystem inconsistency, not for deleted-but-open files.
- ✗
Move the binary logs to a different partition using 'mv /var/lib/mysql/mysql-bin.* /tmp/' and then delete them.
Why it's wrong here
Moving files across filesystems copies then unlinks them, but mysqld still holds the originals open, so space remains allocated. The correct fix is to purge binary logs through MySQL, for example PURGE BINARY LOGS, or restart mysqld to release the deleted file handles.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 402 original LPIC-1 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 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.