Debian/Ubuntu: как исправить LVM device is busy при lvremove и vgchange

Ошибка device is busy в LVM почти всегда означает одно: логический том всё ещё кем-то используется, даже если на первый взгляд он уже не смонтирован. Из-за этого не срабатывают lvremove, деактивация через lvchange -an или выключение группы томов через vgchange -an. В Debian и Ubuntu такое часто всплывает после миграций, очистки старых разделов, работы со снапшотами, контейнерами, chroot-окружениями и swap.

Типичные симптомы выглядят так: lvremove device is busy, Logical volume in use, vgchange failed to deactivate. Проблема неприятна не тем, что команда не работает, а тем, что попытка «додавить» удаление без диагностики легко приводит к потере данных на томе, который на самом деле ещё нужен системе.

Ниже — практический разбор, как безопасно найти источник удержания устройства, проверить, кто именно держит LVM-том, и только потом удалить или деактивировать его. Материал рассчитан на обычные серверные сценарии, в том числе на хостах с systemd, swap, Docker и сервисами баз данных. Если вы работаете на выделенном сервере или VDS, этот runbook особенно удобно держать под рукой.

Что на самом деле означает device is busy в LVM

Когда LVM пишет, что логический том занят, это не обязательно означает обычное монтирование в текущем namespace. Устройство может использоваться несколькими путями:

• том смонтирован как файловая система;
• том используется как swap;
• на томе открыт файл или каталог текущим процессом;
• устройство удерживается контейнером или другим mount namespace;
• том участвует в RAID, thin pool, snapshot, cache pool или mirror-конфигурации LVM;
• поверх него собран LUKS, mdadm, loop или другая прослойка device-mapper;
• systemd, udev или служба мониторинга ещё не отпустили дескрипторы.

Поэтому первая правильная мысль при LVM device is busy — не удалять силой, а выяснить цепочку зависимостей. В LVM почти всегда выгоднее потратить пять минут на диагностику, чем потом восстанавливать сломанный root, swap или данные приложения.

Если umount уже выполнен, это ещё не доказывает, что логический том свободен. Для LVM важен не только mount, но и открытые дескрипторы, swap, mapper-зависимости и отдельные namespace.

Базовая схема диагностики: от простого к скрытому

Лучший порядок проверки такой: сначала смотрим, что это за том и где он используется, потом проверяем mount, swap и процессы, затем — зависимости device-mapper. Именно в таком порядке быстрее всего находится источник ошибки logical volume in use.

1. Уточните имя тома и его состояние

Сначала получите полную картину по VG и LV. Часто администратор работает с коротким именем и забывает, что рядом есть снапшот, thin volume или старый mount unit.

sudo pvs
sudo vgs -o +lv_count,vg_attr
sudo lvs -a -o +devices,lv_attr,lv_size,origin,data_percent,metadata_percent

Особенно полезно поле lv_attr. По нему видно, обычный ли это том, snapshot, thin volume, origin или служебный том пула. Если вы пытаетесь удалить не отдельный data LV, а часть thin pool, ошибка будет закономерной.

2. Проверьте, смонтирован ли том

Самый очевидный шаг — найти активное монтирование. Делать это лучше не только через mount, но и через несколько источников.

findmnt
findmnt /dev/vg0/data
mount | grep vg0
cat /proc/mounts | grep vg0

Если устройство смонтировано, его нужно корректно отмонтировать. Но перед этим убедитесь, что это не рабочий том базы, логов, контейнеров или домашнего каталога. Особенно осторожно нужно действовать, если том указан в /etc/fstab и systemd автоматически его поднимает после изменений.

3. Проверьте, не используется ли том как swap

Очень частая причина, о которой вспоминают в последнюю очередь: логический том всё ещё активен как swap. При этом lvremove device is busy выглядит загадочно, если смотреть только на mount points.

swapon --show
cat /proc/swaps
lsblk -o NAME,FSTYPE,MOUNTPOINTS,SIZE

Если том используется как swap, отключайте его так:

sudo swapoff /dev/vg0/swap

После этого проверьте /etc/fstab, чтобы система не пыталась вернуть его при следующей перезагрузке или после systemctl daemon-reload. Если LVM-том создавался как временный swap на небольшом сервере, полезно заранее продумать замену, чтобы не остаться без резерва памяти.

4. Найдите процессы, которые держат устройство

Теперь переходим к классическим инструментам: lsof и fuser. Именно по этим запросам часто ищут способы понять, кто удерживает LVM-том в Debian или Ubuntu.

sudo lsof /dev/vg0/data
sudo lsof +f -- /dev/mapper/vg0-data
sudo fuser -vm /dev/vg0/data
sudo fuser -vm /dev/mapper/vg0-data

Если том был смонтирован в каталог, дополнительно проверьте саму точку монтирования:

sudo lsof +D /mnt/data
sudo fuser -vm /mnt/data

lsof хорош тем, что показывает открытые файлы и тип доступа. fuser удобен, когда нужно быстро увидеть PID. Часто виновником оказывается shell с текущей директорией внутри старого mount point, агент резервного копирования, процесс базы данных, rsync, контейнерный runtime или редактор, который держит файл на удаляемом томе.

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

5. Посмотрите дерево device-mapper

Если обычные проверки ничего не показывают, почти наверняка нужно смотреть слой device-mapper. Для этого пригодятся dmsetup и lsblk.

sudo dmsetup ls --tree
sudo dmsetup info -C
sudo lsblk -o NAME,KNAME,TYPE,FSTYPE,MOUNTPOINTS,PKNAME

Команда dmsetup ls --tree особенно полезна, когда поверх LVM-тома живёт ещё один mapper-слой: например, LUKS, thin pool, snapshot, кеширующий том или другой виртуальный блоковый девайс. В этом случае ошибка vgchange failed to deactivate возникает потому, что нижний слой пытаются выключить раньше верхнего.

Если видите цепочку вида «LUKS поверх LV» или «filesystem на mapper-устройстве, созданном из LV», сперва убирайте верхний уровень: размонтируйте файловую систему, закройте шифрованный контейнер, отключите swap, остановите сервис. Только потом деактивируйте или удаляйте сам LV.

Пошаговый runbook для lvremove device is busy

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

Шаг 1. Убедитесь, что это не системный том

Перед любыми действиями проверьте, не является ли логический том корневым, томом /var, /home, контейнерным storage или swap. На боевых серверах ошибки часто происходят просто из-за похожих имён: data, data-old, root-old, docker.

lsblk -f
findmnt -R /
cat /etc/fstab
sudo lvs -a -o lv_name,vg_name,lv_path,lv_attr

Шаг 2. Остановите сервисы, связанные с томом

Если на томе лежат данные приложения, сначала остановите сам сервис. Иначе процессы быстро переоткроют файлы, и вы получите впечатление, что устройство «само» остаётся busy.

sudo systemctl stop mysql
sudo systemctl stop postgresql
sudo systemctl stop docker
sudo systemctl stop containerd

Не нужно останавливать всё подряд. Смотрите на фактическое содержимое тома и на вывод lsof или fuser.

Шаг 3. Отмонтируйте файловую систему и отключите swap

sudo umount /mnt/data
sudo swapoff /dev/vg0/swap

Если umount сообщает, что ресурс занят, сначала вернитесь к lsof и fuser. Использовать ленивое отмонтирование стоит только тогда, когда вы точно понимаете последствия.

Шаг 4. Проверьте namespace и контейнеры

На современных Debian и Ubuntu нередка ситуация, когда в хостовой системе том уже не смонтирован, но остаётся видимым внутри контейнера или отдельного mount namespace. Особенно это касается Docker, LXC и сервисов с PrivateMounts.

sudo lsns -t mnt
sudo grep /dev/mapper/vg0-data /proc/*/mountinfo
sudo grep /mnt/data /proc/*/mountinfo

Если находите PID, смотрите, какому процессу он принадлежит:

ps -fp 1234

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

Шаг 5. Деактивируйте том

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

sudo lvchange -an /dev/vg0/data

Если команда проходит успешно, можно удалять LV:

sudo lvremove /dev/vg0/data

Если не удаётся деактивировать всю группу томов и появляется vgchange failed to deactivate, значит хотя бы один LV внутри VG ещё используется. Смотрите список активных LV и убирайте зависимость точечно, а не по всей группе сразу.

sudo lvs -a -o lv_name,lv_path,lv_attr
sudo vgchange -an vg0

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Когда виноват не mount, а скрытая зависимость

Есть несколько сценариев, где простые проверки не помогают, а причина лежит глубже.

Снапшоты и origin-тома

Если у тома есть snapshot или он сам является snapshot или origin, удалить один уровень без другого может не получиться. Это видно в lvs -a по колонкам origin и lv_attr.

Логика простая: сначала разбираетесь со снапшотами, потом с исходным томом. Особенно внимательно — на системах резервного копирования, где snapshot создаётся автоматически и не всегда корректно очищается после задания.

Thin pool и служебные тома

В thin provisioning у вас есть не только пользовательские LV, но и data и metadata-компоненты пула. Если пытаться удалять элементы в неправильном порядке, получите либо отказ, либо зависимость на уровне mapper.

В таких случаях полезно изучить атрибуты томов и увидеть иерархию через lvs -a и dmsetup ls --tree. Удаление должно идти от зависимых thin volume к пулу, а не наоборот.

LUKS поверх LVM или LVM поверх LUKS

Когда используется шифрование, легко перепутать, какой слой закрывать первым. Если LUKS открыт поверх логического тома, сначала закрывается encrypted mapper-устройство, и только потом деактивируется LV. Если же LVM находится внутри уже открытого LUKS-контейнера, порядок будет другим: сначала работа с LV внутри контейнера, потом закрытие внешнего слоя.

udev и кратковременные гонки

Иногда после деактивации или удаления томов команды всё равно некоторое время отвечают ошибками, потому что udev ещё обрабатывает события. Это не самый частый случай, но он встречается после массовых операций LVM.

sudo udevadm settle

Используйте это только как дополнительный шаг после основной диагностики, а не как замену поиску реального потребителя устройства.

Что делать, если lsof и fuser ничего не показывают

Это одна из самых неприятных ситуаций: lvremove device is busy есть, а классические инструменты молчат. Обычно причина в одном из трёх мест: другой mount namespace, mapper-зависимость или уже остановленный процесс с хвостом в systemd или udev.

В таком случае полезна следующая минимальная последовательность:

sudo findmnt -A | grep vg0
sudo swapon --show
sudo lsns -t mnt
sudo dmsetup ls --tree
sudo dmsetup info -C
sudo lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINTS,PKNAME

Если всё равно не видно причины, проверьте сообщения ядра и journal вокруг момента ошибки:

journalctl -xe --no-pager
dmesg | tail -n 100

Для production-систем это часто даёт подсказку: том держит сервис, который был автоматически перезапущен, либо device-mapper сообщает о зависимости, неочевидной из пользовательских команд.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Чего не стоит делать

При ошибках LVM есть несколько типичных антипаттернов, которые только усугубляют ситуацию.

• Не удаляйте LV, если не проверили swap, mount points и /etc/fstab.
• Не останавливайте вслепую критичные сервисы на продакшене без понимания, где лежат их данные.
• Не пытайтесь сразу деактивировать всю VG, если проблема только в одном LV.
• Не воспринимайте пустой вывод lsof как доказательство, что устройство точно свободно.
• Не путайте путь /dev/vg/lv и /dev/mapper/vg-lv: проверять желательно оба варианта.

Главное правило простое: сначала найдите, кто использует том, затем снимите зависимость штатным способом, и только после этого выполняйте lvchange -an или lvremove.

Короткий практический пример

Допустим, вы хотите удалить старый том /dev/vgdata/backup-old, но получаете Logical volume vgdata/backup-old in use.

sudo lvs -a -o lv_name,vg_name,lv_path,lv_attr
findmnt /dev/vgdata/backup-old
swapon --show
sudo lsof /dev/vgdata/backup-old
sudo fuser -vm /dev/vgdata/backup-old
sudo dmsetup ls --tree

Выясняется, что сам блочный девайс не смонтирован, но внутри старого mount namespace его использует контейнерный процесс. Тогда порядок будет таким:

1. остановить контейнер или соответствующий сервис;
2. убедиться, что запись исчезла из /proc/*/mountinfo;
3. при необходимости выполнить udevadm settle;
4. деактивировать том через lvchange -an;
5. удалить том через lvremove.

Именно такой подход обычно решает и запросы вида vgchange failed to deactivate, потому что корень проблемы почти всегда один и тот же — активная зависимость на уровне процесса, mount namespace или device-mapper.

Итог

Ошибки LVM device is busy, lvremove device is busy, vgchange failed to deactivate и logical volume in use в Debian и Ubuntu почти никогда не являются поломкой LVM. Обычно это нормальная защитная реакция системы: том ещё кем-то используется, и LVM не даёт удалить его поверх живой зависимости.

Рабочая формула проста: сначала lvs и findmnt, затем swapon, после этого lsof и fuser, а если причина не найдена — dmsetup ls --tree, lsns и проверка mapper-цепочки. Такой порядок помогает быстро локализовать проблему и не ломать рабочую систему резкими действиями.

Если придерживаться этой последовательности, удаление или деактивация LVM-томов перестаёт быть лотереей и превращается в понятную, воспроизводимую процедуру.