Файл удалён, но место не освободилось: диагностика с lsof
Как найти удалённые файлы, которые ещё открыты процессами, и собрать данные для безопасного освобождения места без случайной остановки сервиса.
В этой статье
Большой журнал удалили, но свободного места почти не прибавилось. В Linux это возможно: имя файла уже исчезло из каталога, а процесс продолжает держать его открытым. До закрытия последней ссылки ядра на такой объект занятые им блоки могут оставаться выделенными.
Подтвердите исходную ситуацию
Эта инструкция относится к Linux с установленной утилитой lsof. Права обычного пользователя могут ограничивать видимость чужих процессов. Если вы администрируете сервер, запускайте проверку с разрешёнными для вашей роли правами; иначе передайте задачу ответственному специалисту.
df -h /var
Запишите файловую систему и доступный объём. Путь /var приведён для примера: нужен именно тот том, на котором находился удалённый файл. Без этой привязки легко принять чужой временный файл за причину заполнения раздела сайта.
Найдите открытые файлы без имени
У lsof есть отбор по числу жёстких ссылок. Значение меньше единицы позволяет найти открытые файлы, удалённые из дерева каталогов:
lsof -nP +L1
Параметры -nP отключают преобразование сетевых адресов и портов в имена. В выводе важны процесс, его идентификатор, дескриптор, устройство и размер. Если список пуст, это может означать отсутствие таких объектов, но также недостаток прав или видимости в текущем пространстве процессов.
Не складывайте каждую строку
Один объект иногда отображается у нескольких процессов или дескрипторов. Простое суммирование всех строк завысит оценку освобождаемого объёма. Сопоставляйте устройство и inode, а также проверяйте, что объект относится к нужной файловой системе.
Надпись об удалении сама по себе не является неисправностью. Приложения могут штатно создавать временные файлы и удалять их имена, оставляя открытые дескрипторы. Важен размер, длительность удержания и связь с наблюдаемым ростом занятого места.
Следующее действие зависит от приложения
Например, веб-сервер может продолжать писать в старый журнал после неправильной ротации. В этом случае нужно проверить штатный механизм переоткрытия логов. У базы данных причина и допустимые действия будут другими. Универсальной команды, безопасно закрывающей любой найденный файл, нет.
Не завершайте процесс только потому, что он стоит в первой строке списка. Он может обслуживать текущие запросы или транзакции. Не обнуляйте файловые дескрипторы через служебные пути: такое вмешательство способно нарушить работу приложения и уничтожить данные. Передайте владельцу сервиса найденный идентификатор, размер и время наблюдения.
Проверка результата
После штатного действия, выбранного администратором, повторите lsof -nP +L1 и замер свободного места на том же разделе. Исчезновение конкретного удерживаемого объекта вместе с ростом свободного объёма подтверждает гипотезу гораздо лучше, чем сам факт перезапуска службы.
Если место не изменилось, вернитесь к другим причинам: снимкам, служебным данным файловой системы или новым записям, появившимся за время проверки. Зафиксируйте результат даже при отрицательном выводе. Это позволит следующему специалисту продолжить диагностику, а не повторять случайные удаления и перезапуски.
A large log file was deleted, but almost no free space appeared. This is possible in Linux: the file name has already disappeared from the directory, but the process continues to keep it open. Until the kernel closes the last link to such an object, the blocks occupied by it may remain allocated.
Confirm the initial situation
This instruction applies to Linux with the lsof utility installed. Standard user permissions may limit visibility of other processes. If you administer the server, run the check with permissions allowed for your role; otherwise, delegate the task to the responsible specialist.
df -h /var
Record the file system and available space. The path /var is provided as an example: you need the specific volume where the deleted file was located. Without this binding, it is easy to mistake a temporary file belonging to someone else for the cause of the site partition filling up.
Find nameless open files
lsof includes filtering by the number of hard links. A value less than one allows you to find open files that have been deleted from the directory tree:
lsof -nP +L1
The -nP parameters disable the conversion of network addresses and ports into names. The output must include the process, its identifier, the descriptor, the device, and the size. If the list is empty, this may indicate the absence of such objects, but it could also mean insufficient permissions or visibility in the current process space.
Do not simply sum every line
One object may sometimes appear for multiple processes or descriptors. Simply summing all lines will overestimate the volume of space to be freed. Match the device and inode, and verify that the object belongs to the correct file system.
The deletion label itself is not a malfunction. Applications can legitimately create temporary files and remove their names while leaving open file descriptors. What matters is the size, the duration of retention, and the correlation with the observed growth in used space.
The next action depends on the application
For example, a web server may continue writing to an old log file after an incorrect rotation. In this case, check the standard log reopening mechanism. For a database, the cause and permissible actions will differ. There is no universal command that safely closes any found file.
Do not terminate the process simply because it appears at the top of the list. It may be handling current requests or transactions. Do not zero out file descriptors via utility paths: such interference can disrupt application operation and destroy data. Pass the found identifier, size, and observation time to the service owner.
Result verification
After the standard action selected by the administrator, repeat lsof -nP +L1 and measure the free space on the same partition. The disappearance of the specific held object along with an increase in free space confirms the hypothesis much better than the mere fact of restarting the service.
If the space has not changed, return to other causes: snapshots, file system metadata, or new records created during the check. Record the result even if the outcome is negative. This allows the next specialist to continue the diagnosis rather than repeating random deletions and restarts.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.