Deleted a Linux Log but Disk Space Is Still Full? Find the Open File

You deleted a large log, the directory became smaller, but df -h still reports a full filesystem. Before deleting anything else, check whether a running process is holding the old file open.

Removing a filename does not always release its storage immediately. When the last name is removed but an open reference remains, the file can survive until that reference is closed. The unlink manual documents this behavior. An application may keep writing to a file that no longer appears in the directory.

Compare the same filesystem first

df -hT /var/log
df -i /var/log
sudo du -xhd1 /var/log

Replace /var/log with the directory where the deleted file lived. df reports the filesystem containing that path; du walks accessible files beneath the chosen directory. The -x option keeps that walk within one filesystem. A total for one directory is not supposed to equal all usage on the root filesystem. See the df and du manuals for those scopes.

The inode check answers another question: are you out of file entries rather than data blocks? Many tiny files can cause a different kind of full-disk incident. Permissions can also make a directory scan incomplete. On a busy production volume, start with the suspected mount rather than repeatedly scanning the entire tree.

Find open files without directory links

sudo lsof -nP +L1

The +L1 selection finds open files whose link count is less than one. A name ending in (deleted) is a useful lead. Read the command, PID, descriptor, device and inode together. The option is described in the lsof manual.

Not every deleted temporary file is an incident. Look for a substantial file on the filesystem that is actually short of space. The same inode may appear against multiple processes or descriptors, so summing every row can count the same data more than once. Also avoid treating SIZE/OFF as allocated physical space for every file type.

If lsof is missing, use the distribution's supported package source when there is enough space to install it. A nearly full filesystem can prevent installation too. The process-specific checks below offer another read-only view. Remember that containers and visibility restrictions can make a list incomplete; no results in one namespace are not a machine-wide guarantee.

Identify the owner before taking action

The PID below is a placeholder. Substitute the process identified in your own output:

ps -p 12345 -o pid,ppid,user,lstart,args
sudo ls -l /proc/12345/fd
sudo cat /proc/12345/cgroup

The process descriptor directory exposes references held by that process. Its cgroup membership can help trace a systemd unit or container. Check that relationship instead of restarting the first service with a similar name; several instances may be running.

Be especially careful if the owner is a database. An open deleted file might be working storage rather than an ordinary application log. If its purpose is unclear, stop here and identify it before changing the process. A deleted name does not make the underlying data disposable.

Release the reference through the application

The filename has already gone. Removing it again will not close an application's descriptor. Look for the service's documented log-reopen operation. A reload may reopen logs for one program and do nothing relevant for another. Do not send HUP merely because an unrelated service uses that signal.

If no supported reopen operation exists, a controlled restart of the owning service may be necessary. Review dependencies, disruption and its configuration check first. Killing the process with kill -9, rebooting the whole host or truncating a descriptor through /proc/PID/fd/N are not safe default troubleshooting steps. The commands in this investigation intentionally read state rather than destroying data.

For the broader problem, use the guide to Linux disk-full troubleshooting. The du and ncdu directory-size guide helps compare visible files. This particular investigation has a narrower target: storage retained by an open reference after its name disappeared.

Check space and logging separately

sudo lsof -nP +L1
df -hT /var/log

The relevant file should disappear from the open-deleted list once all references close. Check reclaimed space on the same filesystem. Concurrent writes can make the net change differ from the old file's size. Then verify that the application has created its replacement log and is writing to it. If the reference is gone but the discrepancy remains, investigate snapshots, mount layout and filesystem accounting instead of repeating the restart.