Rimozione di un file vagabondo vedo .nfs0000000000b869e300000001


15

Ho rimosso un file e ora vedo:

$ ls
total 64
-rw-rw-r-- 1 502 17229 Sep 17 16:42 page_object_methods.rb
drwxrwxr-x 7 502   238 Sep 18 18:41 ../
-rw-rw-r-- 1 502 18437 Sep 18 18:41 new_page_object_methods.rb
-rw-r--r-- 1 502 16384 Sep 18 18:42 .nfs0000000000b869e300000001
drwxrwxr-x 5 502   170 Sep 21 13:48 ./
13:48:11 *vagrant* ubuntu-14 selenium_rspec_conversion

e se provo a rimuoverlo:

$ rm .nfs0000000000b869e300000001
rm: cannot remove ‘.nfs0000000000b869e300000001’: Device or resource busy

Cosa indica questo? Cosa dovrei fare


Questo problema, combinato con questo bug di servizio audio indicatore in cui centinaia di processi mantengono i file aperti, combinato con argomenti come questi in cui i registri ~ / .cache / upstart diventano molto grandi e vengono quindi compressi, occupavano molto spazio nel mio unità NFS aziendale che include la mia directory home. Ci ho aggirato aggiungendo ps -Af | grep 'indicator-services-start' | awk '{ print $2 }' | xargs killa crontab -e.
Andres Riofrio,

Risposte:


14

Un file può essere eliminato mentre è aperto da un processo. Quando ciò accade, la voce della directory viene eliminata, ma il file stesso (l'inode e il contenuto) rimangono indietro; il file viene veramente eliminato solo quando non ha più collegamenti e non è aperto da alcun processo.

NFS è un protocollo senza stato: le operazioni possono essere eseguite indipendentemente dalle operazioni precedenti. È anche possibile riavviare il server e, una volta tornato online, i client continueranno ad accedere ai file come prima. Affinché ciò funzioni, i file devono essere designati con i loro nomi, non con una gestione ottenuta aprendo il file (che il server dimenticherebbe al riavvio).

Metti insieme le due cose: cosa succede quando un file viene aperto da un client ed eliminato? Il file deve continuare ad avere un nome, in modo che il client che lo ha aperto possa ancora accedervi. Ma quando un file viene eliminato, si prevede che non esistano più file con quel nome in seguito. Quindi i server NFS trasformano la cancellazione di un file aperto in una ridenominazione: il file viene rinominato .nfs…( .nfsseguito da una stringa di lettere e cifre).

Non puoi eliminare questi file (se ci provi, tutto ciò che accade è che un nuovo .nfs…appare con un suffisso diverso). Alla fine spariranno quando il client con il file aperto lo chiude. (Se il client scompare prima di chiudere il file, potrebbe essere necessario del tempo prima che il server lo noti.)


2

L'utente @mtak su un'altra domanda suggerisce:

You could try runningfuser /path/to/.nfsto check which process is using the .nfs file. – mtak May 2 '14 at 9:13

^^^^^ Funziona ^^^^^ E uccidi il processo offensivo per far sì che rilasci l'handle del file.

per esempio

$ rm -rf ~/Downloads
rm: cannot remove ‘/nfshome/x/Downloads’: Directory not empty
$ ls -alstr ~/Downloads
total 38864
  972 -rw-r--r--   1 x users   988438 Dec 20  2016 .nfs00000000018d307a00000369
31812 -rw-r--r--   1 x users 32503812 Dec 20  2016 .nfs00000000018d307f0000036b
  636 drwx--x--x 134 x y   647168 Aug 28 10:37 ..
  240 drwxr-xr-x   2 x y   241664 Aug 28 10:43 .
$ rm -rf ~/Downloads
rm: cannot remove ‘/na-homes/x/Downloads/.nfs00000000018d307a00000369’: Device or resource busy
rm: cannot remove ‘/na-homes/x/Downloads/.nfs00000000018d307f0000036b’: Device or resource busy

$ fuser /nfshome/x/Downloads/.nfs00000000018d307400000367
/nfshome/x/Downloads/.nfs00000000018d307400000367:  8231m
$ ps -elf |grep 8231
0 S x     1493 15153  0  80   0 - 28177 pipe_w 10:55 pts/39   00:00:00 grep --color=auto 8231
0 S x     8231  7660  0  99   - - 481464 poll_s Jul19 ?       00:06:01 /usr/libexec/tracker-extract
$ kill 8231
$ kill 8231 # kill twice to check first kill worked, . . 
            # escalate to kill -9 8231 if first kill didn't work, . . 
            # use sudo or root or other user to kill if ownership prevents kill working.
-bash: kill: (8231) - No such process
$ rm -rf ~/Downloads

$ ls -alstr ~/Downloads/
ls: cannot access /nfshome/x/Downloads/: No such file or directory

SÌÌ! Successo.

YMMV ovviamente. Potrebbe essere un processo diverso con il file aperto.

Il processo di estrazione del tracker è stato riavviato automaticamente dopo che l'ho ucciso.

Cos'è questa cosa di tracker-extract? (Vedo questo su centos / redhat)

/programming/26737900/tracker-extract-and-tracker-store-processes-consuming-huge-amount-of-ram

extra/tracker 1.2.3-1 (gnome)
    All-in-one indexer, search tool and metadata database

1
Molto più utile della risposta accettata, in quanto fornisce all'utente un modo per porre rimedio alla situazione.
chb

1

Poiché NFS è "stateless", è necessario un modo per emulare il metodo UNIX di apertura di un file e quindi rimuoverlo mantenendo un filehandle aperto.

Qualsiasi operazione sul file NFS provoca la catena:

open(); seek-last-off(); doit(); close();

da eseguire e questo è il motivo per cui NFS sopravvive al riavvio del server.

Una volta terminato il processo sul client che ha aperto il vecchio file, il file scomparirà.

I file server correttamente implementati eseguiranno uno script ogni notte che rimuove tutti i file più vecchi di una settimana. Il motivo è che nel caso in cui il client si riavvii mentre è in possesso di tale file, il file rimarrà per sempre.


0

È probabile che qualche altro processo stia ancora utilizzando il file (ovvero ha un filehandle aperto). Ignora il file o usa lsofo simili per provare a trovare quale processo ha quel file aperto (o riavvia tutto!).


0

Ho affrontato una situazione simile, ma nel mio caso non sono in grado di eliminare un file creato dal mio programma. Ne ero sicuro perché era presente in una directory creata dal mio programma. Non sapevo dove e quando ho eseguito quel programma. Soluzione: sono semplicemente uscito da tutti i miei terminali. Ho effettuato nuovamente l'accesso e ho semplicemente eliminato il file.

PS La mia risposta è valida solo per lo scenario che ho specificato.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.