it-swarm.it

umount: il dispositivo è occupato. Perché?

Durante l'esecuzione umount /path Ottengo:

umount: /path: device is busy.

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

lsof /path, lsof +f -- /path, e fuser /path tutti non restituiscono nulla. fuser -v /path dà:

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

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

umount -l e umount -f non è abbastanza buono per la mia situazione.

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

186
Ole Tange

Sembra che la causa del mio problema sia stata la nfs-kernel-server stava esportando la directory. Il nfs-kernel-server probabilmente va dietro i normali file aperti e quindi non è elencato da lsof e fuser.

Quando ho fermato il nfs-kernel-server Potrei umount la directory.

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

149
Ole Tange

Per aggiungere a BruceCran 's commento sopra, la causa per la mia manifestazione di questo problema proprio ora era un stantio montaggio loopback. Avevo già verificato l'output di fuser -vm <mountpoint>/lsof +D <mountpoint>, mount e cat /proc/mounts, verificato se alcuni vecchi server nfs-kernel erano in esecuzione, disattivato le quote, tentato (ma non riuscito) un umount -f <mountpoint> e mi sono quasi rassegnato ad abbandonare il tempo di attività di 924 giorni prima di controllare finalmente l'output di losetup e di trovare due loopback non 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#

A post sul forum 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.

42
ZakW

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'
24
Caleb

Per me, il processo offensivo era un demone in esecuzione in un chroot. Poiché era in chroot, lsof e fuser non lo avrebbero trovato.

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

23
cibyr

Apri file

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

lsof +f -- <mountpoint or device>

C'è un vantaggio nell'uso di /dev/<device> piuttosto che /mountpoint: un mountpoint scompare dopo un umount -l, oppure potrebbe essere nascosto da una montatura sovrapposta.

fuser può anche essere usato, ma a mio avviso lsof ha 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 il rimontaggio di sola lettura (mount -o remount,ro <mountpoint>), è sicuro (r) uccidere tutti i processi rimanenti:

fuser -vmMk <mountpoint>

Mountpoints

Il colpevole può essere il kernel stesso. Un altro filesystem montato sul filesystem che si sta tentando di umount provocherà dolore. Controllare con:

mount | grep <mountpoint>/

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

losetup -la

Inode anonimi (Linux)

Inode anonimi può essere creato da:

  • File temporanei (open con O_TMPFILE)
  • inotify orologi
  • [Eventfd]
  • [Eventpoll]
  • [Timerfd]

Questi sono il tipo più sfuggente di pokemon e compaiono nella colonna lsof's TYPE come a_inode (che non è documentato nella pagina man lsof ).

Non verranno visualizzati in 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) .

11
Tom Hale

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

fuser -m /path
5
Patrick

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, mount ha continuato a dare il mount: / is busy errore. È stato causato da un processo che conteneva un descrittore aperto in un file che era stato sostituito da un comando, che era stato eseguito quando il filesystem era in lettura-scrittura. La linea importante di lsof -- / l'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 DEL nell'output. Il semplice riavvio del processo trattenendo il file eliminato ha risolto il problema.

5
pdp

lsof e fuser non mi hanno dato nulla.

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/postfix per /disk2/pers/mail/postfix/varspool per ridurre al minimo le scritture del disco su un filesystem di root basato su SDCARD (Sheeva Plug).

Con questo link simbolico, anche dopo aver interrotto i servizi postfix e dovecot (entrambi ps aux così come netstat -tuanp non ha mostrato nulla di correlato) Non sono stato in grado di unmount /disk2/pers.

Quando ho rimosso il link simbolico e ho aggiornato i file di configurazione postfix e dovecot per puntare direttamente alle nuove directory su /disk2/pers/ Sono stato in grado di arrestare correttamente i servizi e unmount la directory.

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

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

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

4
captcha

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 Shell ha risolto il problema per me.

Ho pensato di condividere la mia risoluzione.

3
colemanm

Ho un paio di bind e overlay sotto il mio mount che mi stavano bloccando, controlla il completamento della tab per il mount-point che vuoi smontare. Ho il sospetto che fosse la montatura overlay in particolare, ma avrebbe potuto essere anche i vincoli

1
ThorSummoner

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 "dispositivo occupato".

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 non ha aiutato neanche questo. 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 ho usato quello ed ho eseguito init 4 Nel mio caso è andato tutto bene, in quanto avevo bisogno di riavviare il server in ogni caso, ma probabilmente sarà il caso di chiunque modifichi i dischi.

1

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
1
Ole Tange