Dispositivo occupato su Umount

Ho spesso problemi a smontare una directory:

umount / mnt / dir
umount: / mnt / dir: il dispositivo è occupato

Ci sono molti motivi per cui il dispositivo è occupato. A volte ci sono processi in esecuzione che hanno blocchi aperti su di esso, a volte ci sono altre directory montate sopra /mnt/dir.

La mia domanda:

Quali sono i passaggi per verificare perché non è stato possibile smontare una directory.

So che ci sono molte ragioni, ma va bene se spieghi una soluzione specifica.

[MODIFICARE]

[X] processi in esecuzione su volumi montati.
[X] un altro volume è montato sopra un volume che vogliamo smontare
[_] NFS blocca il volume che vogliamo smontare

Il modo per verificare è fuser -vm /mnt/dir, che deve essere eseguito come root. Ti dirà quali processi accedono al punto di montaggio.

Un'alternativa è lsof /mnt/dir, che mostrerà ogni file aperto sul mount. Di nuovo, esegui meglio come root.

Puoi eseguire uno di questi come non root, ma l'output sarà limitato ai tuoi processi: quelli di altri utenti non verranno mostrati silenziosamente, anche se impediranno di smontare il filesystem.

Esempio:

Watt:~# fuser -vm /mnt/Zia/src
                     USER        PID ACCESS COMMAND
/mnt/Zia/src:        root     kernel mount /mnt/Zia/src
                     anthony   24909 ..c.. bash
                     anthony   25041 F.c.. gvim

Il campo "accesso" indica come accedervi. In questo caso, il kernel lo ha usato come mount (duh, ma smontare andrà bene solo con questo). bashlo ha come directory di lavoro corrente (dovrà cdsmontare in un'altra directory prima di smontare) e gvim ha entrambi la directory corrente e ha un file aperto (dovrà chiudere quel gvim).

Watt:~# lsof /mnt/Zia/src
COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
bash    24909 anthony  cwd    DIR   0,26    12288 3527682 /mnt/Zia/src/perl (zia.vpn.home:/home/anthony/src)
gvim    25041 anthony  cwd    DIR   0,26    12288 3527682 /mnt/Zia/src/perl (zia.vpn.home:/home/anthony/src)
gvim    25041 anthony    6u   REG   0,26    16384 3526219 /mnt/Zia/src/perl/.utf8.c.swp (zia.vpn.home:/home/anthony/src)

In questo output, puoi vedere le directory correnti sia per bash che per gvim (come tipo DIR). Puoi anche vedere quale file gvim ha aperto per la scrittura.

Come forzare il problema:

fuserha -kun'opzione che invierà un segnale (predefinito:) SIGKILLa ciascun processo usando il mount. Questo è un modo piuttosto efficace per impedire che la cavalcatura sia occupata. (E ovviamente, stai attento a quello che tu SIGKILL!)

umountha -lun'opzione per eseguire un smontaggio pigro. Il mount verrà rimosso dallo spazio dei nomi del filesystem (quindi non lo vedrai /mnt/Zia/srcpiù sotto , nell'esempio) ma rimane montato, quindi i programmi che accedono ad esso possono continuare a farlo. Quando si chiude l'ultimo programma che accede ad esso, lo smontaggio avverrà effettivamente.

Esiste un'ultima causa risolvibile di errore di smontaggio, che è un server NFS inattivo. Qui puoi usare umount -f, ma rischi di perdere i dati se lo fai. (Il client potrebbe avere scritture memorizzate nella cache che non sono state ancora confermate dal server e tali scritture verranno scartate. Tuttavia, alle app è già stato detto che la scrittura ha esito positivo.)

Dovresti usare:

sudo umount -l <path>

Un altro volume è montato su un volume che vogliamo smontare:

Il mountcomando consente di conoscere tutti i volumi montati se fatturati senza argomenti né opzioni (eccetto -v). Puoi avere un elenco di mountpoint attivi aggiungendo un po 'di perl:

mount | perl -pe 's/.*on (\S+) type.*/\1/'

Quindi, basta passare sopra il mointpoint da cui si desidera smontare e si saprà se ci sono filesystem montati su questo.

mount | perl -pe 's/.*on (\S+) type.*/\1/' | grep '/mnt/dir/'

Quindi hai due soluzioni . Smonta i filesystem o spostali con mount --move olddir newdir(kernel> 2.5.1)

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) .

La domanda su come verificare se NFS accede a una directory che sta per smontare è ancora senza risposta.

Quello che ho è solo questo:

Controlla se nfsd è in esecuzione:

pidof nfsd

Mostra directory montate dai client:

showmount -a

e showmountsenza argomenti mostra solo gli host client anche se non sono in linea. Presumo che questo sia un comportamento speciale di NFS.

Per me, il problema era che ero loggato più di una volta (tramite ssh) e su uno degli accessi ero al prompt dei comandi in cui il pwd era all'interno di una cartella subordinata al mount-point.