Eu tentei rm -rf de uma pasta e fiquei com "dispositivo ou recurso ocupado".
No Windows, eu teria usado o LockHunter para resolver isso. Qual é o equivalente do linux? (Por favor, dê como resposta um simples método "desbloquear este", e não artigos completos como este . é útil, estou atualmente interessado apenas em ASimpleMethodThatWorks ™)
A ferramenta que você quer é lsof , que significa lista de arquivos abertos .
Tem muitas opções, por isso verifique a página man, mas se quiser ver todos os arquivos abertos num diretório:
lsof +D /path
Isso irá recorrer ao sistema de arquivos em /path , portanto, tome cuidado em grandes árvores de diretórios.
Depois de saber quais processos têm arquivos abertos, você pode sair desses aplicativos ou eliminá-los com o comando kill(1) .
às vezes é o resultado de problemas de montagem, então eu desmonto o sistema de arquivos ou diretório que você está tentando remover:
umount /path
Eu uso fuser para esse tipo de coisa. Ele listará qual processo está usando um arquivo ou arquivos dentro de uma montagem.
Aqui está a solução:
ls -a
.xyz vi .xyz e veja qual é o conteúdo do arquivo ps -ef | grep username kill -9 job_ids - onde job_ids é o valor da segunda coluna do erro correspondente que causou conteúdo na oitava coluna Eu tive esse problema quando um teste automatizado criou um ramdisk. Os comandos sugeridos nas outras respostas, lsof e fuser , não ajudaram. Após os testes, tentei desmontá-lo e excluir a pasta. Fiquei muito confuso por muito tempo, porque não consegui me livrar dele - continuei recebendo "Dispositivo ou recurso ocupado" !
Por acaso, descobri como me livrar de um disco ram. Eu tive que desmontar o mesmo número de vezes que eu tinha executado o comando mount , ou seja
sudo umount path
Devido ao fato de ter sido criado usando testes automatizados, ele foi montado muitas vezes, por isso eu não consegui me livrar dele simplesmente desmontando-o uma vez após os testes. Então, depois de desmontar manualmente muitas vezes, ele se tornou uma pasta regular novamente e eu poderia deletá-lo.
Espero que isso possa ajudar alguém que tenha esse problema!
Eu tive esse mesmo problema, construí um one-liner começando com a recomendação @camh:
lsof +D ./ | awk '{print $2}' | tail -n +2 | xargs kill -9
O comando awk agarra o PIDS. O comando tail elimina a primeira entrada irritante: "PID". Eu usei -9 no kill, outros podem ter opções mais seguras.
Se você tiver o servidor acessível, tente
Deleting that dir from the server
Ou, umount e montar novamente, tente umount -l : preguiçoso se estiver enfrentando algum problema no umount normal.
Eu também tive esse problema onde
lsof +D path : não fornece saída
ps -ef : não fornece informações relevantes
Riffing fora da pergunta de Prabhat acima, eu tive esse problema no macos high sierra quando eu encalhou um processo de encfs, reiniciar resolvido, mas isso
ps -ef | grep name-of-busy-dir
Me mostrou o processo e o PID (coluna dois).
sudo kill -15 pid-here
consertou.
Eu experimento isso com frequência em servidores que possuem sistemas de arquivos de rede NFS. Estou assumindo que tem algo a ver com o sistema de arquivos, já que os arquivos são geralmente chamados de .nfs000000123089abcxyz .
Minha solução típica é renomear ou mover o diretório pai do arquivo, depois voltar mais tarde em um dia ou dois e o arquivo será removido automaticamente, ponto no qual estou livre para excluir o diretório.
Isso geralmente acontece em diretórios onde estou instalando ou compilando bibliotecas de software.