Куда могло исчезнуть дисковое пространство? (1/5)⁠⁠

В этом небольшом цикле статей будет рассмотрено несколько кейсов, происходивших в реальных инфраструктурах, с описанием их решения.

Тестовая инфраструктура, на которой будем воспроизводить проблемы состоит из виртуалки с Ubuntu 20.04, с установленным стеком LAMP и корневым разделом на 5гигов (потому что больше не понадобится).

Начало каждого инцидента одинаково — мониторинг показывает, что наш веб-сервер не отвечает или внезапно увеличился уровень ошибок.

После оповещения от мониторинга ваша задача первым делом подключиться к серверу по SSH и запустить несколько утилит, для проверки общего состояния сервера: uptime, free, ss, ps и т.д.

Удалённые файлы

Давайте взглянем на первый сценарий. Стандартная проверка для таких случаев:

Чтобы уменьшить количество выводимых данных (например чтобы убрать из вывода tmpfs или squashfs), применим опцию "-x" к df:

В любом случае здесь очевидно, что дисковое пространство полностью исчерпано. Давайте найдём виновного:

У du тоже есть полезная опция "-x", здесь она выполняет задачу исключения из вывода точек монтирования других файловых систем.

Общее пространство, занимаемое корневым разделом, составляет 4,2Gb. То есть у нас должно быть примерно 700Mb свободного места (15% от общего объема). Давайте перепроверим:

Всё так же. Значения в выводах df и du не совпадают:

Выглядит довольно запутанно. Объем свободного дискового пространства, сообщаемый df, меньше суммы размеров всех файлов. Чем же тогда занято всё место?
Оно занято удалёнными файлами.

В выводе команды lsof выше мы можем видеть, что логи сервера Apache хоть и были удалены, но всё еще заняты процессом (М.Керриск - Linux API исчерпывающее руководство, стр. 379). Особенно часто это происходит из-за неправильно настроенного logrotate. Иногда logrotate удаляет журнал, не сообщая процессу, что ему необходимо закрыть файловый дескриптор. Мы можем получить доступ к данным через /proc/$PID/fd/$DESCRIPTOR_NUMBER:

Поскольку данные всё еще там, мы можем их восстановить (кстати еще это может оказаться полезным если вы случайно удалите файлы mysql, тут только главное чтоб сервис был запущен).

Есть пара возможных вариантов решения:

1. Вы можете перезапустить сервис, и дескриптор будет освобождён.

2. Или усечь длину файла до нуля, с помощью truncate:

Проверяем:

Отлично. Проблема решена.

Заключение

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

• Тем временем какой-то другой процесс (или тот же самый) пытался удалить файл (вызвал системный вызов unlink).

• Это уменьшило счетчик ссылок в индексном дескрипторе до нуля, и файл исчез из дерева файлов.

• Однако ядро не смогло освободить блоки, поскольку всё еще существовал открытый дескриптор, ссылающийся на индексный дескриптор.

• Как итог у нас есть два возможных решения такой проблемы — обрезать файл или закрыть дескриптор.

P.S. Извиняюсь за картинки. Так и не понял, как здесь можно вставлять stdout без потери форматирования. Если кто-то в комментах подскажет - будет супер.