umount: il dispositivo è occupato. Perché?

Durante la corsa umount /pathottengo:

umount: /path: device is busy.

Il filesystem è enorme, quindi lsof +D /pathnon è un'opzione realistica.

lsof /path, lsof +f -- /pathe fuser /pathtutti non restituiscono nulla. fuser -v /pathdà:

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

che è normale per tutti i file system montati non utilizzati.

umount -le umount -fnon è abbastanza buono per la mia situazione.

Come faccio a capire perché il kernel pensa che questo filesystem sia occupato?

Sembra che la causa del mio problema sia stata l' nfs-kernel-serveresportazione della directory. La nfs-kernel-serverprobabilmente va dietro i normali file aperti e quindi non è elencato per lsofe fuser.

Quando ho fermato nfs-kernel-serverho potuto umountla directory.

Finora ho creato una pagina con esempi di tutte le soluzioni: http://oletange.blogspot.com/2012/04/umount-device-is-busy-why.html

Per aggiungere a BruceCran 's commento sopra, la causa per la mia manifestazione di questo problema solo ora è stata una stantia montaggio loopback. Avevo già controllato l'output di fuser -vm <mountpoint>/ lsof +D <mountpoint>, mounte cat /proc/mounts, verificato se qualche vecchio server nfs-kernel era in esecuzione, disattivato le quote, tentato (ma non riuscito) a umount -f <mountpoint>tutti ma mi sono rassegnato ad abbandonare il tempo di attività di 924 giorni prima di controllare finalmente l'output di losetupe trovare due loopback stanti configurati ma non montati:

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

poi

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#

Un post sul forum di Gentoo elenca anche gli swapfile come un potenziale colpevole; sebbene lo scambio di file sia probabilmente piuttosto raro in questi giorni, non può far male controllare l'output di cat /proc/swaps. Non sono sicuro che le quote possano mai impedire uno smontaggio - mi aggrappavo alle cannucce.

Invece di usare lsof per eseguire la scansione del file system, basta usare l'elenco totale dei file aperti e grep. Trovo che questo ritorni debba essere più veloce, anche se è meno preciso. Dovrebbe portare a termine il lavoro.

lsof | grep '/path'

Per me, il processo offensivo era un demone in esecuzione in un chroot. Perché era in chroot lsofe fusernon lo trovava.

Se sospetti di avere qualcosa in esecuzione in un chroot, sudo ls -l /proc/*/root | grep chroottroverà il colpevole (sostituisci "chroot" con il percorso del chroot).

Apri file

I processi con file aperti sono i soliti colpevoli. Visualizzali:

lsof +f -- <mountpoint or device>

C'è un vantaggio nell'usare /dev/<device>piuttosto che /mountpoint: un mountpoint scomparirà dopo un umount -l, o potrebbe essere nascosto da un mount sovrapposto.

fuserpuò anche essere usato, ma secondo me lsofha un output più utile. Tuttavia fuserè utile quando si tratta di uccidere i processi che causano i tuoi drammi in modo da poter andare avanti con la tua vita.

Elenca i file su <mountpoint>(vedi avvertenza sopra):

fuser -vmM <mountpoint>

Uccidi in modo interattivo solo i processi con i file aperti per la scrittura:

fuser -vmMkiw <mountpoint>

Dopo aver rimontato la sola lettura ( mount -o remount,ro <mountpoint>), è sicuro (r) eliminare tutti i processi rimanenti:

fuser -vmMk <mountpoint>

mountpoints

Il colpevole può essere il kernel stesso. Un altro filesystem montato sul filesystem che stai provando umountprovocherà dolore. Controllare con:

mount | grep <mountpoint>/

Per i mount di loopback, controlla anche l'output di:

losetup -la

Inode anonimi (Linux)

Gli inode anonimi possono essere creati da:

• File temporanei ( opencon O_TMPFILE)
• inotificare gli orologi
• [Eventfd]
• [Eventpoll]
• [Timerfd]

Queste sono il tipo più sfuggente di pokemon, e appaiono in lsof's TYPEcolonna come a_inode(che è documentato nella lsofpagina man ).

Non verranno visualizzati lsof +f -- /dev/<device>, quindi dovrai:

lsof | grep a_inode

Per i processi di uccisione con inode anonimi, vedi: Elenca gli orologi inotify correnti (nome percorso, PID) .

Affinché il fusore riferisca sui PID che tengono aperta una montatura, è necessario utilizzare -m

fuser -m /path

Abbiamo un sistema proprietario in cui il filesystem di root è normalmente di sola lettura. Occasionalmente, quando i file devono essere copiati, viene rimontato read-write:

mount -oremount,rw /

E poi rimontato:

mount -oremount,ro /

Questa volta, tuttavia, ha mountcontinuato a dare l' mount: / is busyerrore. È stato causato da un processo che contiene un descrittore aperto a un file che è stato sostituito da un comando, che è stato eseguito quando il filesystem era in lettura-scrittura. La linea importante lsof -- /dall'output sembra essere (i nomi sono stati cambiati):

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

Notare DELil nell'output. Il semplice riavvio del processo trattenendo il file eliminato ha risolto il problema.

lsofe fusernon mi ha dato niente.

Dopo un processo di ridenominazione di tutte le possibili directory in .old e riavvio del sistema ogni volta che ho apportato modifiche ho trovato una directory particolare (relativa a postfix) che era responsabile.

Si è scoperto che una volta avevo creato un collegamento simbolico da /var/spool/postfixa /disk2/pers/mail/postfix/varspoolper ridurre al minimo le scritture su disco su un filesystem di root basato su SDCARD (Sheeva Plug).

Con questo link simbolico, anche dopo l'arresto del postfixe dovecotservizi (sia ps auxcome pure netstat -tuanpnon ha mostrato tutto ciò che riguarda) non ero in grado di unmount /disk2/pers.

Quando ho rimosso il collegamento simbolico e aggiornato i file postfixe di dovecotconfigurazione per puntare direttamente alle nuove directory su, /disk2/pers/sono stato in grado di arrestare correttamente i servizi e unmountla directory.

La prossima volta esaminerò più da vicino l'output di:

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

Il comando sopra elencherà in modo ricorsivo tutti i collegamenti simbolici in un albero di directory (qui a partire da /var) e filtrerà quei nomi che puntano a un punto di montaggio target specifico (qui disk2).

Ho avuto questo problema e si è scoperto che c'erano delle sessioni di schermo attive in background che non conoscevo. Mi sono connesso all'altra sessione dello schermo attiva e la sua shell non era nemmeno attualmente nella directory montata. Uccidere quelle altre sessioni di shell ha risolto il problema per me.

Ho pensato di condividere la mia risoluzione.

Oggi il problema era un socket aperto (in particolare 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

Ho un paio di binde overlaysupporti sotto il mio supporto che mi stavano bloccando, controlla il completamento della scheda per il punto di montaggio che vuoi smontare. Ho il sospetto che fosse la montatura overlay in particolare, ma avrebbe potuto essere anche i vincoli

Questa è più una soluzione alternativa che una risposta, ma la sto pubblicando nel caso in cui possa aiutare qualcuno.

Nel mio caso stavo cercando di modificare LVM perché volevo ingrandire la partizione / var, quindi avevo bisogno di smontarla. Ho provato tutti i commenti e le risposte in questo post (grazie a tutti e soprattutto a @ ole-tange per averli raccolti) e ho ancora ricevuto l'errore "device is busy".

Ho provato a uccidere la maggior parte dei processi nell'ordine specificato anche nel runlevel 0, nel caso in cui l'ordine fosse pertinente nel mio caso, ma neanche questo mi ha aiutato. Quindi quello che ho fatto è stato crearmi un runlevel personalizzato (combinando l'output di chkconfig in nuovi comandi chkconfig --level) che sarebbe molto simile a 1 (modalità utente singolo) ma con funzionalità di rete (con rete ssh e xinet).

Mentre stavo usando redhat, runlevel 4 è contrassegnato come "inutilizzato / definito dall'utente", quindi l'ho usato ed eseguivo init 4 Nel mio caso era ok dato che avevo bisogno di riavviare il server in ogni caso, ma probabilmente sarà così di chiunque ottimizzi i dischi.