Come faccio a sapere quali processi impediscono lo smontaggio di un dispositivo?

A volte, vorrei smontare un dispositivo USB con umount /run/media/theDrive, ma viene visualizzato un drive is busyerrore.

Come faccio a sapere quali processi o programmi accedono al dispositivo?

Utilizzare lsof | grep /media/whateverper scoprire cosa sta usando la montatura.

Inoltre, considerare umount -l(pigro umount) per impedire a nuovi processi di utilizzare l'unità durante la pulizia.

La maggior parte del tempo, il comando migliore da utilizzare è lsof ( “ l i s t o penna f iles”).

lsof +f -- /media/usb0

dove si /media/usb0trova il punto di montaggio dell'unità USB o di un altro filesystem da smontare. +f --dice a lsof di trattare l'argomento successivo come un punto di montaggio; di solito, ma non sempre, riesce da solo, quindi lsof /media/usb0funziona anche. Questo trova file aperti (anche quelli non collegati), file mappati in memoria, directory correnti e alcuni usi più oscuri. Dovrai eseguire il comando come root per ottenere informazioni sui processi di altri utenti (e penso che ci siano unices dove lsofdevono essere eseguiti come root).

Ci sono usi che lsof non troverà; questi sono rari su supporti rimovibili. Loro includono:

• punti di montaggio: non è possibile smontare /foose /foo/barè un punto di montaggio.
• dispositivi di mount: non è possibile smontare /foose si /foo/bartratta di un dispositivo a blocchi montato o di un file normale montato in loop o se è la fonte di un mount di bind Linux.
• Esportazione NFS: lsof non rileverà che un albero viene esportato da un server NFS del kernel.

Un altro comando che può servire in un pizzico è il fusore, che elenca solo i PID dei processi con file aperti sul dispositivo:

fuser -m /media/usb0

Puoi usare lsofcome ha detto Peter, o se sei sicuro di voler semplicemente uccidere tutte quelle cose e smontarlo, probabilmente puoi fare qualcosa del tipo:

fuser -Mk /mnt/path
umount /mnt/path

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) uccidere 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 ( grazie Stephen Kitt ), 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) .

inotify orologi (Linux)

Questo commento spiega perché inotify non dovrebbe impedire uno smontaggio, ma questa nota descrive le situazioni in cui dovrà :

uno smontaggio può essere bloccato nella vx_softcnt_flush()chiamata. Il blocco si verifica perché gli orologi inotify incrementano la i_countvariabile e fanno sì che il valore v_os_hold valuerimanga elevato fino a quando l'osservatore inotify rilascia la sospensione.

Se usi GNOME, lo smontaggio tramite Nautilus visualizzerà un messaggio che indica quale processo sta ancora utilizzando l'unità e il file che sta utilizzando.

Per (almeno) OpenBSD:

$ fstat /mnt/mountpoint

Ad esempio (usando doasper eseguire fstatcome root come altrimenti vedremmo solo i nostri processi):

$ doas fstat /usr/ports
USER     CMD          PID   FD MOUNT        INUM MODE         R/W    SZ|DV NAME
_pbuild  make       15172   wd /usr/ports  3923598  drwxrwxr-x     r     1536 /usr/ports/
_pbuild  make       40034   wd /usr/ports  3923598  drwxrwxr-x     r     1536 /usr/ports/

In questo caso, non sarei in grado di smontare /usr/portsfino a quando l'utente non avrà _pbuildterminato l'esecuzione di questi due makeprocessi.

Questa è una trappola comune: fai clic su un altro utente (root o qualsiasi altro utente), passa alla directory di un dispositivo montato e quindi esci come tale utente. Quando dimentichi di essere uscito da quella directory, puoi provare a trovare finché non sei cieco. lsofmostra alla shell quale directory corrente sta usando quel dispositivo. Potresti voler fare di nuovo su quell'utente per cambiare la tua directory.