Why did deleting a large log file fail to release disk space?
Linux can retain a deleted file’s allocated storage while a process still has it open. The pathname disappears, but the process may continue writing through its existing file descriptor. Inspect the owner before taking action; blindly killing processes or truncating their descriptors can damage application state.
Before you start
- lsof is installed and process inspection is authorised.
Instructions
1. Confirm the affected filesystem
Compare current capacity with the expected change and identify which mount was meant to gain space.
df -h /var/logMake sure the deleted file actually lived on this filesystem. Other writes can also consume space during the investigation.
2. Find unlinked files with open descriptors
Use lsof with sufficient permission to see the relevant process. Review the reported device, size and owning command against the affected application.
sudo lsof +L1+L1 selects files with link counts below one. Output may reveal private paths, so share only the required incident evidence.
3. Use the application’s supported reopen procedure
Many logging applications have a documented log-reopen signal or rotation hook. Use that method, or a planned service restart if required, after assessing request and data impact.
Check the result
- The relevant open descriptor is released, the application writes to its intended current log, and filesystem space increases as expected.
Troubleshooting
- No deleted-open file explains the difference
- Investigate snapshots, reserved space, inaccessible paths and ongoing writes.
- The same problem returns after rotation
- Review the application’s rotation/reopen integration rather than repeatedly deleting active logs.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.