Команда размонтирования вежливо отказывает: цель занята. Отказ честный, но бесполезный для действий: система не называет, кто именно держит том, а держателей может быть с десяток, от забытой оболочки до фоновой службы. Диагностика держателей это ровно та задача, для которой в системе есть две утилиты, и за двадцать лет их имена не изменились. Статья разбирает причины занятости, поиск держателей, типовых виновников, честное освобождение и цену ленивого обхода, которым соблазнительно закончить историю быстро.
Причины занятости точки монтирования
Файловая система считается занятой, пока на неё есть активные ссылки: открытые файлы, каталоги, чей рабочий сеанс процесса находится внутри точки, отображения файлов в память. Ядро отказывает в размонтировании не из вредности, а из гарантии: оторвать том из-под работающих процессов значит оставить их с недействительными ссылками, и система принципиально не делает этого без явного принуждения.
Частая ошибка понимания: занятость это не "кто-то пишет прямо сейчас". Открытый на чтение файл, покоящийся каталог как рабочий у процесса, держат том так же крепко, как активная запись. Мгновенная тишина в индикаторе нагрузки не означает освободившейся точки, и утилиты размонтирования смотрят на ссылки, а не на активность.
Второй уровень причин это скрытые держатели: файлы удалённые, но открытые; отображения в память, неочевидные в списках процессов; фоновые задания, живущие со старым рабочим каталогом. Их не видно в дереве процессов обычным взглядом, и именно для них нужны целевые утилиты, а не просмотр вручную.
Третий уровень это держатели вне процессов: используемое устройство в составе сборного тома, активный цикл устройств, ядерные ссылки. Такой уровень встречается реже и лечится разбором конкретной сборки тома, но помнить о нём стоит, потому что утилиты держателей честно покажут пустоту, а отказ размонтирования останется.
Диагностика держателей через fuser и lsof
Первая утилита отвечает на вопрос прямо: кто использует точку. Вызов с двумя ключами показывает таблицу процессов с их правами доступа к файлам точки, с идентификаторами и именами:
fuser -vm /mnt/dataВывод читается за секунды: колонка прав доступа помечает процессы по типу использования, и списком идут имена с идентификаторами. Для сценария "нужно понять и освободить" этого экрана достаточно: имена процессов подсказывают судьбу каждого держателя без второго запроса.
Диагностика держателей это командная работа двух утилит: одна смотрит глазами процессов, вторая глазами файлов, и на пересечении их выводов складывается полная таблица занятости точки.
Вторая утилита показывает ту же картину с другой стороны: список открытых файлов с фильтром по точке. Вариант с флагом каталога медленнее на больших деревьях, зато находит каждый файл; вариант с выборкой по пути в списке всех открытых файлов быстрее и показывает не только процессы, но и конкретные файлы, включая удалённые, но открытые:
lsof /mnt/data
lsof | grep /mnt/dataРазница в назначении: первая утилита о процессах, вторая о файлах. Для быстрого решения кого останавливать, первая. Для понимания что именно держат, вторая. Опытные администраторы запускают обе: таблица процессов для действий, список файлов для объяснений, и полный протокол держателей складывается за минуту.
Пустой вывод утилит при живом отказе это тоже ответ: держатель не в процессах, а в конструкции тома, и разбор переходит к сборке устройства. Подсказки на этот переход дают оба инструмента одинаково честно: молчание при отказе это сигнал про ядро, а не про неисправность утилит.
Типовые держатели от оболочки до служб
Первый в списках всегда человек: оболочка с рабочим каталогом внутри точки. Зашёл посмотреть, вышел из утилиты, а рабочий каталог остался там же. Такой держатель лечится командой перехода в домашний каталог и переуспокоением всех терминалов парка: на сервере с десятком сессий поиск оболочек внутри точки это первая же строка диагностики.
Второй класс: редакторы и просмотрщики, открытые на файлах внутри тома. Забытый сеанс редактора держит файл, файл держит том. Диагностика показывает имя процесса с файлом, и лечение это закрытие конкретного сеанса, а не карательные операции над томом.
Третий класс: службы с рабочим каталогом или открытыми журналами на точке. Служба права доступа показывает с пометкой текущего каталога либо с открытым файлом, и лечение начинается с понимания: рабочий каталог службы в конфигурации, журналы службы на монтируемом томе. Оба случая лечатся конфигурацией, а не ритуалом перед каждым размонтированием.
Четвёртый класс: фоновые и отложенные задания, запущенные из каталога внутри точки. Задание живёт своей жизнью, его рабочий каталог никто не менял, и утилиты честно показывают его среди держателей. Лечение это осознанная остановка задания либо перенос, а в служебных скриптах правилом номер один становится переход в нейтральный каталог сразу после запуска фоновых работ.
Пятый класс, невидимый: удалённые открытые файлы. Журнал вырос, его удалили, а процесс держит дескриптор и пишет дальше, теперь в никуда. Вторая утилита показывает такие файлы отдельной пометкой, и лечение это перезапуск пишущего процесса с переносом журналов на постоянное место, а не размонтирование вслепую.
Честное освобождение от закрытия до остановки службы
Освобождение держателей строится по лестнице мягкости. Первая ступень: убрать то, что не требует решений. Выйти из каталога во всех сессиях, закрыть редакторы, завершить интерактивные дела. Вторая ступень: остановить то, что останавливается штатно. Службы останавливаются своим механизмом, фоновые задания завершаются своим, и после каждого шага повторная попытка размонтирования показывает, ушёл ли отказ.
Третья ступень: осознанное принуждение. Утилита держателей умеет отправить процессам сигнал завершения одним вызовом по точке, и это инструмент последней надежды, а не первой:
fuser -km /mnt/dataКлюч принудительного завершения не различает невиновных: все процессы на точке получают сигнал, и пострадать могут и те, кому место было не причиной, а обстоятельством. Применение этой ступени осознанно: остановка данных, последствия для несохранённых состояний, и повторение после неё диагностики, потому что между сигналом и освобождением проходит время.
Четвёртая ступень для служебного хозяйства: изменить конфигурацию так, чтобы держатели не возникали. Рабочие каталоги служб на постоянных разделах, журналы на постоянных разделах, фоновые задания стартуют из нейтральных мест. Лестница после этого редко поднимается выше первой ступени, и размонтирование перестаёт быть событием.
Проверка успеха это молчаливая команда размонтирования без ошибок и пустой вывод утилиты держателей на точке. Двойная проверка закрывает сценарий по-человечески: не "наверное, размонтировалось", а подтверждённое состояние, записанное в протокол работы.
Ленивое размонтирование и его скрытая цена
Соблазнительный обход работает так: ключ ленивого размонтирования отвязывает точку от дерева немедленно, а фактическое освобождение происходит потом, когда уйдут последние ссылки. Отказ исчезает на глазах, команда завершается успехом, и обход выглядит решением за десять секунд.
Цена выплачивается скрыто. Том фактически остаётся смонтированным в невидимом состоянии: процессы с старыми ссылками продолжают работу с данными, записи идут в оторванный том, и состояние расходится с видимым деревом каталогов. Восстановление системы, остановка с зависшей невидимой ссылкой, диагностика "куда ушли записи" это сюжеты, которые приходят позже, а не сразу.
Ленивое размонтирование честно в одном сценарии: необратимо зависшие сетевые хранилища, где ядро ждёт недоступный сервер, а остановить всё нужно сейчас. Там это инструмент аварийного порядка, признанный практикой. Но даже там за ним следует честная работа с зависшими процессами, и обход это пауза, а не финал.
Правило для регламентов одно: ленивое размонтирование не входит в штатные процедуры. В процедуру входит диагностика держателей и освобождение, а обход остаётся в списке аварийных приёмов с подписью ответственного за последствия. Команды, принявшие обход в ритуал, однажды разбирают загадку записей, ушедших в невидимый том, и эта загадка дороже всех сэкономленных минут.
Особые случаи от зависших сетевых систем до контейнеров
Зависшее сетевое хранилище это отдельный сюжет: точка недоступна, команды на ней виснут, а размонтирование ждёт таймаутов. Инструменты держателей могут сами зависнуть на мёртвом томе, и диагностика переносится на уровень параметров монтирования: жёсткие таймауты при монтировании предотвращают зависание, принудительное размонтирование для сетевых систем существует как признанный аварийный приём именно этого класса.
Сборные тома держат точку через устройства: циклические устройства, сборки из нескольких разделов, слои. Размонтирование внутреннего слоя невозможно, пока смонтирован внешний, и порядок разборки идёт снаружи внутрь. Утилиты держателей показывают пустоту, а отказ живёт в конструкции, и подсказка о сборке тома это вывод из молчания утилит.
Изолированные окружения и контейнерные системы добавляют своих держателей: точки, проброшенные внутрь окружений, держатся их процессами, и размонтирование требует остановки или пересборки окружения. Утилиты показывают процессы вне привычного мира, и лечение это работа с механизмом окружения, а не с отдельными процессами.
Процедура смены носителя заслуживает отдельной строки в регламенте: перед размонтированием протокол держателей, после смены носителя контрольная проверка. Две строки на расписании дешевле любого разбора, потому что нерегулярные держатели ловятся до того, как станут отказом.
Замена носителя по расписанию: смена сменных томов это массовый сценарий размонтирования, и там правило лестницы экономит часы в месяц. Держатели предсказуемы, и служебный скрипт проверки перед сменой носителя, одна команда утилиты держателей с выводом в протокол, превращает ритуал в контрольный список из двух строк.
Рабочая процедура размонтирования занятой точки
Процедура, закрывающая девять случаев из десяти, выглядит так:
- Утилитой держателей получить таблицу процессов на точке;
- Разделить держателей на убираемых и требующих решения;
- Убрать интерактивное: каталоги сеансов, редакторы, просмотрщики;
- Остановить штатно службы и задания, работающие с точкой;
- Повторить размонтирование и при повторном отказе вернуться к диагностике;
- Применять принуждение и обходы только с осознанием последствий и протоколом.
За процедурой стоит философия простая: занятость точки это не препятствие, а информация. Система называет держателей, утилиты их показывают, и работа с размонтированием это работа со списком процессов, а не борьба с командой.
Итоговое суждение рабочее. Отказ размонтирования это самый информативный отказ в системе: он всегда честен, всегда проверяем и всегда лечится найденным списком. Утилита держателей, вторая утилита для деталей и лестница мягкости решают класс целиком, а ленивый обход остаётся аварийным чемоданчиком с понятной ценой. Администратор, у которого процедура размонтирования занимает минуту, отличается от администратора с вечной занятой точкой не удачей, а именно этими привычками.
Мелкая привычка с большим эффектом: перед плановым размонтированием запускать утилиту держателей в протокол. Одна строка заранее отвечает на вопрос, который иначе задаётся системе дважды, и плановые смены носителей проходят без сюрпризов годами.
Финальная строка процедуры: размонтирование подтверждается выводом списка смонтированных систем, а не молчанием команды. В протоколе остаётся строка с именем тома и временем, и следующая смена носителя начинается с чтения этой строки, а не с чистого листа.