Removendo um arquivo vagrant, vejo .nfs0000000000b869e300000001

15

Eu removi um arquivo e agora vejo:

$ 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

e se eu tentar removê-lo:

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

O que isso indica? O que devo fazer

Michael Durrant
fonte
Esse problema, combinado com esse bug do serviço indicador de som, onde centenas de processos mantêm os arquivos abertos, combinado com problemas como estes, nos quais os logs ~ / .cache / upstart crescem muito e são compactados, ocupavam muito espaço no meu unidade NFS corporativa que inclui meu diretório pessoal. Resolvido adicionando ps -Af | grep 'indicator-services-start' | awk '{ print $2 }' | xargs killa crontab -e.
Andres Riofrio 13/03

Respostas:

14

Um arquivo pode ser excluído enquanto é aberto por um processo. Quando isso acontece, a entrada do diretório é excluída, mas o próprio arquivo (o inode e o conteúdo) permanece para trás; o arquivo só é realmente excluído quando não há mais links e não é aberto por nenhum processo.

NFS é um protocolo sem estado: as operações podem ser executadas independentemente das operações anteriores. É até possível que o servidor seja reinicializado e, uma vez on-line novamente, os clientes continuarão acessando os arquivos como antes. Para que isso funcione, os arquivos devem ser designados por seus nomes, e não por uma manipulação obtida pela abertura do arquivo (que o servidor esqueceria quando reiniciar).

Coloque os dois juntos: o que acontece quando um arquivo é aberto por um cliente e excluído? O arquivo precisa manter o nome, para que o cliente que o abrir ainda possa acessá-lo. Mas quando um arquivo é excluído, espera-se que não exista mais arquivo com esse nome posteriormente. Portanto, os servidores NFS transformam a exclusão de um arquivo aberto em uma renomeação: o arquivo é renomeado para .nfs…( .nfsseguido por uma sequência de letras e dígitos).

Você não pode excluir esses arquivos (se tentar, tudo o que acontece é que um novo .nfs…aparece com um sufixo diferente). Eles desaparecerão quando o cliente que tiver o arquivo aberto o fechar. (Se o cliente desaparecer antes de fechar o arquivo, pode demorar um pouco até o servidor perceber.)

Gilles 'SO- parar de ser mau'
fonte
2

O usuário @mtak em outra pergunta sugere:

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

^^^^^ Isso funciona ^^^^^ E elimine o processo incorreto para fazer com que ele libere o identificador do arquivo.

por exemplo

$ 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! Sucesso.

YMMV é claro. Pode ser um processo diferente com o arquivo aberto.

O processo rastreador-extração foi reiniciado automaticamente depois que eu o matei.

O que é essa coisa de rastrear e extrair? (Eu vejo isso em 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
gaoithe
fonte
1
Muito mais útil que a resposta aceita, pois fornece ao usuário uma maneira de remediar a situação.
Chb
1

Como o NFS é "sem estado", é necessário haver uma maneira de emular o método UNIX de abrir um arquivo e removê-lo mantendo uma manipulação de arquivo aberta.

Qualquer operação de arquivo NFS causa a cadeia:

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

para ser executado e é por isso que o NFS sobrevive à reinicialização do servidor.

Quando o processo no cliente que abriu o arquivo antigo terminar, o arquivo desaparecerá.

Os servidores de arquivos implementados corretamente executam um script a cada noite que remove todos os arquivos anteriores a uma semana. O motivo é que, no caso de o cliente reiniciar enquanto mantém esse arquivo, ele permanecerá para sempre.

esperto
fonte
0

É provável que algum outro processo ainda esteja usando o arquivo (ou seja, possui um identificador de arquivo aberto). Ignore o arquivo ou use-o lsofou algo parecido para tentar descobrir qual processo esse arquivo está aberto (ou reinicie tudo!).

agitar
fonte
0

Enfrentei uma situação semelhante, mas, no meu caso, não consigo excluir um arquivo criado por meu próprio programa. Eu tinha certeza disso, porque estava presente em um diretório criado pelo meu programa. Eu não sabia onde e quando executei o programa. Solução: simplesmente saí de todos os meus terminais. Eu entrei novamente e simplesmente excluí o arquivo.

PS Minha resposta é válida apenas para o cenário especificado.

Purushottam Parakh
fonte