Suppression d'un fichier errant Je vois .nfs0000000000b869e300000001

J'ai supprimé un fichier et maintenant je vois:

$ 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

et si j'essaye de l'enlever:

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

Qu'est-ce que cela indique? Que devrais-je faire

Un fichier peut être supprimé alors qu'il est ouvert par un processus. Lorsque cela se produit, l'entrée de répertoire est supprimée, mais le fichier lui-même (l'inode et le contenu) reste en arrière; le fichier n'est vraiment supprimé que lorsqu'il n'a plus de liens et qu'il n'est ouvert par aucun processus.

NFS est un protocole sans état: les opérations peuvent être effectuées indépendamment des opérations précédentes. Il est même possible que le serveur redémarre, et une fois qu'il sera de nouveau en ligne, les clients continueront d'accéder aux fichiers comme auparavant. Pour que cela fonctionne, les fichiers doivent être désignés par leurs noms, et non par un gestionnaire obtenu en ouvrant le fichier (que le serveur oublierait lors de son redémarrage).

Mettez les deux ensemble: que se passe-t-il lorsqu'un fichier est ouvert par un client et supprimé? Le fichier doit conserver son nom afin que le client qui l'a ouvert puisse toujours y accéder. Mais lorsqu'un fichier est supprimé, il est prévu qu'aucun fichier de ce nom n'existe plus par la suite. Ainsi, les serveurs NFS transforment la suppression d'un fichier ouvert en un renommage: le fichier est renommé en .nfs…( .nfssuivi d'une chaîne de lettres et de chiffres).

Vous ne pouvez pas supprimer ces fichiers (si vous essayez, tout ce qui se passe est qu'un nouveau .nfs…apparaît avec un suffixe différent). Ils finiront par disparaître lorsque le client qui a le fichier ouvert le ferme. (Si le client disparaît avant de fermer le fichier, cela peut prendre un certain temps jusqu'à ce que le serveur le remarque.)

L'utilisateur @mtak sur une autre question suggère:

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

^^^^^ Cela fonctionne ^^^^^ Et arrêtez le processus offensant pour qu'il libère le descripteur de fichier.

par exemple

$ 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

YAY! Succès.

YMMV bien sûr. Il peut s'agir d'un processus différent si le fichier est ouvert.

Le processus d'extraction du tracker a été redémarré automatiquement après l'avoir tué.

Qu'est-ce que ce truc d'extrait de tracker? (Je vois cela sur 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

Comme NFS est "sans état", il doit y avoir un moyen d'émuler la méthode UNIX d'ouverture d'un fichier, puis de le supprimer en conservant un descripteur de fichier ouvert.

Toute opération de fichier NFS provoque la chaîne:

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

à exécuter et c'est la raison pour laquelle NFS survit à un redémarrage du serveur.

Une fois le processus sur le client qui a ouvert l'ancien fichier terminé, le fichier disparaîtra.

Les serveurs de fichiers correctement mis en œuvre exécuteront un script chaque nuit qui supprime tous les fichiers de plus d'une semaine. La raison en est qu'au cas où le client redémarre tout en conservant un tel fichier, le fichier resterait pour toujours.

Un autre processus utilise probablement encore le fichier (c'est-à-dire qu'il a un descripteur de fichier ouvert). Soit ignorer le fichier, soit utiliser lsofou similaire pour essayer de trouver quel processus a ouvert ce fichier (ou tout redémarrer!).

J'ai fait face à une situation similaire, mais dans mon cas, je ne suis pas en mesure de supprimer un fichier créé par mon propre programme. J'en étais sûr car il était présent dans un répertoire créé par mon programme. Je ne savais pas où et quand j'exécutais ce programme. Solution: je suis simplement sorti de tous mes terminaux. Je me suis reconnecté et j'ai simplement supprimé le fichier.

PS Ma réponse n'est valable que pour le scénario que j'ai spécifié.