Занятое устройство на Umount

У меня часто возникают проблемы с размонтированием каталога:

umount / mnt / dir
umount: / mnt / dir: устройство занято

Существует множество причин, по которым устройство занято. Иногда выполняются процессы с открытыми блокировками, иногда есть другие каталоги, смонтированные поверх них /mnt/dir.

Мой вопрос:

Какие шаги нужно проверить, почему каталог не может быть размонтирован.

Я знаю, что есть много причин, но это нормально, если вы объясните конкретное решение.

[РЕДАКТИРОВАТЬ]

[X] запуск процессов на подключенных томах.
[X] другой том монтируется поверх тома, который мы хотим размонтировать
[_] NFS блокирует том, который мы хотим размонтировать

Способ проверить fuser -vm /mnt/dir, который должен быть запущен от имени пользователя root. Он скажет вам, какие процессы обращаются к точке монтирования.

Альтернатива lsof /mnt/dir, которая покажет каждый открытый файл на монтировании. Опять лучше всего запускать с правами root.

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

Пример:

Watt:~# fuser -vm /mnt/Zia/src
                     USER        PID ACCESS COMMAND
/mnt/Zia/src:        root     kernel mount /mnt/Zia/src
                     anthony   24909 ..c.. bash
                     anthony   25041 F.c.. gvim

Поле «доступ» сообщает вам, как к нему обращаются. В этом случае ядро ​​использует его в качестве монтирования (да, но с размонтированием все будет в порядке только с этим). bashимеет текущий рабочий каталог ( cdперед размонтированием должен перейти в другой каталог), а у gvim есть текущий каталог и открытый файл (необходимо закрыть этот gvim).

Watt:~# lsof /mnt/Zia/src
COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
bash    24909 anthony  cwd    DIR   0,26    12288 3527682 /mnt/Zia/src/perl (zia.vpn.home:/home/anthony/src)
gvim    25041 anthony  cwd    DIR   0,26    12288 3527682 /mnt/Zia/src/perl (zia.vpn.home:/home/anthony/src)
gvim    25041 anthony    6u   REG   0,26    16384 3526219 /mnt/Zia/src/perl/.utf8.c.swp (zia.vpn.home:/home/anthony/src)

В этом выводе вы можете увидеть текущие каталоги для bash и gvim (как тип DIR). Вы также можете увидеть, какой файл gvim открыт для записи.

Как заставить проблему:

fuserесть -kопция, которая отправляет сигнал (по умолчанию:) SIGKILLкаждому процессу, используя монтирование. Это довольно силовой способ не дать маунту быть занятым. (И конечно, будь осторожен с тем, что ты SIGKILL!)

umountимеет -lвозможность выполнить ленивое размонтирование. Монтирование будет удалено из пространства имен файловой системы (так что /mnt/Zia/srcв этом примере вы его больше не увидите ), но оно остается смонтированным, поэтому программы, обращающиеся к нему, могут продолжать это делать. Когда последняя программа, получающая доступ к нему, завершает работу, произойдет размонтирование.

Существует еще одна решаемая причина сбоя при размонтировании, и это отказ сервера NFS. Здесь вы можете использовать umount -f, но вы рискуете потерей данных, если вы это сделаете. (Возможно, клиент кэшировал записи, которые еще не были подтверждены сервером, и эти записи будут отброшены. Однако приложениям уже было сообщено, что запись прошла успешно.)

Вы должны использовать:

sudo umount -l <path>

Другой том монтируется поверх тома, который мы хотим отключить:

Команда mountпозволяет вам знать все подключенные тома, если они вызываются без аргументов или опций (кроме -v). Вы можете получить список активных точек монтирования, добавив немного perl:

mount | perl -pe 's/.*on (\S+) type.*/\1/'

Затем просто наведите курсор на точку mointpoint, с которой вы хотите отключиться, и вы узнаете, есть ли над ней смонтированные файловые системы.

mount | perl -pe 's/.*on (\S+) type.*/\1/' | grep '/mnt/dir/'

Тогда у вас есть два решения . Либо размонтируйте файловые системы, либо переместите их с помощью mount --move olddir newdir(ядро> 2.5.1)

Открытые файлы

Процессы с открытыми файлами являются обычными виновниками. Показать их:

lsof +f -- <mountpoint or device>

Преимущество использования /dev/<device>вместо /mountpoint: точка монтирования исчезнет после umount -lили может быть скрыта наложенным монтированием.

fuserТакже можно использовать, но на мой взгляд, lsofесть более полезный вывод. Однако fuserэто полезно, когда дело доходит до уничтожения процессов, вызывающих ваши драмы, чтобы вы могли продолжить свою жизнь.

Список файлов <mountpoint>(см. Предостережение выше):

fuser -vmM <mountpoint>

Интерактивно уничтожать только процессы с открытыми для записи файлами:

fuser -vmMkiw <mountpoint>

После перемонтирования только для чтения ( mount -o remount,ro <mountpoint>) можно (r) убить все оставшиеся процессы:

fuser -vmMk <mountpoint>

точки монтирования

Виновником может быть само ядро. Другая файловая система, смонтированная в той файловой системе, к которой вы пытаетесь umount, вызовет горе. Проверить с:

mount | grep <mountpoint>/

Для петлевых монтировок также проверьте вывод:

losetup -la

Анонимные иноды (Linux)

Анонимные иноды могут быть созданы:

• Временные файлы ( openс O_TMPFILE)
• Inotify часы
• [Eventfd]
• [Eventpoll]
• [Timerfd]

Это самый неуловимый тип покемона, и появляются в lsof«s TYPEстолбец как a_inode(который без документов на lsofстранице человека ).

Они не появятся lsof +f -- /dev/<device>, поэтому вам нужно:

lsof | grep a_inode

Для процессов уничтожения, содержащих анонимные inode, смотрите: Список текущих наблюдений inotify (pathname, PID) .

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

Что у меня есть только это:

Проверьте, работает ли nfsd:

pidof nfsd

Показать подключенные каталоги по клиентам:

showmount -a

и showmountбез аргументов показывает только клиентские хосты, даже если они не в сети. Я предполагаю, что это особое поведение NFS.

Для меня проблема заключалась в том, что я входил в систему более одного раза (через ssh), и во время одного из входов в систему я находился в командной строке, где pwd находился внутри папки, подчиненной точке монтирования.