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

Другой объем смонтирован сверху объема, который мы хотим размонтировать:

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

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

Затем просто grep по mointpoint, от которого Вы хотите размонтироваться и Вы будете знать, существуют ли смонтированные файловые системы по этому.

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

Затем у Вас есть два решения. Или размонтируйте файловые системы или переместите их с mount --move olddir newdir (ядро> 2.5.1)

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

То, что я имею, является только этим:

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

pidof nfsd

Покажите смонтированные каталоги клиентов:

showmount -a

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

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

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

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

Пример:

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)

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

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

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

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

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

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

sudo umount -l <path>

Из страницы руководства :

-l, --lazy

Ленивое отключение. Отсоедините файловую систему от файловой иерархии сейчас и очистите все ссылки на эту файловую систему, как только она больше не будет занята.

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

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

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

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

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 часы
• [событиеfd]
• [опрос событий]
• [таймерфд]

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

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

lsof | grep a_inode

Информацию об уничтожении процессов, содержащих анонимные индексные дескрипторы, см. в разделе:List current inotify watch (pathname, PID).