Sou um usuário não root em um servidor de compilação compartilhado que monta /home via NFS de algum outro host. Eu tenho um diretório ~/a/b com muitos subdiretórios c1,c2,... . Eu queria excluir ~/a/b completamente e foi bem-sucedida para a maioria dos diretórios cN . Mas alguns (digamos c1 ) são completamente inacessíveis: eu posso executá-los (por exemplo, cd neles), mas nenhuma lista ( ls ) e muito menos removê-los. Se eu disser rm -rf ~/a/b/c1 , o processo trava em um estado D .
O que posso fazer como usuário não-root para me livrar de ~/a/b ?
Update: Eu apenas ssh'd para o servidor de arquivos (para descartar o NFS) e não consigo executar a operação lá, então isso não parece ser um problema do NFS, afinal. No entanto, por que o kernel se recusa a remover um diretório?
Remover um arquivo ou diretório é uma operação atômica que requer uma chamada de sistema, portanto, se o comando rm trava, é porque o kernel está emperrado. Em um sistema de arquivos NFS, isso pode ser (e geralmente é) devido ao servidor não responder. Em um sistema de arquivos local, isso pode ser (e geralmente é) devido a uma falha de hardware. Seu disco provavelmente está falhando; os logs do kernel confirmariam isso.
Verifique se algum processo está acessando os arquivos sob o capô (como seu diretório de trabalho atual). Eu usaria ferramentas como lsof e fuser -v e veria se há algum processo bagunçando o diretório e me livrando dele primeiro. Reinicie o serviço do cliente nfs, se necessário, e tente verificar se o diretório existe e mais, não remova o diretório quando ele for um diretório de trabalho atual do mesmo shell.
Se ele travar durante a operação de localizar e excluir, você pode definir um tempo limite para o processo, como segue (aqui eu estou chamando-o através de bash no windows com cygwin):
bash -c "find . -regex ".+fileDirToDelete" -exec rm -Rf {} \; & pid=$!; sleep 100; kill $pid"