it-swarm-ru.tech

umount: устройство занято. Почему?

Когда работает umount /path Я получил:

umount: /path: device is busy.

Файловая система огромна, поэтому lsof +D /path нереальный вариант.

lsof /path, lsof +f -- /path, а также fuser /path все ничего не возвращают. fuser -v /path дает:

                  USER        PID ACCESS COMMAND
/path:            root     kernel mount /path

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

umount -l а также umount -f недостаточно для моей ситуации.

Как мне выяснить, почему ядро ​​считает эту файловую систему занятой?

186
Ole Tange

Кажется, причиной моей проблемы было nfs-kernel-server экспортировал каталог. nfs-kernel-server, вероятно, идет за обычными открытыми файлами и поэтому не указан в списке lsof и ​​fuser.

Когда я остановил nfs-kernel-server Я мог бы umount каталог.

На данный момент я создал страницу с примерами всех решений: http://oletange.blogspot.com/2012/04/umount-device-is-busy-why.html

149
Ole Tange

Чтобы добавить к BruceCranкомментарий выше, причина моего проявления этой проблемы только что была устаревшей петлевое крепление. Я уже проверил вывод fuser -vm <mountpoint>/lsof +D <mountpoint>, mount и ​​cat /proc/mounts, проверил, работает ли какой-то старый nfs-kernel-server , отключил квоты, попытался (но потерпел неудачу) umount -f <mountpoint> и ​​почти смирился с тем, что отказался от времени безотказной работы 924 дней, прежде чем, наконец, проверить вывод losetup и ​​найти два устаревших настроенных-но-не-настроенных петли:

parsley:/mnt# cat /proc/mounts 
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,size=10240k,mode=755 0 0
/dev/mapper/stuff-root / ext3 rw,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
fusectl /sys/fs/Fuse/connections fusectl rw 0 0
/dev/dm-2 /mnt/big ext3 rw,errors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user 0 0

тогда

parsley:/mnt# fuser -vm /mnt/big/
parsley:/mnt# lsof +D big
parsley:/mnt# umount -f /mnt/big/
umount2: Device or resource busy
umount: /mnt/big: device is busy
umount2: Device or resource busy
umount: /mnt/big: device is busy

parsley:/mnt# losetup -a    
/dev/loop0: [fd02]:59 (/mnt/big/dot-dropbox.ext2)
/dev/loop1: [fd02]:59 (/mnt/big/dot-dropbox.ext2)

parsley:/mnt# losetup -d /dev/loop0
parsley:/mnt# losetup -d /dev/loop1
parsley:/mnt# losetup -a
parsley:/mnt# umount big/
parsley:/mnt#

A сообщение на форуме Gentoo также перечисляет файлы подкачки как потенциального преступника; хотя в наши дни обмен файлами, вероятно, встречается довольно редко, не помешает проверить вывод cat /proc/swaps. Я не уверен, могли ли когда-нибудь квоты помешать демонтировать - я держался за соломинку.

42
ZakW

Вместо того, чтобы использовать lsof для обхода файловой системы, просто используйте общий список открытых файлов и создайте его. Я считаю, что этот возврат должен быть быстрее, хотя и менее точным. Это должно сделать работу.

lsof | grep '/path'
24
Caleb

Для меня оскорбительным процессом был демон, запущенный в chroot. Поскольку это было в chroot, lsof и ​​fuser не найдут его.

Если вы подозреваете, что что-то осталось в chroot, Sudo ls -l /proc/*/root | grep chroot найдет виновника (замените "chroot" на путь к chroot).

23
cibyr

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

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

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)

Анонимные inode может быть создано:

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

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

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

lsof | grep a_inode

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

11
Tom Hale

Чтобы fuser мог сообщить о PID, которые держат монтируемое устройство открытым, вы должны использовать -m

fuser -m /path
5
Patrick

У нас есть собственная система, в которой корневая файловая система обычно доступна только для чтения. Иногда, когда файлы должны быть скопированы, перемонтируется чтение-запись:

mount -oremount,rw /

А потом перемонтировал обратно:

mount -oremount,ro /

Однако на этот раз mount продолжал давать mount: / is busy ошибка. Это было вызвано процессом, содержащим открытый дескриптор файла, который был заменен какой-то командой, которая выполнялась, когда файловая система находилась в режиме чтения-записи. Важная строка из lsof -- / вывод получился (имена были изменены):

replicate  1719 admin DEL REG 8,5  204394 /opt/gns/lib/replicate/modules/md_es.so

Обратите внимание на DEL в выводе. Простая перезагрузка процесса, держась за удаленный файл, решила проблему.

5
pdp

lsof и ​​fuser тоже ничего мне не дали.

После процесса переименования всех возможных каталогов в .old и перезагрузки системы каждый раз, когда я вносил изменения, я обнаружил один конкретный каталог (связанный с postfix), который отвечал за это.

Оказалось, что я когда-то сделал символическую ссылку из /var/spool/postfix до /disk2/pers/mail/postfix/varspool для минимизации записи на диск в корневой файловой системе на основе SDCARD (Sheeva Plug).

С помощью этой символической ссылки даже после остановки служб postfix и ​​dovecot (обе ps aux а также netstat -tuanp ничего не показывало) Я не смог unmount /disk2/pers.

Когда я удалил символическую ссылку и обновил конфигурационные файлы postfix и ​​dovecot, чтобы они указывали прямо на новые каталоги /disk2/pers/ Мне удалось успешно остановить службы и unmount каталог.

В следующий раз я посмотрю более внимательно на вывод:

ls -lR /var | grep ^l | grep disk2

Приведенная выше команда рекурсивно выведет список всех символических ссылок в дереве каталогов (здесь, начиная с /var) и отфильтруйте те имена, которые указывают на конкретную целевую точку монтирования (здесь disk2).

4
captcha

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

Просто подумал, что поделюсь своим решением.

3
colemanm

У меня есть несколько монтирований bind и ​​overlay под моим монтированием, которые блокировали меня, проверьте завершение вкладки для точки монтирования, которую вы хотите размонтировать. Я подозреваю, что это было наложение, в частности, но могло быть и связыванием

1
ThorSummoner

Это скорее обходной путь, чем ответ, но я выкладываю его на случай, если это кому-нибудь поможет.

В моем случае я пытался изменить LVM, так как хотел увеличить раздел/var, поэтому мне нужно было его размонтировать. Я попробовал все комментарии и ответил в этом посте (спасибо всем и особенно @ ole-tange за их сбор) и все равно получил ошибку "устройство занято".

Я пытался убить большинство процессов в порядке, указанном в уровне запуска 0, на случай, если в моем случае порядок был актуален, но это тоже не помогло. Поэтому я создал собственный уровень выполнения (объединяющий вывод команды chkconfig в новые команды chkconfig --level), который был бы очень похож на 1 (однопользовательский режим), но с сетевыми возможностями (с сетью ssh и xinet).

Поскольку я использовал redhat, уровень запуска 4 помечается как "неиспользуемый/определенный пользователем", поэтому я использовал его и запустил init 4 В моем случае это было нормально, так как в любом случае мне нужно было перезагрузить сервер, но, вероятно, это случится с любым, кто настраивает диски.

1
Gabriel Xunqueira

Сегодня проблема заключалась в открытом сокете (в частности tmux):

mount /mnt/disk
export TMPDIR=/mnt/disk
tmux
<<detatch>>
umount /mnt/disk
umount: /mnt/disk: device is busy.
lsof | grep /mnt/disk
tmux      20885             root    6u     unix 0xffff880022346300        0t0    3215201 /mnt/disk/tmux-0/default
1
Ole Tange