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 не подходит для моей ситуации.

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

154 голоса | спросил Ole Tange 15 J0000006Europe/Moscow 2011, 15:41:11

12 ответов


123

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

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

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

ответил Ole Tange 15 J0000006Europe/Moscow 2011, 16:01:51
38

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

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 также перечисляет swapfiles как потенциальный виновник; хотя обмен файлами, вероятно, довольно редко в эти дни, не может повредить проверку вывода cat /proc/swaps. Я не уверен, могли ли квоты предотвращать разгон - я сжимал соломинку.

ответил ZakW 7 PMpSat, 07 Apr 2012 21:52:37 +040052Saturday 2012, 21:52:37
20

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

lsof | grep '/path'
ответил Caleb 15 J0000006Europe/Moscow 2011, 15:52:20
19

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

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

ответил cibyr 19 MaramTue, 19 Mar 2013 09:45:08 +04002013-03-19T09:45:08+04:0009 2013, 09:45:08
5

Для фьюзера, чтобы сообщать о PID, поддерживающих открывание, вам необходимо использовать -m

fuser -m /path
ответил Patrick 16 J0000006Europe/Moscow 2011, 05:23:59
5

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

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 на выходе. Просто перезагрузка процесса, удерживающего удаленный файл, разрешила проблему.

ответил pdp 2 Maypm16 2016, 13:06:18
4

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

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

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

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

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

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

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

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

ответил captcha 3 Mayam14 2014, 11:55:08
3

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

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

ответил colemanm 23 +04002012-10-23T18:55:14+04:00312012bEurope/MoscowTue, 23 Oct 2012 18:55:14 +0400 2012, 18:55:14
3

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

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

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

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

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

  • Временные файлы (open с помощью O_TMPFILE)
  • inotify часы
  • [eventfd] [eventpoll] [timerfd]

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

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

lsof | grep a_inode

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

ответил Tom Hale 20 PM00000040000000131 2017, 16:24:01
1

Сегодня проблема заключалась в открытом сокете (в частности, 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
ответил Ole Tange 21 SunEurope/Moscow2014-12-21T20:31:00+03:00Europe/Moscow12bEurope/MoscowSun, 21 Dec 2014 20:31:00 +0300 2014, 20:31:00
1

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

ответил Ole Tange 21 SunEurope/Moscow2014-12-21T20:31:00+03:00Europe/Moscow12bEurope/MoscowSun, 21 Dec 2014 20:31:00 +0300 2014, 20:31:00
1

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

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

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

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

ответил Gabriel Xunqueira 30 42017vEurope/Moscow11bEurope/MoscowThu, 30 Nov 2017 13:45:00 +0300 2017, 13:45:00

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132