Como superar o "dispositivo ou recurso ocupado"?

229

Eu tentei rm -rfuma pasta e fiquei "dispositivo ou recurso ocupado".

No Windows, eu teria usado o LockHunter para resolver isso. Qual é o equivalente ao Linux? (Por favor, forneça como resposta um método simples "desbloqueie este" e não complete artigos como este . Embora sejam úteis, atualmente estou interessado apenas no ASimpleMethodThatWorks ™)

files lock

— ripper234
fonte

5

Obrigado, isso foi útil - eu estava vindo do Linux para o Windows, estava procurando o equivalente ao lsof - LockHunter.

— Sonia Hamilton

3

Que diabos? O Unix não impede que você exclua arquivos abertos como o Windows. É por isso que você pode excluir todo o seu sistema executando rm -rf /... ele excluirá todos os arquivos, incluindo / bin / rm.

— psusi

1

@ psusi, isso está incorreto. Você tem uma fonte ruim de informação ou está apenas inventando coisas. O Linux, como o Windows, possui bloqueio de arquivos e dispositivos. Está meio que quebrado, no entanto. 0pointer.de/blog/projects/locking.html

— foobarbecue

1

@foobarbecue, normalmente esses são apenas bloqueios consultivos e a página de manual pelo menos parece indicar que são apenas para leitura / gravação, não desvincular.

— psusi

232

A ferramenta que você deseja é lsof, que significa arquivos abertos da lista .

Ele tem muitas opções, portanto verifique a página de manual, mas se você quiser ver todos os arquivos abertos em um diretório:

lsof +D /path

Isso ocorrerá através do sistema de arquivos abaixo /path; portanto, cuidado com isso em grandes árvores de diretórios.

Depois de saber quais processos têm arquivos abertos, você pode sair desses aplicativos ou matá-los com o kill(1)comando

— camh
fonte

46

E se não houvesse resultados?

— marines

22

@marines: Verifique se outro sistema de arquivos está montado abaixo /path. Essa é uma causa de "arquivos abertos" ocultos.

— Camh

2

O comando lsof diretamente no caminho não funciona. Então, basicamente, precisa ir no local do caminho e depois executar lsof busy_file depois matar todo o processo

— J4cK

4

lsofparece não fazer nada por mim: lsof storage/logs/laravel.lognão retornou nada, e o fez lsof +D storage/logs/. umountrespondeu com not mounted.

— Ryan

1

Apenas para elaborar a resposta @camh: Use mount | grep <path>. Isso mostra que qualquer um /dev/<abc>pode estar montado no <path>. Use sudo umount -lf /dev/<abc>e tente remover <path>. Funciona para mim. Obrigado @camh

— Vikas Goel

107

às vezes, é o resultado de problemas de montagem, então desmonte o sistema de arquivos ou o diretório que você está tentando remover:

quantidade / caminho

— kip2
fonte

5

São quinze para as quatro. Obrigado cara, você salvou minha noite. Hilário. Em uma única linha - tanto tempo perdido -.- '

— Aiyion.Prime

1

meu problema era um diretório de log montado como / dev / mapper / vg00-root

— Spikolynn

1

Me ajudou a sair de um congestionamento semelhante nos enroladores.

— 9136 Jon

1

no meu caso, Jenkins não desmontar chroot dir após abortar tarefa

— zarkone

1

no meu caso, desmontar com o ubuntu desktop funcionou !! THanks

— JRichardsz

14

Eu uso fuserpara esse tipo de coisa. Ele listará qual processo está usando um arquivo ou arquivos em uma montagem.

— BillThor
fonte

fuserajuda apenas no caso específico em que você deseja desmontar um sistema de arquivos. Aqui, o problema é descobrir o que está usando um arquivo específico.

— Gilles

@ Gilles: Também funciona para arquivos.

— BillThor

Desculpe, objeção errada: fusernão ajuda aqui porque o problema é encontrar todos os arquivos abertos em uma árvore de diretórios. Você pode dizer lsofpara mostrar todos os arquivos e filtros ou fazê-lo recuar; fusernão possui esse modo e precisa ser chamado em todos os arquivos.

— Gilles

@ Giles: fuserobras serão listas. Tente fuser /var/log/*, se houver algum registro aberto, ele informará quem e quem está aberto. Se um curinga simples, não funcionar, findcom ou sem xargsfará o trabalho.

— BillThor

1

lsofnão estava no meu caminho enquanto fuserestava, permitindo-me encontrar o ID do processo incorreto para matar, então + 1 + obrigado.

— Steveliva

12

Aqui está a solução:

Entre no diretório e digite ls -a
Você encontrará um .xyzarquivo
vi .xyz e veja qual é o conteúdo do arquivo
ps -ef | grep username
Você verá o conteúdo .xyz na 8a coluna (última linha)
kill -9 job_ids - onde job_ids é o valor da segunda coluna do erro correspondente causado pelo conteúdo na oitava coluna
Agora tente excluir a pasta ou arquivo.

— user73011
fonte

4

Seria interessante saber de onde vêm esses arquivos misteriosos.

— John WH Smith

9

Eu tive esse mesmo problema, construí uma linha única começando com a recomendação @camh:

lsof +D ./ | awk '{print $2}' | tail -n +2 | xargs kill -9

O awkcomando agarra o PIDS. O tailcomando se livra da primeira entrada traquina: "PID". Eu costumava -9matar, outros podem ter opções mais seguras.

— Choylton B. Higginbottom
fonte

1

Para torná-lo mais universal, você pode usar ./ para o diretório atual em vez de log /

— user2589273

Bom ponto, @ user2589273. Atualizada.

— Choylton B. Higginbottom

5

Eu tive esse problema quando um teste automatizado criou um ramdisk. Os comandos sugeridos nas outras respostas lsofe fusernão ajudaram. Após os testes, tentei desmontá-lo e excluir a pasta. Fiquei realmente confuso por muito tempo porque não consegui me livrar dele - fiquei ficando "Dispositivo ou recurso ocupado" !

Por acidente, descobri como me livrar de um disco rígido. Eu tive que desmontá-lo o mesmo número de vezes que eu executei o mountcomando, ou seja, sudo umount path

Devido ao fato de ter sido criado usando testes automatizados, ele foi montado várias vezes, por isso não consegui me livrar dele simplesmente desmontando-o uma vez após os testes. Então, depois de desmontá-lo manualmente muitas vezes, ele finalmente se tornou uma pasta normal novamente e eu pude excluí-lo.

Espero que isso possa ajudar alguém que se deparar com esse problema!

— glorifobia
fonte

5

Eu experimento isso frequentemente em servidores que possuem sistemas de arquivos de rede NFS. Estou assumindo que tem algo a ver com o sistema de arquivos, uma vez que os arquivos geralmente são nomeados como .nfs000000123089abcxyz.

Minha solução típica é renomear ou mover o diretório pai do arquivo e voltar mais tarde em um dia ou dois e o arquivo será removido automaticamente. Nesse momento, eu posso excluir o diretório.

Isso normalmente acontece nos diretórios em que estou instalando ou compilando bibliotecas de software.

— user5359531
fonte

4

Tirando a pergunta de Prabhat acima, eu tive esse problema em macos high sierra quando encalhei um processo encfs, a reinicialização o resolveu, mas isso

ps -ef | grep name-of-busy-dir

Me mostrou o processo e o PID (coluna dois).

sudo kill -15 pid-here

consertou.

— bil
fonte

Isso funcionou para mim também. Qual é o -15?

— O.rka

3

Se você tiver o servidor acessível, tente

Excluindo esse diretório do servidor

Ou então, monte umount e monte novamente, tente umount -l: umount lento se enfrentar algum problema no umount normal.

Eu também tive esse problema em que

lsof +D path : não fornece saída

ps -ef : não fornece informações relevantes

— Prabhat Kumar Singh
fonte