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

Як зрозуміти, чому ядро ​​вважає, що ця файлова система зайнята?

Здається, причиною моєї проблеми 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 «s коментар вище, причина для мого прояви цієї проблеми тільки зараз був несвіжий петлевий кріплення. Я вже перевіряв вихід fuser -vm <mountpoint>/ та lsof +D <mountpoint>, mountі cat /proc/mountsперевіряв, чи працює якийсь старий nfs-kernel-сервер, вимикав квоти, намагався (але не вдався) a 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#

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

Замість того, щоб використовувати lsof для проходу по файловій системі, просто використовуйте загальний список відкритих файлів і скопіюйте його. Я вважаю, що це повернення повинно швидше, хоча воно менш точне. Слід виконати роботу.

lsof | grep '/path'

Для мене образотворчим процесом був демон, що працює в хротоні. Тому що він був у chroot, lsofі fuserне знайшов би його.

Якщо ви підозрюєте, що у вас є щось, що працює в chroot, sudo ls -l /proc/*/root | grep chrootзнайдете винуватця (замініть "chroot" на шлях до chroot).

Відкрити файли

Процеси з відкритими файлами - звичні винуватці. Показати їх:

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)
• прищеплювати годинник
• [eventfd]
• [опитування подій]
• [timerfd]

Це найбільш невловимий тип покемону, і вони з’являються у стовпці lsof's TYPEяк a_inode(що недокументовано на lsofсторінці man ).

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

lsof | grep a_inode

За вбивство процесів , проведенням анонімних дескрипторів, см: список поточних Inotify годин (шлях до файлу, PID) .

Щоб сповіщувач повідомляв про PID, які тримають кріплення відкритим, ви повинні використовувати -m

fuser -m /path

У нас є власна система, де коренева файлова система, як правило, лише для читання. Іноді, коли файли потрібно копіювати, вони перераховуються для читання-запису:

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на висновок. Проста перезапуск процесу, що тримається за видаленим файлом, вирішив проблему.

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конфігурації, щоб вказати безпосередньо на нові файли, /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кріплення під монтом, які блокували мене, перевірте завершення вкладки на точку монтажу, яку ви хочете відключити. Я підозрюю, що це саме кріплення накладення, але могло бути і зв'язком

Це скоріше рішення, ніж відповідь, але я публікую його у випадку, якщо це може комусь допомогти.

У моєму випадку я намагався змінити LVM, оскільки хотів зробити / var розділ більшим, тому мені потрібно було його замінити. Я спробував усі коментарі та відповів у цьому дописі (дякую всім, а особливо @ ole-tange за їх зібрання) і все-таки отримав помилку "пристрій зайнятий".

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

Оскільки я використовував redhat, runlevel 4 позначається як "невикористаний / визначений користувачем", тому я використав цей і запустити. init 4 У моєму випадку це було нормально, оскільки мені потрібно було перезавантажити сервер у будь-якому випадку, але, мабуть, так буде кого-небудь, що підправляє диски.