ファイルを削除すると、次のように表示されます。
$ 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
そして私がそれを削除しようとすると:
$ rm .nfs0000000000b869e300000001
rm: cannot remove ‘.nfs0000000000b869e300000001’: Device or resource busy
これは何を示していますか?私は何をすべきか
プロセスによって開かれているファイルは削除できます。これが発生すると、ディレクトリエントリは削除されますが、ファイル自体(iノードとコンテンツ)は残ります。ファイルが本当に削除されるのは、リンクがなくなり、どのプロセスでも開かれていない場合のみです。
NFSはステートレスプロトコルです。操作は、以前の操作とは無関係に実行できます。サーバーを再起動することもできます。サーバーがオンラインに戻ると、クライアントは以前と同様にファイルにアクセスし続けます。これが機能するためには、ファイルを開くことによって取得されたハンドル(サーバーが再起動すると忘れる)ではなく、ファイルを名前で指定する必要があります。
2つを組み合わせる:クライアントがファイルを開いて削除するとどうなりますか?ファイルには名前を付け続ける必要があるため、ファイルを開いているクライアントは引き続きファイルにアクセスできます。しかし、ファイルが削除されると、その名前のファイルがそれ以上存在しないことが予想されます。したがって、NFSサーバーは開いているファイルの削除を名前の変更に変えます。ファイルの名前は.nfs…
(.nfs
の後に文字と数字の文字列が続く)に変更されます。
これらのファイルを削除することはできません(実行すると、新しい.nfs…
が異なるサフィックスで表示されるだけです)。ファイルを開いているクライアントがファイルを閉じると、最終的にはなくなります。 (ファイルを閉じる前にクライアントが消えた場合、サーバーが気付くまでにしばらく時間がかかることがあります。)
別の質問に対するユーザー@mtakの提案:
You could try running
fuser /path/to/.nfsto check which process is using the .nfs file. – mtak May 2 '14 at 9:13
^^^^^動作します^^^^^問題のプロセスを強制終了して、ファイルハンドルを解放します。
例えば.
$ 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
わーい!成功。
もちろんYMMV。ファイルを開いた状態で別のプロセスになっている可能性があります。
私がそれを殺した後、トラッカー抽出プロセスは自動的に再開されました。
このトラッカー抽出物は何ですか? (私はcentos/redhatでこれを見ます)
extra/tracker 1.2.3-1 (gnome)
All-in-one indexer, search tool and metadata database
NFSは「ステートレス」なので、ファイルを開くUNIXの方法をエミュレートして、開いているファイルハンドルを保持したまま削除する方法が必要です。
NFSファイル操作によってチェーンが発生します。
open(); seek-last-off(); doit(); close();
これが実行され、NFSがサーバーの再起動後も存続する理由です。
古いファイルを開いたクライアントのプロセスが終了すると、ファイルは消えます。
正しく実装されたファイルサーバーは、毎週スクリプトを実行して、1週間より古いファイルをすべて削除します。その理由は、そのようなファイルを保持しているときにクライアントが再起動した場合、ファイルは永久に残るためです。
他のいくつかのプロセスがまだファイルを使用している可能性があります(つまり、ファイルへのオープンファイルハンドルがあります)。ファイルを無視するか、lsof
などを使用して、そのファイルを開いているプロセスを見つけてください(またはすべてを再起動してください)。
同様の状況に直面しましたが、私の場合、自分のプログラムで作成したファイルを削除することができません。私のプログラムによって作成されたディレクトリに存在していたので、私はこれを確信していました。そのプログラムをどこでいつ実行したかはわかりませんでした。解決策:私は単にすべての端末を終了しました。再度ログインして、ファイルを削除しました。
追伸私の回答は、指定したscenerioに対してのみ有効です。