Что делать, если после удаления файлов в Linux места все равно нет

Разбор проблемы: удалил файлы, но место не освободилось

Эта классическая проблема в Linux почти всегда связана с тем, что удаленный файл все еще открыт каким-то процессом. Когда файл открыт процессом, ядро не освобождает дисковое пространство сразу после удаления через rm — вместо этого удаляется лишь запись из каталога. Физические данные на диске будут удалены только тогда, когда закроется последний дескриптор файла.

Пошаговый алгоритм диагностики и решения

1. Первичная проверка: ищем "висящие" файлы

Используйте утилиту lsof (List Open Files) для поиска удаленных, но все еще открытых файлов:

sudo lsof +L1

или более конкретный вариант:

sudo lsof | grep -i deleted

Эта команда покажет процессы, которые держат открытыми удаленные файлы. Обратите внимание на столбцы SIZE/OFF (размер файла) и NAME (где будет указано "(deleted)").

2. Анализ использования диска утилитами df и du

Часто помогает сравнение показаний df и du:

df -h              # Покажет полную файловую систему
du -sh /путь/к/диску  # Подсчитает фактический объем данных

Если df показывает 90% заполнения, а du — только 50%, это явный признак того, что место занято неучтенными ("висящими") файлами.

3. Поиск конкретных процессов и файлов

Для более детального анализа можно использовать:

# Найти все открытые удаленные файлы с указанием размера
sudo lsof -nP +L1 | awk '$5=="REG" && $9=="deleted" {print $2, $7, $9}'

# Или сгруппировать по процессам
sudo lsof -nP +L1 | grep deleted | awk '{print $2}' | sort | uniq -c | sort -n

4. Действия по освобождению места

После идентификации процессов есть несколько вариантов:

• Перезапустить процесс, удерживающий файл:

sudo kill -9 PID_процесса
# или
sudo systemctl restart имя_сервиса

• Очистить файл без перезапуска процесса (для лог-файлов):

# Найдите файловый дескриптор
ls -la /proc/PID/fd/

# Очистите содержимое файла через его дескриптор
sudo truncate -s 0 /proc/PID/fd/Номер_дескриптора

5. Альтернативные причины и их решение

Если проблема не в открытых файлах, проверьте:

• Монтирование файловых систем — убедитесь, что df показывает правильную точку монтирования
• Резервные копии и снапшоты — проверьте LVM-снапшоты или бэкапы, занимающие место
• Корзина и мусор — некоторые графические среды имеют собственную корзину (~/.local/share/Trash/)
• Журналирование файловой системы — для ext3/ext4 можно проверить журнал:

sudo dumpe2fs /dev/sdX | grep -i journal

Профилактика проблемы

1. Используйте логическую ротацию логов с помощью logrotate
2. При удалении больших файлов сначала убедитесь, что они не используются:

fuser файл_который_удаляете

1. Для критически важных процессов предусмотрите механизм SIGHUP для переоткрытия логов
2. Регулярно мониторьте дисковое пространство скриптами или системами мониторинга (Prometheus, Zabbix)

Практический пример

Представьте ситуацию: Apache держит открытым лог-файл 20 ГБ. Вы удалили файл access.log, но место не освободилось. Решение:

# Находим процесс
sudo lsof | grep access.log | grep deleted
# Вывод: apache2 1234 apache 1w REG 8,1 21474836480 12345 /var/log/apache2/access.log (deleted)

# Перезапускаем Apache
sudo systemctl restart apache2

# Проверяем результат
df -h /var

Помните: никогда не перезапускайте критические продакшен-сервисы без понимания последствий. В некоторых случаях лучше запланировать перезапуск на время минимальной нагрузки или использовать механизмы безопасной очистки файлов.