Как будете решать проблему, если у вас коллега постоянно удаляет файлы rm rf, но файлы не исчезают и место на диске не освобождается

Диагностика и решение проблемы с rm -rf

Основываясь на вашем описании, проблема выглядит классической: исполнение команды rm -rf не приводит к освобождению места на диске, потому что удаляемые файлы на самом деле продолжают занимать пространство. Скорее всего, это происходит из-за того, что эти файлы всё ещё открыты каким-то процессом в системе. Когда процесс держит файловый дескриптор (file handle) на файл, даже после его удаления из файловой системы (посредством rm), фактическое освобождение дискового пространства произойдёт только после того, как все процессы закроют свои дескрипторы на этот файл. Удаление в данном случае лишь убирает ссылку на файл из директории.

Пошаговый план решения

1. Первичная диагностика: выявление открытых файлов

Сначала необходимо найти процессы, которые всё ещё держат открытыми удалённые файлы. Для этого в Linux есть отличный инструмент lsof (list open files). Запустим с ключом +L1, который показывает файлы с количеством ссылок меньше 1 (т.е. удалённые).

sudo lsof +L1

Если нужно сузить поиск до конкретной файловой системы (например, где коллега производил удаление), можно использовать:

sudo lsof | grep deleted

Это покажет список процессов, их PID и имена удалённых, но всё ещё открытых файлов.

2. Анализ выводов lsof и принятие решения

После выполнения команды вы получите вывод вида:

nginx     1234  www-data    5u      REG    254,1   10485760   1234567 /var/log/application.log (deleted)

Здесь:

• nginx — имя процесса.
• 1234 — его PID.
• /var/log/application.log (deleted) — удалённый, но открытый файл.

Варианты действий:

• Перезапустить процесс: Если это сервис (например, nginx, docker, приложение), который можно безопасно перезапустить, это самый чистый способ. После перезапуска все файловые дескрипторы закроются, и место освободится.

  sudo systemctl restart nginx
  

• Аварийное освобождение: Если перезапуск невозможен, можно вручную очистить файловый дескриптор, перенаправив вывод в /dev/null (для лог-файлов) или закрыть его через gdb (осторожно!). Но чаще проще и безопаснее перезапустить процесс.

3. Проверка освобождения места

После закрытия дескрипторов проверьте, освободилось ли место с помощью df:

df -h

Или для более точного анализа использования inode:

df -i

Если место не освободилось, возможно, есть и другие процессы, удерживающие файлы. Повторите анализ с lsof.

4. Автоматизация мониторинга и предотвращение проблемы

Чтобы в будущем избегать подобных ситуаций, можно предложить коллеге и команде следующие меры:

• Использование logrotate: Для лог-файлов настройте logrotate с опцией copytruncate или create, чтобы избежать необходимости удаления открытых логов вручную.
• Мониторинг дискового пространства: Внедрите систему мониторинга (например, Prometheus с node_exporter и Alertmanager), которая будет предупреждать о нехватке места до критического состояния.
• Ограничение прав: Проверьте, нет ли у коллеги избыточных прав на выполнение rm -rf в критичных директориях. Возможно, стоит ограничить использование этой команды через sudoers или перейти на более безопасные методы (например, перемещение в корзину с последующим удалением).
• Обучение и практики: Объясните механизм работы файловых дескрипторов в Linux. Предложите использовать команды du и ncdu для анализа использования диска, а не просто rm -rf.

5. Дополнительные проверки

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

• Смонтированные файловые системы: Возможно, файлы находятся в отдельном overlay (например, в Docker), и rm не влияет на основной слой.
• Процессы в контейнерах: Если используется Docker, файлы могут быть удалены внутри контейнера, но занимать место на хосте, пока контейнер работает. Решение — остановить или удалить контейнер.

  docker ps -a  # найти контейнер
  docker stop <container_id> && docker rm <container_id>
  

Резюме

Проблема, скорее всего, решается выявлением и завершением процессов, удерживающих удалённые файлы, через lsof. Далее важно внедрить превентивные меры: автоматический ротацию логов, мониторинг и обучение команды. Это не только исправит текущую ситуацию, но и снизит риски в будущем. В DevOps-культуре важно не только «тушить пожары», но и строить устойчивые системы.