TGViewer
DevOps Ready | IT DevOps Ready | IT @devops_ready · 7.62K subscribers
Post #1127 1.14K
Разбираемся с диагностикой утечек дискового пространства!

Иногда сервер начинает терять свободное место, но при этом du не показывает ничего критичного. Один из типовых сценариев — удалённые файлы, которые продолжают удерживаться процессами.

С точки зрения Linux файл уже удалён из дерева каталогов, но inode и блоки остаются заняты, пока хотя бы один процесс держит файловый дескриптор открытым.

Базовая проверка состояния диска:
df -h


Это первый шаг — смотрим, есть ли реальное заполнение файловой системы. Если раздел почти полный, а по каталогам картина не бьётся с ожиданиями, дальше имеет смысл копать глубже.

Сравнение с фактическим использованием:
du -xhd1 /var


-x важен: он ограничивает обход текущей файловой системой и исключает мусор с других mount points.

Если df показывает занято много, а du — нет, почти всегда это либо удалённые открытые файлы, либо редкие случаи с скрытыми mount/overlay слоями (контейнеры тоже сюда попадают).

Поиск удалённых файлов, удерживаемых процессами:
sudo lsof +L1


Здесь важный момент — +L1 означает link count < 1, то есть файл уже удалён, но ещё открыт процессом.

Типичный пример:
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NLINK NAME
java 1234 app 45w REG 8,1 12G 0 /var/log/app.log (deleted)


Файл исчез из каталога, но процесс продолжает писать в него. На практике это часто логи или временные буферы.

Быстро отфильтровать только проблемные записи:
sudo lsof +L1 | grep deleted


Удобно, когда вывода много и нужно сразу увидеть реальные утечки.

Посмотреть открытые дескрипторы процесса:
ls -l /proc/PID/fd


Каждый файл там — это активный файловый дескриптор. Если среди них есть (deleted), это и есть удерживаемое место.

Приближённая оценка объёма:
sudo lsof +L1 | awk '{print $7}' | grep -E '^[0-9]+$' | awk '{sum+=$1} END {print sum/1024/1024/1024 " GB"}'


Честно говоря, это грубая оценка. SIZE/OFF не всегда чистый байтовый формат, поэтому цифра больше для ориентира, чем для точного аудита.

Как освобождается место: самый нормальный вариант — дать процессу корректно закрыть файл:
sudo systemctl restart service_name


Если это сервис с поддержкой переоткрытия логов:
kill -HUP PID


Классический сценарий — лог-файл удалили вручную через rm, но процесс продолжает писать в уже открытый inode. В итоге место на диске исчезло, хотя файлов как будто нет.

Если df показывает заполнение, а du не объясняет куда делось место — первым делом проверяются открытые удалённые файлы через lsof +L1. Это один из самых быстрых способов найти невидимую утечку диска в Linux-системах.

🚪 Linux Ready | #практика
  • 🔥 10
  • 👍 6
  • ❤ 5
More from @devops_ready
  1. Oct 2, 2026Знали, почему настройки systemd-сервиса лучше менять через systemctl edit? Допустим, прило…
  2. Oct 2, 2026⚡️5 фундаментальных курсов по ИБ по цене одного Это предложение для тех, кто готов войти в…
  3. Oct 2, 2026Этот инструмент поможет поять из чего на самом деле состоит Docker-образ! Он содержит терм…
  4. Oct 1, 2026Проверяем итоговую конфигурацию Docker Compose перед запуском! Когда проект использует баз…
  5. Oct 1, 2026🔄 Безопасный арсенал практических инструкций, курсов и инструментов 👩‍💻 Linux & Bash 🤔…
  6. Oct 1, 2026Шпаргалка по жизненному циклу Pod в Kubernetes! На картинке показано, как запрос проходит…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →