Deleting a Linux log pathname does not necessarily release its storage immediately. If a process still holds that file open, it can continue using the underlying file even though the directory entry has disappeared. Investigate the owning process and its open descriptors before deleting more files, truncating anything or restarting services. This workflow focuses on that specific cause of apparently missing disk space.
Understand the difference between a name and an open file
The Linux unlink manual explains the key condition: after the last filename link is removed, a file remains in existence while a process still has it open. Its space becomes available for reuse when the relevant open references are finally closed. Removing a pathname is therefore not the same operation as telling an application to close its log.
For example, imagine an application that opened its log before an administrator removed the filename. Creating a new empty file at the same pathname does not redirect the application’s existing descriptor. The application may keep writing to the old object. This is an explanation of a possible failure mode, not a claim that your current disk issue has that cause.
Record the affected filesystem and likely writer
Start with the filesystem that held the deleted file. The following example checks /var/log; replace it with the relevant existing directory on your system.
df -h /var/logRecord the filesystem, mount point and available space with the observation time. If the original file lived on a separate mount or inside a container, inspecting the host’s root filesystem may answer the wrong question. Avoid a large recursive scan during a storage incident unless the operational owner approves its cost.
Identify the application that owned the log using your service inventory and logging configuration. On a systemd host, this read-only example can help identify a service’s main process:
systemctl show example.service -p MainPID -p ActiveState -p SubStateReplace example.service with the real unit. A zero MainPID is not a usable process ID. Workers or a separate logging process may own the descriptor instead of the main process, so treat this as a starting point, not a complete ownership search. Do not restart a similarly named service just because its name seems plausible.
Inspect a known process without reading log contents
The proc_pid_fd manual documents /proc/PID/fd as a directory with symbolic links for the process’s open descriptors. Link targets can also represent pipes, sockets and anonymous kernel objects; not every entry is a disk file. Access is subject to process-access permission checks.
This Bash example reads the link targets for one known process. Replace 1234 only after verifying the actual process ID:
pid=1234
for fd in /proc/"$pid"/fd/*; do
[ -L "$fd" ] || continue
printf '%s -> ' "$fd"
readlink -- "$fd"
doneLook for a regular-file target corresponding to the removed log, commonly displayed with a deleted marker. Record the descriptor number and owning process. Processes can exit or close files during inspection, so disappearing entries need a fresh observation rather than an assumption of corruption. Keep filenames private if they reveal customer or application details.
A permission error does not establish that there are no open logs. Ask an authorised administrator to inspect the process; do not relax procfs or process-access protections. Avoid opening descriptor paths for their contents: logs may contain secrets, and some descriptors are not ordinary files.
Choose an application-aware release action
Finding a matching descriptor supports a diagnosis, but does not authorise a repair. Check the application’s documented log-reopen or rotation procedure with its owner. A supported reopen can close the old file and open the intended new pathname without a full restart, but the command or signal is application-specific.
If a restart is necessary, plan the outage, dependencies, health checks and recovery steps first. Never send an assumed signal or kill a process simply to release space. A restart can interrupt work, and multiple processes may hold the same file. Closing one descriptor is insufficient if other open references remain.
Do not write to or truncate /proc/PID/fd entries as a shortcut. That changes data through the open reference and can destroy evidence or interact badly with the application. Deleting the replacement log repeatedly is also not a reliable way to close an old descriptor.
Verify both storage and logging after the approved action
- Recheck the relevant process descriptors, allowing for a changed PID after restart.
- Repeat the filesystem-space check against the same mount point.
- Confirm that the application is healthy and new log records reach the intended destination.
- Record what changed and repair the rotation procedure that allowed the mismatch.
If space does not improve, investigate other holders and other storage causes rather than declaring the filesystem faulty. This explanation does not cover every difference between file-tree totals and filesystem accounting. For a related but separate journald maintenance problem, see why journalctl vacuum may not reduce disk usage as expected.
Can I undo deleting the original pathname? Do not treat this inspection workflow as a recovery procedure. If log preservation matters, stop unplanned changes and involve the storage or incident-response owner. Restarting may remove the remaining opportunity to inspect an unlinked file.
Safety: This tutorial is for educational purposes. Test procedures carefully before production use. The site owner is not responsible for misuse, damage, data loss or production issues. The inspection commands do not modify files; application reopen and restart actions require separate approval.
