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

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

  • Сценарий для «перемонтирования» раздела (umount затем mount)
  • Любимые секционирующие и монтажные трюки
  • Каков длинный идентификатор, который Linux присваивает диску в / media /?
  • Клонирование и повторная установка SD-карты
  • Как установить конкретный каталог?
  • Создание локальной рабочей области для разработки / тестирования
  • Установить каталог на корневой каталог
  • Жесткие диски
  • 11 Solutions collect form web for “umount: устройство занято. Зачем?”

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

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

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

    Чтобы добавить к комментарию BruceCran выше, причиной моего проявления этой проблемы на данный момент было устаревшее соединение с петлей. Я уже проверил вывод fuser -vm <mountpoint> / lsof +D <mountpoint> , mount и cat /proc/mounts , проверил, работал ли какой-то старый nfs-сервер-сервер, отключил квоты, попытался (но не смог ) 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# 

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

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

     lsof | grep '/path' 

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

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

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

     fuser -m /path 

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

     mount -oremount,rw / 

    А затем вернулась обратно:

     mount -oremount,ro / 

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

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

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

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

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

    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 on /disk2/pers/ я смог успешно остановить службы и unmount каталог.

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

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

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

    Сегодня проблема заключалась в открытом сокете (в частности, 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 

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

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

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

     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> 

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

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

     mount | grep <mountpoint>/ 

    Для соединений с петлевой петлей также проверяйте вывод:

     losetup -la 

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

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

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

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

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

     lsof | grep a_inode 

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

    Interesting Posts

    Листинг номера числа результатов в `find` и` ls`

    Как установить парольную фразу на USB-накопитель?

    Предотвращение отключения терминала от убийства текущей работы в zsh

    Переключение с letencrypt (клиент) на acme-client – где мой ключ учетной записи?

    Ресурсы для программирования переносных оболочек

    Loopback весь полученный трафик на интерфейсе

    Как выполнить операцию «&» последовательно

    Слишком рано попробовать LibreSSL?

    Как остановить sudo PAM-сообщения в auth.log для определенного пользователя на Ubuntu 16.04?

    Что такое расщепление слов? Почему это важно в программировании оболочки?

    Как выводить только столбец с постоянными соседями?

    Как использовать регулярное выражение с отрицательным выражением?

    Как изменить направление прокрутки сенсорной панели двумя пальцами в Wayland Gnome?

    Если ssh-add будет тихим, если ключ уже есть

    Замена 3 или более цифр эквивалентным числом *

    Linux и Unix - лучшая ОС в мире.