파일을 제거하면 다음과 같이 표시됩니다.
$ 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
이것이 무엇을 나타 냅니까? 어떻게해야합니까
답변
프로세스에서 파일을 여는 동안 파일을 삭제할 수 있습니다. 이 경우 디렉토리 항목이 삭제되지만 파일 자체 (아이 노드 및 내용)는 남아 있습니다. 파일은 더 이상 링크가없고 프로세스에 의해 열리지 않을 때만 실제로 삭제됩니다.
NFS는 상태 비 저장 프로토콜입니다. 작업은 이전 작업과 독립적으로 수행 할 수 있습니다. 서버를 다시 부팅 할 수도 있으며 다시 온라인 상태가되면 클라이언트는 이전과 같이 파일에 계속 액세스합니다. 이 작업을 수행하려면 파일을 열어서 얻은 핸들 (서버가 재부팅 할 때 잊어 버린 핸들)이 아니라 파일 이름으로 파일을 지정해야합니다.
이 두 가지를 함께 정리하면 클라이언트가 파일을 열고 삭제하면 어떻게됩니까? 파일의 이름을 계속 유지해야 파일을 연 클라이언트가 계속 파일에 액세스 할 수 있습니다. 그러나 파일이 삭제되면 나중에 해당 이름의 파일이 더 이상 존재하지 않을 것으로 예상됩니다. 그래서 NFS 서버는 이름 변경에 열려있는 파일의 삭제를 설정 : 파일이로 이름이 변경 .nfs…
( .nfs
문자와 숫자의 문자열 뒤에).
이러한 파일은 삭제할 수 없습니다 (시도 할 경우 새 파일 .nfs…
이 다른 접미사로 표시 되기만하면됩니다). 파일을 연 클라이언트가 파일을 닫으면 결국 사라집니다. (파일을 닫기 전에 클라이언트가 사라지면 서버가 통지 할 때까지 시간이 걸릴 수 있습니다.)
답변
다른 질문에 대한 @mtak 사용자는 다음을 제안합니다.
You could try running
퓨저 /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에서 이것을 본다)
/programming/26737900/tracker-extract-and-tracker-store-processes- consumer-huge-amount-of-ram
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가 서버 재부팅 후에도 유지되는 이유입니다.
이전 파일을 연 클라이언트의 프로세스가 종료되면 파일이 사라집니다.
올바르게 구현 된 파일 서버는 매일 밤 스크립트를 실행하여 일주일이 지난 파일을 모두 제거합니다. 그 이유는 그러한 파일을 보유한 상태에서 클라이언트가 재부팅되는 경우 파일이 영구적으로 유지되기 때문입니다.
답변
다른 프로세스가 여전히 파일을 사용 중일 수 있습니다 (즉, 열린 파일 핸들이 있음). 파일을 무시하거나 등을 사용 lsof
하여 해당 파일이 열려있는 프로세스를 찾거나 모든 항목을 재부팅하십시오!
답변
비슷한 상황에 직면했지만 내 경우에는 내 프로그램으로 만든 파일을 삭제할 수 없습니다. 내 프로그램에서 만든 디렉토리에 있었기 때문에 이것을 확신했습니다. 나는 언제 어디서 그 프로그램을 운영했는지 몰랐다. 솔루션 : 모든 터미널에서 간단히 나왔습니다. 다시 로그인하여 파일을 삭제했습니다.
추신 : 내 답변은 내가 지정한 scenerio에만 유효합니다.