Eliminando un archivo vagabundo veo .nfs0000000000b869e300000001

Eliminé un archivo y ahora veo:

$ 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

y si trato de eliminarlo:

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

¿Qué indica esto? Qué tengo que hacer

Un archivo se puede eliminar mientras está abierto por un proceso. Cuando esto sucede, la entrada del directorio se elimina, pero el archivo en sí (el inodo y el contenido) se quedan atrás; el archivo solo se elimina realmente cuando no tiene más enlaces y ningún proceso lo abre.

NFS es un protocolo sin estado: las operaciones se pueden realizar independientemente de las operaciones anteriores. Incluso es posible que el servidor se reinicie, y una vez que vuelva a estar en línea, los clientes continuarán accediendo a los archivos como antes. Para que esto funcione, los archivos deben ser designados por sus nombres, no por un identificador obtenido al abrir el archivo (que el servidor olvidaría cuando se reinicie).

Ponga los dos juntos: ¿qué sucede cuando un cliente abre un archivo y lo elimina? El archivo debe seguir teniendo nombre, para que el cliente que lo tiene abierto pueda acceder a él. Pero cuando se elimina un archivo, se espera que no exista más archivo con ese nombre después. Por lo tanto, los servidores NFS convierten la eliminación de un archivo abierto en un cambio de nombre: se cambia el nombre del archivo .nfs…( .nfsseguido de una cadena de letras y dígitos).

No puede eliminar estos archivos (si lo intenta, todo lo que sucede es que .nfs…aparece un nuevo con un sufijo diferente). Eventualmente desaparecerán cuando el cliente que tiene el archivo abierto lo cierre. (Si el cliente desaparece antes de cerrar el archivo, puede pasar un tiempo hasta que el servidor se dé cuenta).

El usuario @mtak en otra pregunta sugiere:

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

^^^^^ Eso funciona ^^^^^ Y anula el proceso ofensivo para que libere el identificador de archivo.

p.ej

$ 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

¡HURRA! Éxito.

YMMV por supuesto. Puede ser un proceso diferente sentado con el archivo abierto.

El proceso de extracción del rastreador se reinició automáticamente después de que lo maté.

¿Qué es esta cosa de extracto de rastreador? (Veo esto en 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

Como NFS es "sin estado", debe haber una manera de emular el método UNIX de abrir un archivo y luego eliminarlo manteniendo un identificador de archivo abierto.

Cualquier operación de archivo NFS provoca la cadena:

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

para ejecutarse y esta es la razón por la cual NFS sobrevive al reinicio del servidor.

Una vez que el proceso en el cliente que abrió el archivo anterior finaliza, el archivo desaparecerá.

Los servidores de archivos implementados correctamente ejecutarán un script todas las noches que elimine todos los archivos anteriores a una semana. La razón es que en caso de que el cliente se reinicie mientras mantiene dicho archivo, el archivo permanecerá para siempre.

Es probable que algún otro proceso siga usando el archivo (es decir, tiene un identificador de archivo abierto). O bien ignore el archivo, o use lsofo algo similar para tratar de encontrar qué proceso tiene ese archivo abierto (¡o reinicie todo!).

Me enfrenté a una situación similar, pero en mi caso no puedo eliminar un archivo creado por mi propio programa. Estaba seguro de esto porque estaba presente en un directorio creado por mi programa. No sabía dónde y cuándo ejecuté ese programa. Solución: simplemente salí de todas mis terminales. Ingresé nuevamente y simplemente eliminé el archivo.

PD Mi respuesta solo es válida para el escenario que he especificado.