it-swarm-eu.dev

umount: zařízení je zaneprázdněno. Proč?

Při spuštění umount /path Dostanu:

umount: /path: device is busy.

Souborový systém je obrovský, takže lsof +D /path není realistická možnost.

lsof /path, lsof +f -- /path, a fuser /path vše nevrací nic. fuser -v /path dává:

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

což je normální pro všechny nepoužívané připojené souborové systémy.

umount -l a umount -f není pro mou situaci dost dobrý.

Jak zjistím, proč si jádro myslí, že tento souborový systém je zaneprázdněn?

186
Ole Tange

Zdá se, že příčinou mého problému byla nfs-kernel-server exportoval adresář. The nfs-kernel-server pravděpodobně jde za normální otevřené soubory, a proto není uveden v lsof a fuser.

Když jsem zastavil nfs-kernel-server Mohl jsem umount adresář.

Zde jsem vytvořil stránku s příklady všech řešení: http://oletange.blogspot.com/2012/04/umount-device-is-busy-why.html

149
Ole Tange

Chcete-li přidat k BruceCran 's komentář výše, příčinou mého projevu tohoto problému právě teď byl zastaralý zpětný smyčka. Už jsem zkontroloval výstup fuser -vm <mountpoint>/lsof +D <mountpoint>, mount a cat /proc/mounts, zkontroloval, zda běží nějaký starý nfs-kernel-server, vypnul kvóty, pokusil se (ale selhal) o umount -f <mountpoint> a všichni kromě rezignace jsem opustil 924 dnů uptime, než jsem konečně zkontroloval výstup losetup a našel dva zastaralé nakonfigurované zpětné smyčky bez připojení:

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

pak

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 příspěvek na fór také uvádí swapfiles jako potenciálního viníka; ačkoli přepínání do souborů je v těchto dnech pravděpodobně docela vzácné, nemůže ublížit zkontrolovat výstup cat /proc/swaps. Nejsem si jistý, zda by kvóty mohly někdy zabránit odpojení - svíral jsem se na brčka.

42
ZakW

Namísto použití lsof k procházení souborovým systémem stačí použít celkový seznam otevřených souborů a grep. Zjistil jsem, že tento výnos musí být rychlejší, i když je méně přesný. To by mělo udělat práci.

lsof | grep '/path'
24
Caleb

Pro mě byl tento trestný čin démonem běžícím v chroot. Protože to bylo v chrootu, lsof a fuser ho nenašli.

Pokud máte podezření, že v chrootu zbývá něco, Sudo ls -l /proc/*/root | grep chroot najde viníka (nahraďte "chroot" cestou k chroot).

23
cibyr

Otevřít soubory

Procesy s otevřenými soubory jsou obvyklými viníky. Zobrazit je:

lsof +f -- <mountpoint or device>

Výhodou použití /dev/<device> spíše než /mountpoint: přípojný bod zmizí po umount -l nebo to může být skryto překrýváním.

fuser lze také použít, ale podle mého názoru má lsof užitečnější výstup. fuser je však užitečný, pokud jde o zabíjení procesů způsobujících vaše dramata, abyste mohli pokračovat ve svém životě.

Seznam souborů na <mountpoint> (viz upozornění výše):

fuser -vmM <mountpoint>

Interaktivní zabíjení pouze procesů se soubory otevřenými pro zápis:

fuser -vmMkiw <mountpoint>

Po opětovném připojení pouze ke čtení (mount -o remount,ro <mountpoint>), je bezpečné (r) zabít všechny zbývající procesy:

fuser -vmMk <mountpoint>

Mountpoints

Pachatelem může být samotné jádro. Další souborový systém připojený k souborovému systému, který se pokoušíte umount, způsobí zármutek. Ověřte pomocí:

mount | grep <mountpoint>/

U připojení zpětné smyčky také zkontrolujte výstup:

losetup -la

Anonymní inody (Linux)

Anonymous inodes může být vytvořen:

  • Dočasné soubory (open s O_TMPFILE)
  • inotify hodinky
  • [eventfd]
  • [eventpoll]
  • [časovač]

Jedná se o nejvíce nepolapitelný typ pokémona a objeví se ve sloupci lsof ve sloupci TYPE jako a_inode (což je nezdokumentováno na manuálové stránce lsof ).

Nezobrazí se v lsof +f -- /dev/<device>, takže budete muset:

lsof | grep a_inode

Pro procesy zabíjení, které drží anonymní inody, viz: Seznam aktuálních hodinek inotify (cesta, PID) .

11
Tom Hale

Aby mohla fixační jednotka hlásit PID, které drží držák otevřený, musíte použít -m

fuser -m /path
5
Patrick

Máme proprietární systém, kde je kořenový souborový systém normálně jen pro čtení. Občas, když je třeba soubory zkopírovat, je znovu načteno čtení a zápis:

mount -oremount,rw /

A pak se vrátil zpět:

mount -oremount,ro /

Tentokrát však mount stále dával mount: / is busy chyba. Bylo to způsobeno procesem, který držel otevřený deskriptor souboru, který byl nahrazen nějakým příkazem, který byl proveden, když byl souborový systém čten a zapisován. Důležitá linka od lsof -- / výstup se stane (jména byla změněna):

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

Všimněte si DEL ve výstupu. Problém byl vyřešen pouze restartováním procesu přidržení odstraněného souboru.

5
pdp

lsof a fuser mi také nic nedali.

Po procesu přejmenování všech možných adresářů na .old a restartování systému pokaždé, když jsem provedl změny, jsem našel jeden konkrétní adresář (vztahující se k postfixu), který byl zodpovědný.

Ukázalo se, že jsem jednou udělal symbolický odkaz od /var/spool/postfix to /disk2/pers/mail/postfix/varspool za účelem minimalizace zápisu na disk v kořenovém souborovém systému založeném na SDCARD (Sheeva Plug).

S tímto symbolickým odkazem i po zastavení služeb postfix a dovecot (obojí ps aux jakož i netstat -tuanp neukazoval nic společného) Nebyl jsem schopen unmount /disk2/pers.

Když jsem odstranil symbolický odkaz a aktualizoval konfigurační soubory postfix a dovecot tak, aby ukazovaly přímo na nové dirky na /disk2/pers/ Dokázal jsem úspěšně zastavit služby a unmount adresář.

Příště se podrobněji podívám na výstup:

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

Výše uvedený příkaz rekurzivně vypíše všechny symbolické odkazy ve stromu adresářů (zde začíná na /var) a odfiltrujte jména, která ukazují na konkrétní cílový bod připojení (zde disk2).

4
captcha

Měl jsem tento problém a ukázalo se, že v pozadí, které jsem nevěděl, byly aktivní obrazovky. Připojil jsem se k další aktivní relaci obrazovky a její Shell ani neseděl v připojeném adresáři. Zabití těchto dalších Shellových schůzek mě vyřešilo.

Jen jsem si myslel, že budu sdílet své usnesení.

3
colemanm

Mám pod svým připojením několik přípojek bind a overlay, které mě blokovaly, zkontrolujte dokončení přípojného bodu pro přípojný bod, který chcete odpojit. Mám podezření, že se jednalo zejména o překrytí, ale mohla to být i vazba

1
ThorSummoner

Toto je spíše řešení než odpověď, ale zveřejňuji ji pro případ, že by to někomu mohlo pomoci.

V mém případě jsem se pokoušel modifikovat LVM, protože jsem chtěl zvětšit diskový oddíl/var, takže jsem ho musel rozšířit. Vyzkoušel jsem všechny komentáře a odpovědi v tomto příspěvku (děkuji všem a zejména @ ole-tange za jejich shromáždění) a stále se mi zobrazila chyba „zařízení je zaneprázdněno“.

Pokusil jsem se zabít většinu procesů v pořadí uvedeném v runlevelu 0, jen v případě, že objednávka byla v mém případě relevantní, ale to nepomohlo. To, co jsem udělal, bylo vytvořit mi vlastní runlevel (kombinující výstup chkconfig do nových příkazů chkconfig --level), který by byl velmi podobný 1 (režim pro jednoho uživatele), ale se síťovými schopnostmi (se sítí ssh a xinet).

Když jsem používal redhat, runlevel 4 je označen jako „nepoužitý/uživatelem definovaný“, takže jsem ho použil a spustil init 4 V mém případě to bylo v pořádku, protože jsem v každém případě potřeboval restartovat server, ale pravděpodobně to bude někdo, kdo disky vyladí.

1
Gabriel Xunqueira

Dnes byl problém otevřený soket (konkrétně 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