Usuwanie błędnego pliku Widzę .nfs0000000000b869e300000001

Usunąłem plik i teraz widzę:

$ 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

a jeśli spróbuję go usunąć:

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

Co to oznacza? Co powinienem zrobić

Plik można usunąć, gdy jest otwarty przez proces. Kiedy tak się dzieje, pozycja katalogu jest usuwana, ale sam plik (i-węzeł i zawartość) pozostają w tyle; plik jest usuwany tylko wtedy, gdy nie ma już żadnych linków i nie jest otwarty przez żaden proces.

NFS jest protokołem bezstanowym: operacje można wykonywać niezależnie od poprzednich operacji. Serwer może się zrestartować, a po powrocie do trybu online klienci będą nadal uzyskiwać dostęp do plików jak poprzednio. Aby to zadziałało, pliki muszą być oznaczone ich nazwami, a nie uchwytami uzyskanymi przez otwarcie pliku (który serwer zapomniałby po ponownym uruchomieniu).

Połącz oba: co się stanie, gdy klient otworzy plik i go usunie? Plik musi nadal mieć nazwę, aby klient, który go otworzył, nadal mógł uzyskać do niego dostęp. Ale po usunięciu pliku oczekuje się, że nie będzie już więcej pliku o tej nazwie. Tak więc serwery NFS zmieniają usunięcie otwartego pliku na zmianę nazwy: nazwa pliku jest zmieniana na .nfs…( .nfspo której następuje ciąg liter i cyfr).

Nie możesz usunąć tych plików (jeśli spróbujesz, wszystko się wydarzy, że .nfs…pojawi się nowy z innym przyrostkiem). W końcu odejdą, gdy klient, który ma otwarty plik, go zamknie. (Jeśli klient zniknie przed zamknięciem pliku, może upłynąć trochę czasu, zanim serwer to zauważy).

Użytkownik @mtak w innym pytaniu sugeruje:

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

^^^^^ To działa ^^^^^ I zabij obrażający proces, aby zwolnić uchwyt pliku.

na przykład

$ 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

TAK! Sukces.

Oczywiście YMMV. Może to być inny proces z otwartym plikiem.

Proces wyodrębniania trackera został ponownie uruchomiony automatycznie po jego zabiciu.

Co to za ekstrakt z trackera? (Widzę to na 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

Ponieważ NFS jest „bezstanowy”, musi istnieć sposób na emulację UNIXowej metody otwierania pliku, a następnie usuwania go z zachowaniem otwartego uchwytu pliku.

Każda operacja na pliku NFS powoduje łańcuch:

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

do uruchomienia, dlatego NFS przetrwa restart serwera.

Po zakończeniu procesu na kliencie, który otworzył stary plik, plik zniknie.

Prawidłowo zaimplementowane serwery plików będą uruchamiać skrypt co noc, który usuwa wszystkie takie pliki, które są starsze niż tydzień. Powodem jest to, że w przypadku ponownego uruchomienia klienta podczas przechowywania takiego pliku, plik pozostanie na zawsze.

Pewien inny proces prawdopodobnie nadal korzysta z pliku (tzn. Ma otwarty uchwyt pliku). Zignoruj ​​plik, użyj lsoflub tym podobne, aby spróbować dowiedzieć się, jaki proces ma otwarty ten plik (lub uruchom ponownie wszystko!).

Napotkałem podobną sytuację, ale w moim przypadku nie jestem w stanie usunąć pliku utworzonego przez mój własny program. Byłem tego pewien, ponieważ był obecny w katalogu utworzonym przez mój program. Nie wiedziałem, gdzie i kiedy uruchomiłem ten program. Rozwiązanie: po prostu wyszedłem ze wszystkich moich terminali. Zalogowałem się ponownie i po prostu usunąłem plik.

PS Moja odpowiedź jest ważna tylko dla określonego przeze mnie scenariusza.