Confirm the affected filesystem and compare df with visible directory usage. Use administrative privileges only where authorized, because open-file listings can reveal private paths. Preserve any evidence needed from the retained file before closing it.

1. Run sudo lsof +L1 to locate open files whose directory links have been removed. Inspect device, size, process ID and descriptor rather than assuming every listed file is significant.
2. Map the large retained file to the affected mount and identify its owning service. Verify the PID still belongs to that process before acting, because process identifiers can be reused.
3. Determine whether the service supports reopening logs through a reload or a documented signal. Use that supported action when it closes the old descriptor safely.
4. If reopening is unsupported, schedule a controlled service restart with application impact understood. Keep the current data state and recovery requirements in mind for databases or long-running jobs.
5. Recheck open-file references and filesystem free space. Correct log rotation so the application reopens its log properly on future rotations.

On a self-managed Linux server, an administrator can inspect deleted files that processes still hold open. Run this after a disk-space alert when deleting or rotating a large log did not recover the expected space. The command does not terminate any process.

sudo lsof +L1

Read the result: Look for a regular file marked deleted, its owning COMMAND and PID, and the SIZE/OFF column. An unlinked multi-gigabyte application log can remain allocated until its last open file descriptor is closed. Several file descriptors can refer to one underlying file, so do not simply sum every displayed row.

Use the owning service documentation to arrange a controlled log reopen or restart when justified. Preserve the incident evidence first. Do not truncate a process descriptor or kill database processes merely to make the free-space figure increase.

Sometimes its open descriptor still permits an authorized copy. Preserve necessary evidence before restarting the owner, and avoid treating this possibility as a substitute for backups.

Confirm the deleted reference disappears, expected space returns and the service continues writing to its intended current log. Test a representative application request and ensure the recovery action did not interrupt unfinished work unexpectedly.

If space remains consumed, investigate other retained descriptors, snapshots or a different mount. Do not blindly kill the process, truncate an arbitrary /proc descriptor or reboot every service merely to recover space. A careful restart of the identified owner is usually easier to assess than an indiscriminate system reboot.

• Recovering service when a Linux filesystem is full
• Configuring log rotation for a custom Linux application
• Investigating a failed systemd service
• Finding which process listens on a Linux network port

• Debian manual: Lsof.8.en
• Debian manual: Logrotate.8.en