Exercise 3: What Caused the Missing 18 GB — Possible Solution
====================================================================

WHAT CAUSED IT
------------------------------
Per this chapter's worked example, "lsof +L1 finds the answer
directly: a Java application still holding open a deleted 18 GB log
file - deleted by an overnight cleanup script that never told the
running process to reopen a fresh one." The cleanup script deleted the
log file's directory entry, but the running Java process still had the
file open by its original file descriptor, so the underlying disk
space was never released.

WHY DIRECTLY DELETING A LOG FILE CAUSES THIS
------------------------------
A running process that's actively writing to a log file holds an open
file handle referencing the file's actual data on disk, not just its
name. Deleting the file only removes the name (the directory entry) -
per this chapter's own finding-box, "the space is only freed once
every process holding it closed has released it." If the writing
process is never told to close and reopen its log file, it keeps
writing to the same now-nameless data, and the space keeps growing
invisibly to any directory-based tool like du.

WHY logrotate AVOIDS THIS
------------------------------
Per this chapter's tip-box, logrotate (covered in log1's own Chapter 9)
"handles this correctly" - rather than deleting a file a process still
has open, proper log rotation either renames the file and creates a
new one, or signals the application to close and reopen its log handle
after rotation, so no process is ever left writing into a deleted,
unreachable file.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the specific mechanism (a cleanup script deleting a file
still held open by a running process) using the chapter's own example,
and explains why proper log rotation tooling avoids the same outcome
by not leaving a process writing to a deleted file in the first place.